Today, the Node.js community is releasing Node.js 15 with new features that are important to Node.js users and customers. While it won’t be promoted to long-term support (LTS), we need our customers and the greater ecosystem to try it out and give us feedback to help pave the way for the Node.js 16 release.
Some of the new features and ongoing work in the 15 release include:
- Updated handling of rejections
- npm 7
- N-API Version 7
- Refinement of the Async Local Storage APIs
- V8 8.6
Updated handling of rejections
In previous versions of Node.js, if there was an unhandled rejection, you would get a warning about the rejection and a deprecation warning.
For example, the following example:
new Promise((resolve, reject) => {
reject('error');
});
would result in this deprecation message:
(node:31727) UnhandledPromiseRejectionWarning: error
(node:31727) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:31727) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
You can avoid these warning messaging by handling the rejection with a catch block:
new Promise((resolve, reject) => {
reject('error');
}).catch((error) => {});
As of Node.js 15, the default behavior has changed to :
node:internal/process/promises:218
triggerUncaughtException(err, true /* fromPromise */);
^
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "error".] {
code: 'ERR_UNHANDLED_REJECTION'
}
We made this change to align with community expectations and to help surface problems that would otherwise be hard to locate and debug. It brings behavior of unhandled rejections in line with that for unhandled exceptions where we’ve seen the throw behavior being helpful.
While the default has changed, Node.js allows you to configure the default behavior for unhandled rejections through the --unhandled-rejections flag. If you need to revert to the previous default, simply add the following command line: --unhandled-rejections=warn or through the NODE_OPTIONS evironment variable export NODE_OPTIONS=--unhandled-rejections=warn.
You can also handle the unhandled rejection by adding an unhandledRejection listener:
process.on('unhandledRejection', (reason, promise) => {
// do something
});
npm 7
npm 7 is a major release that comes with new features including workspaces and improved support for package lock file. One new change with npm 7 is that peer dependencies are installed by default. (If you want to delve into the details of why or how, read the Install Peer Dependencies blog post.
While the npm team has worked to minimize potential disruption to existing projects due to the switch to automatically installing peer dependencies, if you run into problems, you can use the --legacy-peer-deps flag at install time as a workaround to revert to the previous behavior. You can also set it in the environment or npm config files as outlined in the npm documentation.
For more complete information about the npm 7 release, read their release blog: Presenting v7.0.0 of the npm CLI.
N-API Version 7
Node.js 15 makes it easier to create, build, and support native modules (also known as addons). IBM and Red Hat are ongoing contributors to N-API, and Node 15 comes with N-API version 7, which brings additional methods for working with array buffers:
napi_status napi_detach_arraybuffer(napi_env env,
napi_value arraybuffer)
napi_status napi_is_detached_arraybuffer(napi_env env,
napi_value arraybuffer,
bool* result)
Of note, the node-addon-api, which is one of the ways to consume N-API, recently surpassed 2 million downloads per week! For more information about N-API, check out the API docs and node-addon-api.
Refinement of the Async Local Storage APIs
In the Node.js 14.x release blog, I highlighted the addition of the Async Local Storage API. We’ve continued to refine and community test this API during the 15.x timeline. The API is still experimental at this time, but please try it out.
This is an important feature for enterprise customers that need cross-process transaction tracing and deeper insights in their large applications. It will ensure Node.js provides supported APIs and a first-class experience for companies using open source solutions like OpenTelemetry, as well as other application performance management solutions (APMs).
Node.js 14.x becomes the next LTS version
Just as exciting, next week the Node.js 14.x release goes LTS so you can more easily use its features in production! Node.js 14.x brings a number of great additions, but I’m particularly excited that:
- Diagnostic Report as a stable feature is available in 14.x. Customers are already using the easy-to-consume diagnostic report to solve their problems faster. In one recent example, a customer provided a Diagnostic Report when they reported their issue, and we were able to diagnose and provide a solution quickly without having to waste time trying to get additional information. This is a great example of how the summary level information in the report can you help diagnose and resolve issues more quickly.
- There will be an LTS release with full ICU data built in, simplifying large-scale multi-language deployments.
IBM’s strategy with our Node.js involvement 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 nets, and key features. As one of the top runtimes for cloud-native deployments, Node.js is crucial to IBM and Red Hat’s hybrid cloud and OpenShift work.
The 14.x release delivers in a number of those areas and you can read more about all the new features in 14.x that you can now use in an LTS release in: Node.js 14 release: New diagnostic tools, features, and performance enhancements.
Thanks to our great team
In closing, I’d like to thank the release team including Bethany Griggs from Red Hat who managed the 15.x release for all of their hard work in releasing Node.js 15. I’d also like to thank the supporting cast from the build working group and, of course, the individual contributors as well.
How you can contribute to Node.js
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 package developer or end user, I ask that you help out by testing early and often and provide feedback to the Node.js project.
Our regular, 6-month (April and October) major release cycle provides a good opportunity to test out releases in advance so that when a release is promoted to LTS, there are no surprises. We need your help in doing that testing. Once a release is in LTS, consider testing your applications and packages regularly on the LTS versions in order to ensure a good experience for end users who are migrating to those versions. If you find issues please report them by opening an issue in the Node.js repository.
If you are a package maintainer, please 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.
We’ve also recently created a new Node.js Triage Role to help us manage our backlog of issues. This is a great way to start contributing to the project.
Originally published: https://developer.ibm.com/languages/node-js/blogs/nodejs-15-release-blog/
#node #javascript #programming #developer #web-development
