This blog was written by Bethany Griggs, with additional contributions from the Node.js Technical Steering Committee and project collaborators.
Node.js 17 is here!
This blog was written by Bethany Griggs, with additional contributions from the Node.js Technical Steering Committee and project collaborators.
We’re excited to announce that Node.js 17 was released today!
Node.js 17 replaces Node.js 16 as our ‘current’ release line, with Node.js 16 being promoted to long-term support (LTS) next week. You can expect new releases of Node.js 17 approximately every two weeks, keeping you up to date with the latest features and changes. As an odd-numbered release line, Node.js 17 will not be promoted to LTS. You can read more about our release policy at https://github.com/nodejs/release.
To download Node.js v17.0.0, visit: https://nodejs.org/en/download/current/. Similarly, you can find the release post at https://nodejs.org/en/blog/release/v17.0.0, which contains the list of commits included in this release.
Some of the new changes and features delivered in Node.js 17 include:
Following our Release Policy, new features that are contributed to the runtime are shipped approximately every two weeks in our ‘current’ release line. This means that the majority of new commits that are included in the initial major release (v17.0.0) are those that involve breaking changes. We care about minimizing the number and disruption of these breaking changes for the stability of the platform and to make version migrations easier for our users.
A continuing strategic initiative within the Node.js project is to provide promise-based Node.js core APIs. In recent years, we have added the Timers Promises API and Streams Promises API (both available since Node.js 15).
In Node.js 17, we introduce promise-based APIs for the Readline module. The readline module provides an interface for reading data from a Readable stream (such as process.stdin) one line at a time.
The following simple example illustrates the basic use of the readline module:
import * as readline from 'node:readline/promises'; import { stdin as input, stdout as output } from 'process'; const rl = readline.createInterface({ input, output }); const answer = await rl.question('What do you think of Node.js? '); console.log(`Thank you for your valuable feedback: ${answer}`); rl.close();
You can read more about the Readline module in the API documentation.
Node.js now includes the recently released OpenSSL 3.0, specifically quictls/openssl, upgraded from OpenSSL 1.1.1. OpenSSL 1.1.1 will reach the end of support on 2023-09-11 (from OpenSSL Release Strategy), which is before our proposed End-of-Life date for Node.js 18 (LTS). For this reason, we have decided to include OpenSSL 3.0 in Node.js 17 to provide time for user testing and feedback before the next LTS release.
Among the new features in OpenSSL 3.0 is the introduction of Providers, of which one is a FIPS provider which can be enabled in Node.js. For details about how to build Node.js with FIPS support please see BUILDING.md.
While OpenSSL 3.0 APIs should be mostly compatible with those provided by OpenSSL 1.1.1, we do anticipate some ecosystem impact due to tightened restrictions on the allowed algorithms and key sizes.
If you hit an ERR_OSSL_EVP_UNSUPPORTED error in your application with Node.js 17, it’s likely that your application or a module you’re using is attempting to use an algorithm or key size which is no longer allowed by default with OpenSSL 3.0. A new command-line option, --openssl-legacy-provider, has been added to revert to the legacy provider as a temporary workaround for these tightened restrictions.
Example usage:
$ ./node --openssl-legacy-provider -p 'crypto.createHash("md4")' Hash { _options: undefined, [Symbol(kHandle)]: Hash {}, [Symbol(kState)]: { [Symbol(kFinalized)]: false } }
For more details on the OpenSSL 3.0 release please see the OpenSSL 3.0 release post.
Stack traces are an essential part of diagnosing application errors, helping to provide visibility into what has gone wrong. In Node.js 17, the Node.js version will be included at the end of the stack trace when there is a fatal exception that causes the process to exit.
It’s useful to provide this by default as often when diagnosing reported errors one of the first questions asked will be “What Node.js version are you using?”
Node.js 17 also comes with a command-line option, --no-extra-info-on-fatal-exception, to omit this extra information.
In Node.js 17.0.0, the V8 JavaScript engine has been updated to V8 9.5. (V8 9.4 is the latest available in Node.js 16).
Along with performance tweaks and improvements, this update comes with additional supported types for Intl.DisplayNames API and Extended timeZoneName options in the Intl.DateTimeFormat API.
You can read more details in the V8 9.5 release post – https://v8.dev/blog/v8-release-95.
Next week, Node.js 16 will be promoted to long-term support. This is a significant milestone, as many users, particularly those operating production deployments, will opt to only use the long-term supported versions of Node.js. This means for the first time some features will be available in a long-term supported release line.
Node.js 16 and later include Corepack, a script that acts as a bridge between Node.js projects and the package managers they are intended to be used with during development. In practical terms, Corepack will let you use Yarn and pnpm without having to install them. Read more about Corepack in the documentation.
In Node.js 16, the V8 JavaScript Engine is V8 9.4. It’s through the V8 JavaScript Engine upgrades that Node.js gains the new JavaScript language features. In Node.js 16, we have gained the following language features:
Other features new to LTS in Node.js 16 include npm 8 and the Experimental Web Streams API.
Node.js 16 is also the first LTS release where we ship prebuilt binaries for Apple Silicon. We provide separate tarballs for the Intel (darwin-x64) and ARM (darwin-arm64) architectures, with the macOS installer (.pkg) shipped as a fat (multi-architecture) binary.
The project is also continuing its Next 10 effort. The goal of this effort is to reflect on what led to success in the first 10 years of Node.js and set the direction for success in the next 10. Initial efforts were focused on defining and documenting the project’s technical values and priorities.
Our next steps on this effort are to host deep-dive sessions on specific topics, with improving documentation and growing our contributions being two of the first topics we plan to discuss.
We welcome you to join our meetings, which can be found on the Node.js Calendar.
Try out the new Node.js 17 release! We’re always happy to hear your feedback. Testing your applications and modules with Node.js 17 helps to ensure the future compatibility of your project with the latest Node.js changes and features.
Now is also a good time to start planning to upgrade to Node.js 16, which is due to be promoted to long-term support next week. Node.js 16 will continue to be supported until April 30th, 2024.
Also of note is that Node.js 12 will go End of Life in April 2021, so we advise you to start planning to upgrade if you are still using Node.js 12.
For the timeline of Node.js releases, check out the Node.js Release Schedule.
Thank you! We’d like to thank all of the Node.js collaborators and contributors, as this release is a sum of all their efforts.
Specifically, thank you to the Node.js Release Working Group for maintaining and producing Node.js releases and the Node.js Build Working Group for keeping the project infrastructure running.