Updatify / Node.js | Release notes

Notable Changes

Update root certificates to NSS 3.104

This is the version of NSS that shipped in Firefox 131.0 on 2024-10-01.

Certificates added:

• FIRMAPROFESIONAL CA ROOT-A WEB
• TWCA CYBER Root CA
• SecureSign Root CA12
• SecureSign Root CA14
• SecureSign Root CA15

Other notable changes

• [fa61dced44] - doc: move typescript support to active development (Marco Ippolito) #55536
• [9dcca5441b] - doc: add jazelly to collaborators (Jason Zhang) #55531
• [f628fc43cb] - (SEMVER-MINOR) fs: make dirent.path writable (Antoine du Hamel) #55547
• [25b1422337] - (SEMVER-MINOR) http: add diagnostic channel http.client.request.created (Marco Ippolito) #55586
• [adda37f00c] - (SEMVER-MINOR) module: add findPackageJSON util (Jacob Smith) #55412

Notable Changes

This release marks the transition of Node.js 22.x into Long Term Support (LTS) with the codename ‘Jod’. The 22.x release line now moves into “Active LTS” and will remain so until October 2025. After that time, it will move into “Maintenance” until end of life in April 2027.

Other than updating metadata, such as the process.release object, to reflect that the release is LTS, no further changes from Node.js 22.10.0 are included.

OpenSSL 3.x

Official binaries for Node.js 22.x currently include OpenSSL 3.0.x (more specifically, the quictls OpenSSL fork). OpenSSL 3.0.x is the currently designated long term support version that is scheduled to be supported until 7th September 2026, which is within the expected lifetime of Node.js 22.x. We are expecting upstream OpenSSL to announce a successor long term support version prior to that date and since OpenSSL now follows a semantic versioning-like versioning scheme we expect to be able to update to the next long term supported version of OpenSSL during the lifetime of Node.js 22.x.

Notable Changes

Buffer now work with resizable ArrayBuffer

When a Buffer is created using a resizable ArrayBuffer, the Buffer length will now correctly change as the underlying ArrayBuffer size is changed.

const ab = new ArrayBuffer(10, { maxByteLength: 20 });
const buffer = Buffer.from(ab);
console.log(buffer.byteLength); 10
ab.resize(15);
console.log(buffer.byteLength); 15
ab.resize(5);
console.log(buffer.byteLength); 5

Contributed by James M Snell in #55377.

MockTimers test runner API is now stable

MockTimers, introduced in April 2023, has just reached stable status. This API provides comprehensive support for mocking Date and all major timers in Node.js, including setTimeout, setInterval, and setImmediate, both from the node:timers, node:timers/promises modules and global objects. After months of refinement, developers can now fully rely on MockTimers for testing time-based operations with confidence, ensuring better control over asynchronous behavior in their Node.js applications.

Example usage with initial Date object as time set:

import { mock } from 'node:test';
mock.timers.enable({ apis: ['Date'], now: new Date('1970-01-01') });

Contributed by Erick Wendel in #55398.

JSON modules and import attributes are now stable

The two proposals reached stage 4 of the TC39 process, at the October 2024

Notable Changes

New "module-sync" exports condition

This release introduces a "module-sync" exports condition that’s enabled when require(esm) is enabled, so packages can supply a synchronous ES module to the Node.js module loader, no matter if it’s being required or imported. This is similar to the "module" condition that bundlers have been using to support require(esm) in Node.js, and allows dual-package authors to opt into ESM-first only on newer versions of Node.js that supports require(esm) to avoid the dual-package hazard.

{
  "type": "module",
  "exports": {
    "node": {
      // On new version of Node.js, both require() and import get
      // the ESM version
      "module-sync": "./index.js",
      // On older version of Node.js, where "module-sync" and require(esm) are
      // not supported, use the CJS version to avoid dual-package hazard.
      // When package authors think it's time to drop support for older versions of
      // Node.js, they can remove the exports conditions and just use "main": "index.js".
      "default": "./dist/index.cjs"
    },
    // On any other environment, use the ESM version.
    "default": "./index.js"
  }
}

Or if the package is only meant to be run on Node.js and wants to fallback to CJS on older versions that don’t have require(esm):

