Welcome Node.js 18

It’s that time of year again where the Node.js community releases a new major release - Node.js 18. Following the well defined release process, this version will be promoted to long-term support (LTS) in October 2022. Before then, we need the greater ecosystem to try it out and give the community feedback. This will allow us to address any issues in advance and make sure both the release, the ecosystem, and our customers are ready when it’s promoted.

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 our community work 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

Those aspects,along with working with our customers and internal teams and sharing our experience in the Node.js reference architecture, keeps us pretty busy.

For the Node.js 18 release I’ll highlight some of the new features and ongoing work in the 18 timeframe and where our team’s been involved.Interesting new features  include:

• Experimental Fetch 
• Test Runner
• ECMAScript modules improvements
• Improved support for AbortController and AbortSignal
• Updated Platform Support
• V8 Version 10.1
• OPENSSL 3 Support
• Default DNS resolution 

As you can see from the list, there is lots going on, with new experimental features like Fetch and Test Runner support and ongoing progress on some of the larger efforts like support for ECMAScript modules. Add to this updated platform support, a new version of V8 and updated cryptographic support, which are a common feature of most releases and we can see that Node.js development is moving ahead at a good pace.

The use of Node.js also continues to grow with almost 2 billion downloads of Node.js binaries and containers that we know about in the last year (based on our informal count using the Node.js download data and Docker hub pulls). In the context of Red Hat customers, we see continued growth in the downloads of Red Hat Node.js containers with a growth of almost 92% last year.

New features

Experimental Fetch 

Soon after the Next-10 mini-summit on Modern HTTP and Documentation, an experimental implementation of the WHATWG Fetch was added. In the summit it was agreed that we needed a high level and a low level API and that Fetch was the right answer for the high level API. Making a request is as simple as:

  const resp = await fetch(url)

You can read more about the people who contributed to make this happen in the community blog post. Many thanks for their hard work. 

Experimental test runner

Node.js 18 includes an experimental test runner. It’s not intended to replace full featured alternatives like Jest or Mocha, but does offer a quick and easy way to run a test suite without any additional dependencies. It provides TAP output which is widely used and makes it easy to consume the output. You can read more about it in the community blog post and the Node.js API docs.

ECMAScript modules improvements

Since the introduction of ECMAScript module support, Node.js has continued to work on improvements. Some interesting additions since Node.js 17 include:

• JSON Import Assertions in line with the TC39 proposal
• A command line flag is no longer needed to use esm json modules (although it is still experimental)
• Experimental support for HTTPS and HTTP impo1998e83983rts under the --experimental-network-imports flag.

Work on larger initiatives like loaders and diagnostic channel are also underway in order to help improve observability when using ECMAScript modules.

Improving support for AbortController and AbortSignal

While AbortController and AbortSignal are not new in Node.js 18, work continues to expand support in the Node.js codebase. By our count there were 11 SemVer minor PRs adding functionality related to AbortSignal.

As an example, with the newly added AbortSignal.timeout(), you can now easily abort an HTTP request when using fetch with

const resp =  

await fetch('http://slowsite.com', {signal: AbortSignal.timeout(1000)});

You can check out the full list of commits in the release changelog.

Stream improvements

Since the release of Node.js 17, there were 6 SemVer minor and 11 SemVer minor changes. This includes adding a number of Experimental methods to Readable streams such as:

• reduce
• toArray
• forEach
• filter
• isReadable
• some
• every

Platform support

As with most major releases, this release updates the minimum supported levels for platforms and tooling used to build Node.js. Node's building instructions document these new minimum levels. Of note, the minimum glibc level required on Linux has been increased. This was necessary because the Node.js project builds its release binaries on RHEL/Centos (now just RHEL) and RHEL/CENTOS 7 will go out of service before the end of community support for Node.js 18. Thanks to Red Hat’s Richard Lau who put in many hours getting new RHEL 8 machines across the supported platforms into the Node.js community CI system.

For those who use the Red Hat Node.js binaries or containers, this change will not affect you as Red Hat builds and makes available binaries that match Fedora and RHEL major versions through rpms and containers.

V8 JavaScript engine version 10.1

The V8 JavaScript engine is the runtime environment that executes JavaScript code. It's what lets JavaScript run across many platforms so developers don't need to worry about whether their code is running on Linux, Windows, macOS or whether the hardware underneath the OS is x64, Arm, or Power PC. However, V8 is written in C++ and requires the Node community to maintain and improve V8 for assorted operating system and hardware combinations.

Because of this, the Red Hat Node.js team gets a "sneak peek" at what is coming in new versions of the V8 JavaScript engine. As the platform owners for Power PC and s390 directories within V8, we are hard at work making commits every week to keep V8 running on these platforms. It’s great to see that work pay off as new features come to Node.js. For more info on all the new features, keep an eye out for the blog post for all of the V8 versions between 9.6 (the latest version in Node.js 17) and 10.1 in the V8 blog.

OPENSSL 3 support 

Node.js 17 was the first version to use OpenSSL 3 instead of OpenSSL 1.1.1 but it’s worth revisiting as Node.js 18 will be the first major version promoted to LTS with OpenSSL3. Red Hat's Daniel Bevenius and Richard Lau worked diligently to get OpenSSL 3 integrated into the Node.js code base. There are still a few rough edges but we hope that these can be ironed out before Node.js 18 gets promoted to LTS.

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.

Default DNS resolution

This change was also in Node.js 17 but is also worth noting as Node.js 18 will be the first version that will be promoted to LTS and may be the first time our customers run into it. 

For dns lookups, Node.js no longer prefers IPv4 over IPV6. Instead, it will now respect the order that is returned based on the dns entries. For properly configured hosts this should not make a difference but if you have a partially or incorrectly configured IPv6 stack on your hosts you might start seeing problems that were hidden before. The command line option --dns-result-order=ipv4first can be used to revert to the old behavior if necessary.

Looking to the future

While a major release is a good time to look at what’s been accomplished, it’s also important to think about the future. The project has been doing this in the Next-10 effort and as part of that has defined the top 10 priorities:

• Modern HTTP
• Suitable types for end-users
• Documentation
• WebAssembly
• Support for features from latest ECMAScript spec
• Observability
• Permissions/policies/security model
• Better multithreaded support
• Single Executable Applications

Our team has helped the community host a number of mini-summit’s have been held to discuss what’s needed and identify next steps. Those summits have been a great way to make progress (fetch was landed in the project soon after the one on Modern HTTP) and we plan to have the next one at the Node.js collaborator summit at the upcoming OpenJS World conference. We hope to see you there or in the regular Next-10 meetings which can be found on the Node.js Project Calendar.

A big thank you

We’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 18 release. The community has a large cast of contributors working across the Node.js project and each release is the result of all of their hard work.

As a side note, I’d also like to thank the companies/individuals who have stepped up to help with security releases as security release stewards or as part of the security triage team, along with all of those who make security releases happen. The major releases are the big splash, but security releases are just as important. I’d like to see more companies committing to help with security triage, security stewardship as well as fixing vulnerabilities.

Wrapping up

You can read about all the new features and changes from the community post here. To learn more about the Node.js community and to learn how you can contribute, 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, head to the Node.js developers page here. Finally, if you’re a Red Hat customer, visit the customer portal for more information.