An introduction to Node.js 22 from Red Hat

It's that time of year again for the Node.js community to release a new major version, and this time it's Node.js 22. This release line is an even-numbered one, which means that it will be promoted to long-term support (LTS) in October 2024, and receive support until April 2027.

However, before the release is officially promoted to LTS, the Node.js team needs the help of the wider community to test it out and provide feedback. This will help identify and fix any issues before the release, ensuring a smoother experience for everyone.

For those using Red Hat Enterprise Linux (RHEL), Node.js support will start after the release is promoted to LTS in October, which means you can expect to find packages for the RPM Package Manager (rpm) and containers around that time. However, to facilitate advanced testing, the Red Hat Node.js team plans to provide some unofficial container images.

Red Hat's focus in the Node.js project is on topics that are important to our customers, including:

• stable and predictable releases
• platform support
• security
• diagnostics
• performance, and 
• code quality

Our commitment to these priorities, combined with our collaborations with customers and internal teams, keeping the Node.js infrastructure running, keeping V8 running on the s390 and PPC architectures, integrating support for ubi into buildpacks, as well as our sharing of expertise in the Node.js reference architecture, keeps us busy.

At the time of Node.js 22, we are excited to share some recent features and ongoing initiatives that have piqued our interest, or in which our team has played a role. Due to how quickly features flow back into the existing Node.js release line, they all may not be technically new in Node.js 22 but they are worth mentioning as having landed since the last major release. As an example there are a number of interesting additions that were added to Node.js 21 after the initial release.

Highlights of recent additions

Continued progress on performance

As with every release, Node.js brings with it a new version of the V8 JavaScript engine which generally boosts performance. In addition the project continues to optimize and adjust base settings to provide a better out of the box experience. A few updates of note include:

• V8 update to 12.4. A new optimizing JIT compiler called Maglev, which sits between the existing Sparkplug and Turbofan compilers, has been enabled by default on supported architectures. 
• The general performance for Node.js streams has been boosted by increasing the default high water mark from 16 KB to 65 KB. This does slightly increase memory usage, so for memory sensitive environments the default value can be adjusted via setDefaultHighWaterMark().
• Performance of the fetch() API and test runner has been boosted by improving the efficiency of AbortSignal instance creation.
• Improvements to the performance of synchronous filesystem APIs.

If you are interested in Node.js performance, follow or consider joining the Performance team.

Better handling of bad IPV6 configurations

Starting with version 17, Node.js no longer preferred IPv4 over IPV6. Instead it respects the order that is returned based on the DNS entries. For properly configured hosts this should not make a difference but if you had a partially or incorrectly configured IPv6 stack on your hosts you might have run into problems.

Since Node.js 17, the project has been working to improve the experience with incorrectly configured IPv6 stacks, including implementing the happy eyeballs algorithm and fixing edge cases including most recently adding new connection attempts events.

As before, if you encounter an issue you can use the --dns-result-order=ipv4first command line option to revert to the old behavior. There is also --no-network-family-autoselection which is on by default but can be used to disable happy eyeballs.

Progress on web compatibility

Node.js continues to evaluate adding APIs for web compatibility. This includes the following which were added during the lifespan of Node.js 21:

• Adding experimental support for a browser-compatible Websocket client.
• Support for the deflate-raw compression format for Webstreams.
• Partial support for the Navigator API.

In addition, the Websocket support not long requires a flag in Node.js 22 although it is still experimental.

Progress on ESM compatibility

Improving ESM compatibility is a continued focus with a some of the interesting tech preview additions including:

   import.meta.dirname

   Import.meta.filename

Which were added during the lifecycle of Node.js 21.

Another addition aimed at simplifying the migration path from CJS to ESM is the --experimental-detect-module flag. It can be used to automatically run ES modules when their syntax can be detected. For .js files or extensionless files when there is no indication via the package.json as to the type, it will parse the file to detect the syntax and either run it as CommonJS if uncertain or as ES module it is sure that is the correct type. You can read more about that in:

• [e375063e01] - (SEMVER-MINOR) esm: detect ESM syntax in ambiguous JavaScript (Geoffrey Booth) #50096

Which was added during the lifecycle of Node.js 21.

Finally in Node.js 22 another addition which is meant to simplify the migration path from CJS to ESM is the ability to require synchronous ESM graphs. For modules to be loaded they must be explicitly marked as an ES module and fully synchronous. You can read more about the details in the Node.js API docs.

While we are talking about ES modules it's also a good time to remind people that import assertions have been replaced with import attributes and that import assertions have been removed in Node.js 22. To migrate to the new syntax, replace the assert keyword with with.

   For example,

import "foo" assert { ... }

   should be replaced with

import "foo" with { ... }

You can read more about that in esm: drop support for import assertions.

Deprecations in util

Major releases are an opportunity to deprecate or remove obsolete APIs. The project follows a planned deprecation process with three levels: Documentation-only, runtime, end-of-life. On note, Node.js 22 runtime deprecates a number of util APIs. You can check for APIs that are deprecated by running your application with --throw-deprecation to get a runtime error when a runtime deprecated API is used. It might be a good time to check your usage of the util APIs when upgrading to Node.js 22 and to remove usage of the runtime deprecated APIs.