{
  "type": "module",
  "exports": {
    // On new version of Node.js, both require() and import get the ESM version
    "module-sync": "./index.js",

We’re excited to announce the release of Node.js 23! Key highlights include:

• Enabling require(esm) by default for Node.js applications
• Removing support for Windows 32-bit systems
• Stabilizing the node --run command
• Enhancements to the test runner, including glob pattern support for coverage files

Node.js 23 will replace Node.js 22 as the ‘Current’ release line when Node.js 22 enters long-term support (LTS) later this month. According to the release schedule, Node.js 23 will remain the ‘Current’ release for the next six months, until April 2025.

Other Notable Changes

• [7ad0cc3e57] - (SEMVER-MAJOR) build: remove support for 32-bit Windows (Michaël Zasso) #53184
• [83eb4f2855] - (SEMVER-MINOR) deps: V8: cherry-pick cd10ad7cdbe5 (Joyee Cheung) #52535
• [b8493a5789] - doc: add abmusse to collaborators (Abdirahim Musse) #55086
• [7fab6e8885] - (SEMVER-MAJOR) doc: use gcc 12 on AIX for Node.js >=23 (Richard Lau) #54338

Notable Changes

Experimental Network Inspection Support in Node.js

This update introduces the initial support for network inspection in Node.js. Currently, this is an experimental feature, so you need to enable it using the --experimental-network-inspection flag. With this feature enabled, you can inspect network activities occurring within a JavaScript application.

To use network inspection, start your Node.js application with the following command:

$ node --inspect-wait --experimental-network-inspection index.js

Please note that the network inspection capabilities are in active development. We are actively working on enhancing this feature and will continue to expand its functionality in future updates.

• Network inspection is limited to the http and https modules only.
• The Network tab in Chrome DevTools will not be available until the feature request on the Chrome DevTools side is addressed.

Contributed by Kohei Ueno in #53593 and #54246

Exposes X509_V_FLAG_PARTIAL_CHAIN to tls.createSecureContext

This releases introduces a new option to the API tls.createSecureContext. From now on, tls.createSecureContext({ allowPartialTrustChain: true }) can be used to treat intermediate (non-self-signed) certificates in the trust CA certificate list as trusted.

New API to retrieve execution Stack Trace

A new API getCallSite has been introduced to the util module. This API allows users to retrieve the stacktrace of the current execution. Example:

const util = require('node:util');

function exampleFunction() {
  const callSites = util.getCallSite();

  console.log('Call Sites:');
  callSites.forEach((callSite, index) => {
    console.log(`CallSite ${index + 1}:`);
    console.log(`Function Name: ${callSite.functionName}`);
    console.log(`Script Name: ${callSite.scriptName}`);
    console.log(`Line Number: ${callSite.lineNumber}`);
    console.log(`Column Number: ${callSite.column}`);
  });
  // CallSite 1:
  // Function Name: exampleFunction
  // Script Name: /home/example.js
  // Line Number: 5
  // Column Number: 26

  // CallSite 2:
  // Function Name: anotherFunction
  // Script Name: /home/example.js
  // Line Number: 22
  // Column Number: 3

  // ...
}

// A function to simulate another stack layer
function anotherFunction() {
  exampleFunction();
}

anotherFunction();

Thanks to Rafael Gonzaga for making this work on #54380.

Disable V8 Maglev

We have seen several crashes/unexpected JS behaviors with maglev on v22 (which ships V8 v12.4). The bugs lie in the codegen so it would be difficult for users to work around them or even figure out where the bugs are coming from. Some bugs are fixed in the upstream while some others probably remain.

New JS API for compile cache

This release adds a new API module.enableCompileCache() that can be used to enable on-disk code caching of all modules loaded after this API is called. Previously this could only be enabled by the NODE_COMPILE_CACHE environment variable, so it could only set by end-users. This API allows tooling and library authors to enable caching of their own code. This is a built-in alternative to the v8-compile-cache/v8-compile-cache-lib packages, but have better performance and supports ESM.

Thanks to Joyee Cheung for working on this.

New option for vm.createContext() to create a context with a freezable globalThis

Node.js implements a flavor of vm.createContext() and friends that creates a context without contextifying its global object when vm.constants.DONT_CONTEXTIFY is used. This is suitable when users want to freeze the context (impossible when the global is contextified i.e. has interceptors installed) or speed up the global access if they don’t need the interceptor behavior.

Thanks to Joyee Cheung for working on this.

Support for coverage thresholds

Node.js now supports requiring code coverage to meet a specific threshold before the process exits successfully. To use this feature, you need to enable the --experimental-test-coverage flag.

Experimental transform types support

With the new flag --experimental-transform-types it is possible to enable the transformation of TypeScript-only syntax into JavaScript code.

This feature allows Node.js to support TypeScript syntax such as Enum and namespace.

Thanks to Marco Ippolito for making this work on #54283.

Module syntax detection is now enabled by default.

Module syntax detection (the --experimental-detect-module flag) is now enabled by default. Use --no-experimental-detect-module to disable it if needed.

Syntax detection attempts to run ambiguous files as CommonJS, and if the module fails to parse as CommonJS due to ES module syntax, Node.js tries again and runs the file as an ES module. Ambiguous files are those with a .js or no extension, where the nearest parent package.json has no "type" field (either "type": "module" or "type": "commonjs"). Syntax detection should have no performance impact on CommonJS modules, but it incurs a slight performance penalty for ES modules; add "type": "module" to the nearest parent package.json file to eliminate the performance cost. A use case unlocked by this feature is the ability to use ES module syntax in extensionless scripts with no nearby package.json.

Thanks to Geoffrey Booth for making this work on #53619.

Performance Improvements to Buffer

module: support require()ing synchronous ESM graphs

This release adds require() support for synchronous ESM graphs under the flag --experimental-require-module.

If --experimental-require-module is enabled, and the ECMAScript module being loaded by require() meets the following requirements:

• Explicitly marked as an ES module with a “type”: “module” field in the closest package.json or a .mjs extension.
• Fully synchronous (contains no top-level await).

require() will load the requested module as an ES Module, and return the module name space object. In this case it is similar to dynamic import() but is run synchronously and returns the name space object directly.

Contributed by Joyee Cheung in #51977

path: add matchesGlob method

Glob patterns can now be tested against individual paths via the path.matchesGlob(path, pattern) method.

Contributed by Aviv Keller in #52881

stream: expose DuplexPair API

The function duplexPair returns an array with two items, each being a Duplex stream connected to the other side:

const [ sideA, sideB ] = duplexPair();

Whatever is written to one stream is made readable on the other. It provides behavior analogous to a network connection, where the data written by the client becomes readable by the server, and vice-versa.

Experimental TypeScript support via strip types

Node.js introduces the --experimental-strip-types flag for initial TypeScript support. This feature strips type annotations from .ts files, allowing them to run without transforming TypeScript-specific syntax. Current limitations include:

• Supports only inline type annotations, not features like enums or namespaces.
• Requires explicit file extensions in import and require statements.
• Enforces the use of the type keyword for type imports to avoid runtime errors.
• Disabled for TypeScript in node_modules by default.

Thanks Marco Ippolito for working on this.

Experimental Network Inspection Support in Node.js

This update introduces the initial support for network inspection in Node.js. Currently, this is an experimental feature, so you need to enable it using the --experimental-network-inspection flag. With this feature enabled, you can inspect network activities occurring within a JavaScript application.

To use network inspection, start your Node.js application with the following command:

$ node --inspect-wait --experimental-network-inspection index.js

Please note that the network inspection capabilities are in active development. We are actively working on enhancing this feature and will continue to expand its functionality in future updates.

• Network inspection is limited to the http and https modules only.

process: add process.getBuiltinModule(id)

process.getBuiltinModule(id) provides a way to load built-in modules in a globally available function. ES Modules that need to support other environments can use it to conditionally load a Node.js built-in when it is run in Node.js, without having to deal with the resolution error that can be thrown by import in a non-Node.js environment or having to use dynamic import() which either turns the module into an asynchronous module, or turns a synchronous API into an asynchronous one.

if (globalThis.process?.getBuiltinModule) {
  // Run in Node.js, use the Node.js fs module.
  const fs = globalThis.process.getBuiltinModule('fs');
  // If `require()` is needed to load user-modules, use createRequire()
  const module = globalThis.process.getBuiltinModule('module');
  const require = module.createRequire(import.meta.url);
  const foo = require('foo');
}

If id specifies a built-in module available in the current Node.js process, process.getBuiltinModule(id) method returns the corresponding built-in module. If id does not correspond to any built-in module, undefined is returned.

process.getBuiltinModule(id) accepts built-in module IDs that are recognized by module.isBuiltin(id).

The references returned by process.getBuiltinModule(id) always point to the built-in module corresponding to id even if users modify require.cache so that require(id) returns something else.

Notable Changes

This release fixes a regression introduced in Node.js 22.5.0. The problem is known to display the following symptoms:

• Crash with FATAL ERROR: v8::Object::GetCreationContextChecked No creation context available #53902
• npm errors with npm error Exit handler never called! npm/cli#7657
• yarn hangs or outputs Usage Error: Couldn't find the node_modules state file - running an install might help (findPackageLocation) yarnpkg/berry#6398

Commits

• [e2deeedc6e] - Revert “fs: add v8 fast api to closeSync” (Aviv Keller) #53904