Node.js 17 is out, loaded with OpenSSL 3 and other new features, but it is not intended for use in production – and the promotion for Node.js 16 to an LTS release, expected soon, may be more important to most developers.
“We put together the LTS release process almost five years ago, it works quite well in that we’re balancing [the fact] that some people want the latest, others prefer to have things be stable… when we go LTS,” Red Hat’s Michael Dawson, chair of the Node.js Technical Steering Committee, told The Register.
“We’ve hopefully shaken out any issues. Actually at Red Hat we only issue binaries for the LTS releases, and that’s what I recommend people to use in production.”
Having established that Node.js 17 is not primarily intended for production use, what is new? Inclusion of OpenSSL 3.0 is a big one, Dawson told us. “It give us a path to community FIPS (Federal Information Processing Standards),” said Dawson – though the OpenSSL team said last month that FIPS 140-2 validation is still in progress and “the final certificate is not expected to be issued until next year.”
FIPS 140-2 covers cryptographic modules, and observance of the standard ensures, a level of security approved by the US government for sensitive information, and requires use of FIPS-approved cryptographic algorithms. There will be some impact on developers if existing application uses disallow algorithms or keys that are too small. A command line option enables use of the now legacy OpenSSL provider if needed. Some distributions of Node.js already provide FIPS support but “community FIPS” 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 enables reading data from a stream one line at a time. Fatal exceptions will now include the Node.js version number. And Node.js can be compiled with GNU++ 17 and Microsoft VC++ 17.
Showing its age?
Is Node beginning to look dated, with its use of CommonJS modules, gradually being replaced by modern ECMAScript (ES6) modules, and advances in browser technology that will reduce the necessity of build processes using the likes of WebPack?
“If you track the usage numbers, 200 million downloads from our site last quarter, 350 million pulls from the Docker container registry. 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 quite a big team working on that. The way the spec was put together made it a challenge to bring together two module systems, there’s still some experimental features that we’re working on to improve the ES6 implementation and make it easier to adopt. I don’t see any problem that ES6 causes to Node adoption or usage.”
There has been 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 have identified that 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 where we should have a plan,” said Dawson.
One of the debates is over cases where there are types maintained externally to a module, by people other than the module authors, with the potential for compatibility issues and breaking changes.
“Is there something we should do to improve that situation?” asked Dawson. The APIs tend to be “relatively stable,” he said, so problems do not often occur. “You can use Node with TypeScript today quite effectively. ” ®