Watch mode command line option is now stable

Back in our blog post on Node.js 19 we mentioned --watch as one of the interesting additions. It’s worth mentioning that in Node.js 22 watch now been promoted to stable. As a reminder some of the options include:

 --watch
  --watch-path
  --watch-preserve-output

With the core benefit being a faster inner loop develop cycle where you application automatically restarts when you edit watched files.

Additional APIs to reduce need for additional dependencies

Over the last few years the project has added a number of APIs to allow basic use cases to be covered without having to pull in additional dependencies. Examples of this include the argument parser, test runner, web-socket, and most recently Text Styling, which made it in during the lifecycle of Node.js 21. The Text Styling API allows you to format text based on util.inspect.colors, for example:

const { styleText } = require('node:util');
const myMessage = styleText('red', 'This text is red');
console.log(myMessage);

Another recent addition is support for defining environment variables in files, via the --env-file command line option, or programmatically with process.loadEnvFile and util.parseEnv which were also added during the lifecycle of Node.js 21. These allow you to easily load .env files or content in .env format. For example:

const { loadEnvFile } = require('node:process');
loadEnvFile();

Platform support

This release retains the same minimum supported levels for platforms and tooling used to build Node.js as Node.js 21. The Node.js building instructions document the minimum levels. For those who use the Red Hat Node.js binaries or containers, changes to the minimum supported levels will not affect you as Red Hat builds and makes available binaries that match Fedora and RHEL major versions through rpms and containers.

Dependency updates

If you take a look at the changelog you’ll see lots of updates to the dependencies Node.js pulls in. Thanks to work of the security working group (and Marco in particular) much of this is now automated (those shown below as being submitted by GitHub Bot). This means the project is keeping on top of dependency updates. As a few examples in this release:

• [cf629366b9] - deps: update simdutf to 5.2.3 (Yagiz Nizipli) #52381
• [ad86a12964] - deps: upgrade npm to 10.5.1 (npm team) #52351
• [45cc32c9c6] - deps: update c-ares to 1.28.1 (Node.js GitHub Bot) #52285
• [38161c38d9] - deps: update zlib to 1.3.0.1-motley-24c07df (Node.js GitHub Bot) #52199
• [1264414700] - deps: update simdjson to 3.8.0 (Node.js GitHub Bot) #52124
• [70a05103c8] - deps: update zlib to 1.3.0.1-motley-24342f6 (Node.js GitHub Bot) #52123
• [0b4cdb4b42] - deps: update ada to 2.7.7 (Node.js GitHub Bot) #52028
• [b241a1d0ae] - deps: update simdutf to 4.0.9 (Node.js GitHub Bot) #51655
• [36dcd399c0] - deps: upgrade libuv to 1.48.0 (Santiago Gimeno) #51697
• [8cf313cd72] - deps: update undici to 6.6.0 (Node.js GitHub Bot) #51630
• [dd4767f99f] - deps: update undici to 6.4.0 (Node.js GitHub Bot) #51527
   

Security and supply chain security

While security and supply chain security have always been important, there has been growing awareness and interest in these areas in recent years. Within the Node.js project, a significant amount of effort is devoted to security-related work, ranging from identifying and resolving vulnerabilities to executing security releases.

We’d like to express our appreciation to the companies and individuals who have stepped up to help with security releases as security release stewards or as part of the security triage team, the Release Working Group, and all those who contribute to the security release efforts. While major releases gather considerable attention, security releases are equally essential. We’d like to see more companies committing to help with security triage, security stewardship, and fixing vulnerabilities.

On the good news front, funding from the Open Source Security Foundation (OSSF) was renewed for 2024 and continues to allow the project to better keep on top of fixing vulnerabilities and to accelerate progress on key initiatives including:

• Automation of security releases
• Assessment against best practices
• Auditing of dependency build processes

In line with what is important to our customers, Red Hat is proud to be doing part of this work through our involvement in the triage team, doing security releases and contributing to the efforts of the security working group team along with all of the other contributors across the project.

Next-10

While major releases are the time people look at what’s new, it’s also important to look forward to what’s coming in the future. The project is working on that as part of the Next-10 effort and has defined the constituencies, needs of those constituencies and the technical priorities based on those needs. For this year the Next-10 team is planning to look more at non-technical aspects of the project like:

• Advocacy and promotion for the project
• Corporate support and contribution
• Growing and building new contributors

In addition, just like last year the Next-10 team will be doing a survey, supported by the OpenJS foundation. The survey went live today. We hope you participate so that the next-10 team can incorporate your feedback into future work.

A big thank you

Our gratitude goes out to every individual involved in the release of Node.js. The Node.js project has a diverse group of contributors who work tirelessly, and each release is a culmination of their collective efforts.

Wrapping up

The community changelog for Node.js 22.0.0 and OpenJS blog post contain more details about the latest enhancements and modifications.

For further insights on the Node.js community and ways to participate, visit the project repository and website. To explore Red Hat's involvement in the Node.js space, refer to the Red Hat Node.js Developers page. Additionally, Red Hat customers can refer to the customer portal for additional information.