Node.js 22 ChangeLog #

LTS 'Jod' Current
22.14.0
22.13.1
22.13.0
22.12.0
22.11.0
 22.10.0
22.9.0
22.8.0
22.7.0
22.6.0
22.5.1
22.5.0
22.4.1
22.4.0
22.3.0
22.2.0
22.1.0
22.0.0

2025-02-11, Version 22.14.0 'Jod' (LTS), @aduh95 #

Notable Changes #

Commits #

2025-01-21, Version 22.13.1 'Jod' (LTS), @RafaelGSS #

This is a security release.

Notable Changes #

Dependency update:

Commits #

2025-01-07, Version 22.13.0 'Jod' (LTS), @ruyadorno #

Notable Changes #

Stabilize Permission Model #

Upgrades the Permission Model status from Active Development to Stable.

Contributed by Rafael Gonzaga #56201

Graduate WebCryptoAPI Ed25519 and X25519 algorithms as stable #

Following the merge of Curve25519 into the Web Cryptography API Editor's Draft the Ed25519 and X25519 algorithm identifiers are now stable and will no longer emit an ExperimentalWarning upon use.

Contributed by (Filip Skokan) #56142

Other Notable Changes #

Commits #

2024-12-03, Version 22.12.0 'Jod' (LTS), @ruyadorno #

Notable Changes #

require(esm) is now enabled by default #

Support for loading native ES modules using require() had been available on v20.x and v22.x under the command line flag --experimental-require-module, and available by default on v23.x. In this release, it is now no longer behind a flag on v22.x.

This feature is still experimental, and we are looking for user feedback to make more final tweaks before fully stabilizing it. For this reason, on v23.x, when the Node.js instance encounters a native ES module in require() for the first time, it will emit an experimental warning unless require() comes from a path that contains node_modules. If there happens to be any regressions caused by this feature, users can report it to the Node.js issue tracker. Meanwhile this feature can also be disabled using --no-experimental-require-module as a workaround.

With this feature enabled, Node.js will no longer throw ERR_REQUIRE_ESM if require() is used to load a ES module. It can, however, throw ERR_REQUIRE_ASYNC_MODULE if the ES module being loaded or its dependencies contain top-level await. When the ES module is loaded successfully by require(), the returned object will either be a ES module namespace object similar to what's returned by import(), or what gets exported as "module.exports" in the ES module.

Users can check process.features.require_module to see whether require(esm) is enabled in the current Node.js instance. For packages, the "module-sync" exports condition can be used as a way to detect require(esm) support in the current Node.js instance and allow both require() and import to load the same native ES module. See the documentation for more details about this feature.

Contributed by Joyee Cheung in #55085

Added resizable ArrayBuffer support in Buffer #

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 Snell in #55377

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:

Contributed by Richard Lau in #55681

SQLite Session Extension #

Basic support for the SQLite Session Extension
got added to the experimental node:sqlite module.

const sourceDb = new DatabaseSync(':memory:');
const targetDb = new DatabaseSync(':memory:');

sourceDb.exec('CREATE TABLE data(key INTEGER PRIMARY KEY, value TEXT)');
targetDb.exec('CREATE TABLE data(key INTEGER PRIMARY KEY, value TEXT)');

const session = sourceDb.createSession();

const insert = sourceDb.prepare('INSERT INTO data (key, value) VALUES (?, ?)');
insert.run(1, 'hello');
insert.run(2, 'world');

const changeset = session.changeset();
targetDb.applyChangeset(changeset);
// Now that the changeset has been applied, targetDb contains the same data as sourceDb.

Of note to distributors when dynamically linking with SQLite (using the --shared-sqlite
flag): compiling SQLite with SQLITE_ENABLE_SESSION and SQLITE_ENABLE_PREUPDATE_HOOK
defines is now required.

Contributed by Bart Louwers in #54181.

Other Notable Changes #

Commits #

2024-10-29, Version 22.11.0 'Jod' (LTS), @richardlau #

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.

2024-10-16, Version 22.10.0 (Current), @aduh95 #

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",
    // 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"
  }
}

For package authors: this only serves as a feature-detection mechanism for
packages that wish to support both CJS and ESM users during the period when some
active Node.js LTS versions support require(esm) while some older ones don't.
When all active Node.js LTS lines support require(esm), packages can simplify
their distributions by bumping the major version, dropping their CJS exports,
and removing the module-sync exports condition (with only main or default
targetting the ESM exports). If the package needs to support both bundlers and
being run unbundled on Node.js during the transition period, use both
module-sync and module and point them to the same ESM file. If the package
already doesn't want to support older versions of Node.js that doesn't support
require(esm), don't use this export condition.

For bundlers/tools: they should avoid implementing this stop-gap condition.
Most existing bundlers implement the de-facto bundler standard
module
exports condition, and that should be enough to support users who want to bundle
ESM from CJS consumers. Users who want both bundlers and Node.js to recognize
the ESM exports can use both module/module-sync conditions during the
transition period, and can drop module-sync+module when they no longer need
to support older versions of Node.js. If tools do want to support this
condition, it's recommended to make the resolution rules in the graph pointed by
this condition match the Node.js native ESM rules to avoid divergence.

