Introducing Node.js 17

Back in April, I gave an update on some of the news features in the Node.js 16 release. Today, I am happy to share that the Node.js community is releasing Node.js 17 and that next week Node.js 16 will be promoted to Long Term Support (LTS).

As per the Node.js release process, Node.js version 17 will not be promoted to LTS as only even versions get LTS. For production deployments, we recommended using Node.js 16, and focus on Node.js 17 to test and provide feedback on the new functionality and features to help pave the way for future releases. You can read more about the community release process here.

If you follow Red Hat’s work in the Node.js project or have been following our regular updates you’ll see that our strategy is to focus on aspects we believe are important to our customers, including:

• Stable and predictable releases
• Platform support
• Security
• Diagnostics
• Performance
• Code quality and safety net
• Key features

The Node.js 17 release continues to deliver in these areas.

Some of the interesting new features in the 17.x release include:

• OpenSSL 3 support
• Node.js version in stack traces
• V8 JavaScript Engine Version 9.5
• New promises APIs
• Updated platform support

We have been waiting on a GA version of OpenSSL 3 for a while and we were happy to see that it arrived in September. Red Hat's Daniel Bevenius and Richard Lau have been working diligently to get the OpenSSL 3 betas integrated into the Node.js code base so we were ready to switch over to the OpenSSL 3 GA when it arrived.

While the OpenSSL 3 APIs aim to be compatible with the previous OpenSSL version, there will be some impact on users due to the switch to OpenSSL 3 as each new version of OpenSSL tightens the allowable key sizes and algorithms that are available. If you are still using small keys or older algorithms you should plan time to understand how you might be affected. More information is available in the OpenSSL3 blog post.

One of the exciting aspects of OpenSSL 3 is that it provides a path for FIPS 140-2 compliance support in community builds. Red Hat already provides FIPs support for Node.js in Red Hat Enterprise Linux distributions and containers, but community support should simplify integration of third party modules and hardware over time.

Node.js 17 adds the Node.js version to unhandled exceptions:

This can help with diagnostics as it can remove a round trip asking a customer what version of Node.js they are using. It’s good to see these small but important improvements to the Node.js diagnostics over time.

Each major release brings with it an updated version of the V8 JavaScript engine along with better performance and new features. One of the interesting new features is the addition of an error cause.

Being able to better nest errors also helps with diagnostics. As an example:

There is an ongoing strategic initiative within the project to add promise-based APIs. The Node.js project strives to progress this initiative with the addition of a promise-based API for readline. With Node.js 17 you can await on readline as follows:

   async function getInput() {
     const readln = readline.createInterface({ input, output });
     const response = await readln.question('You there? ');

     console.log(`Thanks for answering: ${response}`);

     readln.close();
   }

It’s great to see regular progress with the promise-based APIs being added over the last number of releases:

• readline (v17.0.0)
• timers (V16.0.0)
• stream (v15.0.0)
• fs (v14.0.0)
• dns (v11.14.0)

As with most major releases, this release updates the minimum supported levels for platforms and tooling used to build Node.js. Please check the documentation in Node's building instructions for all the latest minimum levels.

With the promotion of version 16 to LTS, it’s now suitable for use in production, and you should consider how it fits into your migration plan. Node.js 16.x brings with features/functions that we believe are important to our customers:

• Updated Platform support
• V8 JavaScript Engine Version 9
• N-API Version 8
• New Promises APIs
• Async Local Storage APIs

You can check out the details in my previous blog, Node.js 16 is here with updated platform support, V8 version 9, and more!

Of particular note for Mac OS X fans, this is the first Node.js LTS release with support for ARM (Apple Silicon).

It is also interesting to note that while Async Local Storage was not stable when the Node.js 16 release came out in April, it is now a stable feature as part of the LTS release.

With the community promotion of Node.js 16 to LTS, we’ll follow up with Node.js 16 support in upcoming releases of Red Hat Enterprise Linux  and Node.js Universal Base Image (UBI) containers. Keep an eye out for our upcoming release announcements.

Thanks to all of the project contributors
At this point I’d like to thank all of the people who contribute to Node.js releases, including Red Hat's Bethany Griggs, on the Node.js releaser team, who created and coordinated the Node.js 17 release. The community has a large cast of contributors (including those across Red Hat and IBM) working across the Node.js project and each release is the result of all of their hard work.

There are many ways to contribute to the Node.js project. Committing code and participating in the work of the Node.js organization is not the only way to contribute to the continued success of Node.js. As a Node.js application developer or end user a few ways you can help out include:

• Testing new releases early and often and providing feedback to the Node.js project.
• Helping to define and move forward the priorities identified as important for the success of Node.js over the next 10 years and participating in the next-10 effort.

If you are a package maintainer, there are a number of things you can do to align with the efforts of the Node.js project including:

• Consider adding package support information to your Node.js modules. This is an effort led by the Node.js package-maintenance team and you can read more about it in these articles: Add standardized support information to your Node.js modules, Node.js package maintenance bridges the gap between maintainers and consumers
• Consider aligning your releases and support cycles with the Node.js release lines. This article, Maintainers Should Consider Following Node.js’ Release Schedule, from the OpenJS Foundation makes a great case for why this benefits the ecosystem.
• Join the package-maintenance team to work on common challenges.

You can read about all the new features and changes in Node.js 17 from the community post here. To learn more about the Node.js community and to learn how you can contribute, you can check out the project repository and website. If you want to read more about what Red Hat is up to on the Node.js front, check out the Node.js developers page here. Finally, if you’re a Red Hat customer, check out the customer portal for more information.