Node.js 17 is out, loaded with OpenSSL 3 and other new features, but it’s not intended for production use – and the promotion of Node.js 16 to an LTS version, expected soon, may be more important for most developers.
“We set up the LTS release process almost five years ago, it works pretty well as long as we balance [the fact] that some people want the latest stuff, some people want things to be stableâ¦ when we switch to LTS, âsaid Michael Dawson of Red Hat, chairman of the technical steering committee of Node.js. The register.
âWe hope to have solved all the problems. In fact, at Red Hat we only release binaries for the LTS versions, and that’s what I recommend people use in production.
Having established that Node.js 17 is not primarily intended for production use, what is new? The inclusion of OpenSSL 3.0 is important, Dawson told us. âIt gives us a path to the Federal Information Processing Standards (FIPS) community,â said Dawson – via the OpenSSL team said last month that FIPS 140-2 validation is still ongoing and that “the final certificate should not be issued until next year”.
FIPS 140-2 covers cryptographic modules and compliance with the standard ensures a US government approved level of security for sensitive information and requires the use of FIPS approved cryptographic algorithms. There will be some impact on developers if the existing application uses denial algorithms or keys that are too small. A command line option allows you to use the now legacy OpenSSL provider if needed. Some distributions of Node.js already provide FIPS support but “FIPS community” will mean better integration with third party modules.
There are other changes in Node.js 17, including the Readline Promise API, a new feature that allows data from a stream to be read one line at a time. Fatal exceptions will now include the version number of Node.js. And Node.js can be compiled with GNU ++ 17 and Microsoft VC ++ 17.
Show his age?
Is Node starting to look obsolete, with its use of CommonJS modules, gradually being replaced by modern ECMAScript (ES6) modules, and advancements in browser technology that will reduce the need to build processes using WebPack?
âIf you follow the usage numbers, 200 million downloads from our site last quarter, 350 million draws from the Docker container ledger. I don’t see any trend other than continued growth in usage,â said Dawson.
“The project is evolving, we have an ES6 implementation, we have a fairly large team working on it. The way the specification was put together made it difficult to bring two systems of modules together, there are still experimental features on which We are working to improve the implementation of ES6 and make it easier to adopt. I see no problem ES6 is causing with adopting or using Node. “
There was an impact though, in that “we think it’s good to provide types with your module even if it’s not written in TypeScript … we’ve identified this as something the [Node.js] project should have an opinion on. I can’t say what that opinion will be, but everyone agrees that types are an important concept that we should have a plan for, âDawson said.
One of the debates is where there are types maintained outside of a mod, by people other than the mod’s authors, with the potential for compatibility issues and breaking changes.
“Is there anything we should be doing to improve this situation?” Dawson asked. APIs tend to be “relatively stable,” he said, so problems don’t happen often. âYou can use Node with TypeScript today quite efficiently. “Â®