We ended up implementing a condition with a different name instead of reusing
"module", because existing code in the ecosystem using the "module"
condition sometimes also expect the module resolution for these ESM files to
work in CJS style, which is supported by bundlers, but the native Node.js loader
has intentionally made ESM resolution different from CJS resolution (e.g.
forbidding import './noext' or import './directory'), so it would be
breaking to implement a "module" condition without implementing the forbidden
ESM resolution rules. For now, this just implements a new condition as
semver-minor so it can be backported to older LTS.

Contributed by Joyee Cheung in #54648.

node --run is now stable #

This CLI flag runs a specified command from a package.json's "scripts" object.

For the following package.json:

{
  "scripts": {
    "test": "node --test-reporter junit --test ./test"
  }
}

You can run node --run test and that would start the test suite.

Contributed by Yagiz Nizipli in #53763.

Other notable changes #

Commits #

2024-09-17, Version 22.9.0 (Current), @RafaelGSS #

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.

As v22 will get stuck with V8 v12.4 as LTS, it will be increasingly difficult to
backport patches for them even if the bugs are fixed. So disable it by default
on v22 to reduce the churn and troubles for users.

Thanks to Joyee Cheung for making this work on #54384

Exposes X509_V_FLAG_PARTIAL_CHAIN to tls.createSecureContext #

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

Thanks to Anna Henningsen for making this work on #54790

Other Notable Changes #

Deprecations #

Commits #

2024-09-03, Version 22.8.0 (Current), @RafaelGSS #

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.

You can set thresholds for the following types of coverage:

<threshold> should be an integer between 0 and 100. If an invalid value is provided, a TypeError will be thrown.

If the code coverage fails to meet the specified thresholds for any category, the process will exit with code 1.

For instance, to enforce a minimum of 80% line coverage and 60% branch coverage, you can run:

$ node --experimental-test-coverage --test-coverage-lines=80 --test-coverage-branches=60 example.js

Thanks Aviv Keller for working on this.

Other Notable Changes #

Commits #

2024-08-22, Version 22.7.0 (Current), @RafaelGSS #

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 #

Performance of Node.js Buffers have been optimized through multiple PR's with significant
improvements to the Buffer.copy and Buffer.write methods. These are used throughout
the codebase and should give a nice boost across the board.

Thanks to Robert Nagy for making this work on #54311,
#54324, and #54087.

Other Notable Changes #

Commits #

2024-08-06, Version 22.6.0 (Current), @RafaelGSS #

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:

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.

Thanks Kohei Ueno for working on this.

Other Notable Changes #

Commits #

2024-07-19, Version 22.5.1 (Current), @richardlau #

Notable Changes #

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

Commits #

2024-07-17, Version 22.5.0 (Current), @RafaelGSS prepared by @aduh95 #

Notable Changes #

Commits #

2024-07-08, Version 22.4.1 (Current), @RafaelGSS #

This is a security release.

Notable Changes #

Commits #

2024-07-02, Version 22.4.0 (Current), @targos #

Notable Changes #

Experimental Web Storage API #

API stability updates #

Other Notable Changes #

Commits #

2024-06-11, Version 22.3.0 (Current), @RafaelGSS #

Notable Changes #

Commits #

2024-05-15, Version 22.2.0 (Current), @targos #

Notable Changes #

Commits #

2024-05-02, Version 22.1.0 (Current), @targos prepared by @aduh95 #

module: implement NODE_COMPILE_CACHE for automatic on-disk code caching #

This patch implements automatic on-disk code caching that can be enabled
via an environment variable NODE_COMPILE_CACHE=/path/to/cache/dir.

When set, whenever Node.js compiles a CommonJS or a ECMAScript Module,
it will use on-disk V8 code cache
persisted in the specified directory
to speed up the compilation. This may slow down the first load of a
module graph, but subsequent loads of the same module graph may get
a significant speedup if the contents of the modules do not change.
Locally, this speeds up loading of test/fixtures/snapshot/typescript.js
from ~130ms to ~80ms.

To clean up the generated code cache, simply remove the directory.
It will be recreated the next time the same directory is used for
NODE_COMPILE_CACHE.

Compilation cache generated by one version of Node.js may not be used
by a different version of Node.js. Cache generated by different versions
of Node.js will be stored separately if the same directory is used
to persist the cache, so they can co-exist.

Caveat: currently when using this with V8 JavaScript code coverage, the
coverage being collected by V8 may be less precise in functions that are
deserialized from the code cache. It's recommended to turn this off when
running tests to generate precise coverage.

Contributed by Joyee Cheung in #52535.

Other Notable Changes #

Commits #

2024-04-24, Version 22.0.0 (Current), @RafaelGSS and @marco-ippolito #

We're excited to announce the release of Node.js 22!
Highlights include require()ing ESM graphs, WebSocket client, updates of the V8 JavaScript engine, and more!
As a reminder, Node.js 22 will enter long-term support (LTS) in October, but until then, it will be the "Current" release for the next six months.
We encourage you to explore the new features and benefits offered by this latest release and evaluate their potential impact on your applications.

Other Notable Changes #

Semver-Major Commits #

Semver-Minor Commits #

Semver-Patch Commits #