Chapter 2. Features

This release includes an upgrade of the V8 JavaScript engine to v11.3, which is part of Chromium 113.

The upgraded V8 JavaScript engine includes the following new features and enhancements:

For more information about the changes that are available in the V8 JavaScript Engine, see the V8 blog.

Red Hat build of Node.js 20 provides the test runner module as a stable feature that you can use in production environments. In earlier releases, the test runner module was available as an experimental feature only.

The test runner module is not intended to replace full-featured test frameworks such as Jest or Mocha. The test runner module offers a quick and easy way to write and run a test suite without needing to install additional dependencies.

In Red Hat build of Node.js 20, the test runner module includes the following types of enhancements:

For more information, see the Node.js Test Runner documentation.

In Red Hat build of Node.js 20, ECMAScipt modules (ESM) hooks that you supply through a loader (for example, --experimental-loader=myhook.mjs) run on a dedicated thread, which is separate from the main application thread. By providing a separate scope for loaders, this enhancement protects the application code from potential contamination.

In Red Hat build of Node.js 20, the import.meta.resolve() function returns values synchronously. However, depending on your preferences, you can still define custom loader resolve hooks as either synchronous or asychronous functions. Even if asynchronous resolve hooks are loaded, the import.meta.resolve() function returns values synchronously for application code.

In Red Hat build of Node.js 20, the Web Crypto API coerces and validates function arguments based on their WebIDL definitions, similar to other implementations of the Web Crypto API. This enhancement helps to improve interoperability between Node.js and browser implementations of the Web Crypto API.

From Red Hat build of Node.js 20 onward, the import.meta.resolve(specifier) property no longer relies on the use of the --experimental-import-meta-resolve command-line interface (CLI) flag by default. You can now use the import.meta.resolve(specifier) property to get an absolute string to which the specifier string resolves, which is similar to the require.resolve functionality in CommonJS modules. This enhancement helps to align Node.js with browsers and other server-side runtimes.

For more information, see the Node.js import.meta.resolve documentation.

Red Hat build of Node.js 20 provides a new module.register(specifier[, parentURL][, options]) method that is part of the node:module API. You can use this new method to specify a file that exports module customization hooks, pass data to the hooks, and establish communication channels with these hooks. This enhancement supersedes the behavior in previous releases, which required the use of an --experimental-loader flag to specify the file that exported the hooks.

To ensure that customization hooks are registered before any application code runs, consider using the --import flag when running applications that use the register functionality.

For example:

node --import ./file-that-calls-register.js ./app.js

For more information, see the Node.js module.register documentation.

Red Hat build of Node.js 20 enables authors of module customization hooks to handle both ESM and CommonJS sources in the load hook. This enhancement is available for CommonJS modules that are referenced by using an import or require statement when the main entry point of the application is handled by the ESM loader. For example, in situations where the entry point is an ESM file or when you use the --import flag, this enhancement is relevant. This helps to simplify the customization of the Node.js loading process, because package authors can perform additional Node.js customization without needing to rely on deprecated APIs, such as require.extensions.

For more information, see the Node.js Hooks: load documentation.

Red Hat build of Node.js 20 enhances the performance of readable and writable streams. This enhancement includes improvements such as reduced memory overhead, improved async iterator consumption for readable streams, and improved pipeTo consumption for readable streams.

This release includes the runtime deprecation of url.parse() method calls that contain invalid ports. In previous releases, the url.parse() method accepted URLs that contained non-numeric port values, which could result in hostname spoofing with unexpected inputs. In this release, if a URL contains a non-numeric port value, the url.parse() method emits a warning.

For more information, see the Node.js url.parse documentation.

The experimental WebAssembly System Interface (WASI) feature includes the following enhancements in this release:

For more information, see the Node.js WebAssembly System Interface (WASI) documentation.

Red Hat build of Node.js 20 introduces an experimental Permission Model feature. This feature enables developers to restrict access to specific resources such as file system operations, child process spawning, and worker thread creation during program execution. This means that you can prevent your applications from accessing or modifying sensitive data or running potentially harmful code.

You can enable the Permission Model feature by using a --experimental-permission CLI flag. By enabling this feature, you automatically restrict access to all available permissions.

To manage permissions, you can use the following CLI flags:

For more information, see the Node.js Permission Model documentation.

Red Hat build of Node.js 20 introduces the TracingChannel class as an experimental extension to the Diagnostics Channel feature. Tracing channels help to group diagnostic channels, which represent different points in the execution lifecycle of a single traceable action, for use in generating and consuming trace data. Tracing channels therefore help to formalize and simplify the process of producing events for tracing application flow.

For more information, see the Node.js TracingChannel documentation.

Red Hat build of Node.js 20 introduces an experimental Mock Timers feature that enables developers to write more predictable and reliable tests for functionality that relies on timers. Timer mocking is a commonly used technique to simulate and test timer behavior without needing to wait for the specified time intervals. The Mock Timers feature includes a MockTimers class that enables you to simulate calls to the setTimeout() and setInterval() methods from global objects and from the node:timers and node:timers/promises API.

The Mock Timers feature provides a simple API to advance time, enable specific timers, and release all timers.

For example:

import assert from 'node:assert';
import { test } from 'node:test';

test('mocks setTimeout to be executed synchronously without having to actually wait for it', (context) => {
  const fn = context.mock.fn();
  // Optionally choose what to mock
  context.mock.timers.enable(['setTimeout']);
  const nineSecs = 9000;
  setTimeout(fn, nineSecs);

  const threeSeconds = 3000;
  context.mock.timers.tick(threeSeconds);
  context.mock.timers.tick(threeSeconds);
  context.mock.timers.tick(threeSeconds);

  assert.strictEqual(fn.mock.callCount(), 1);

For more information, see the Node.js Mocking: Timers documentation.

Red Hat build of Node.js 20 introduces an experimental feature for configuring environment variables in a .env file that is passed to the Node.js application at startup. Similar to .ini file format, each line in a .env configuration file contains a key-value pair for a specific environment variable. For example:

PASSWORD=nodejs

You can initialize and run your Node.js application with predefined environment variables by using the --env-file flag. For example:

node --env-file=myconfig.env myapp.js

When you initialize your application as shown in the preceding example, you can access the relevant environment variables by using the process.env property. For example, to access the PASSWORD=node.js environment variable, you can use the process.env.PASSWORD property.

This enhancement also enables you to define the NODE_OPTIONS environment variable in a .env configuration file, which eliminates the need to include NODE_OPTIONS in the package.json file.