Release Notes for Node.js 22


Red Hat build of Node.js 22

For use with Node.js 22 LTS

Red Hat Customer Content Services

Abstract

This Release Note contains important information related to Node.js 22 LTS.

Preface

Date of release: 2025-02-24

The following infrastructure components are required when using the Red Hat build of Node.js. Except for components that are explicitly designated as supported, Red Hat does not provide support for these components.

Expand
Component nameVersion

Nodeshift

2.1.1

npm 10

10.9.0

OpenShift Container Platform (OCP)[a]

3.11, 4.5

git

2.0 or later

oc command line tool

3.11 or later[b]

[a] OCP is supported by Red Hat
[b] The version of the oc CLI tool should correspond to the version of OCP that you are using.

Chapter 2. Features

This section contains information about feature changes in the Red Hat build of Node.js 22 release.

2.1. New and Changed features

Node.js 22 LTS has the following new features and enhancements that the Red Hat build of Node.js supports.

For detailed changes in Node.js 22 LTS, see the upstream community release notes and documentation.

2.1.1. V8 JavaScript engine upgraded to v12.4

This release includes an upgrade of the V8 JavaScript engine to v12.4, which is part of Chromium 124.

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 22 increases the default high water mark for Node.js streams from 16 KB to 65 KB. This enhancement helps to improve the general performance of Node.js streams.

Note

This enhancement also causes a slight increase in memory usage. If your environment is memory-sensitive, you can change the default value by using setDefaultHighWaterMark().

For more information, see the Node.js new stream.Writable and new stream.Readable documentation.

Red Hat build of Node.js 22 provides more efficient creation of AbortSignal instances. This enhancement greatly improves the performance of the fetch() API and the test runner module.

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

Red Hat build of Node.js 22 enhances the writeFileSync() method by including a highly efficient fast path for UTF-8-encoded string data. This release also uses the improved writeFileSync() functionality to help optimize the appendFileSync() method. This enhancement focuses specifically on maximizing the efficiency of string data operations.

For more information, see the Node.js fs.writeFileSync and fs.appendFileSync documentation.

From the Node.js 17 release onward, Node.js no longer prefers IPv4 addresses over IPv6 addresses. Node.js adheres to the order that is returned based on the domain name search (DNS) entries. This behavior does not typically affect properly configured hosts. However, this behavior might cause issues for hosts that have a partially or incorrectly configured IPv6 stack. Recent releases have aimed to improve the user experience with incorrectly configured IPv6 stacks, by including an implementation of the Happy Eyeballs algorithm and by fixing edge cases.

Red Hat build of Node.js 22 includes three new events for connection attempts in the net.createConnection flow:

  • A connectionAttempt event is emitted when a new connection attempt is established. When using Happy Eyeballs, this event might be emitted multiple times.
  • A connectionAttemptFailed event is emitted when a connection attempt fails. When using Happy Eyeballs, this event might be emitted multiple times.
  • A connectionAttemptTimeout event is emitted when a connection attempt exceeds a specified timeout period. When using Happy Eyeballs, this event is not emitted for the last attempt. If you are not using Happy Eyeballs, this event is never emitted.

Additionally, Red Hat build of Node.js 22 resolves an issue where a new connection attempt could start after a previous attempt failed and the user had already destroyed the connection. This issue caused a failed assertion in earlier releases.

Note

Similar to previous releases, if you encounter an issue, you can revert to the old behavior by using the --dns-result-order=ipv4first CLI option. You can also disable Happy Eyeballs by using the --no-network-family-autoselection option.

For more information, see the Node.js net.Socket documentation.

Red Hat build of Node.js 22 adds support for the deflate-raw parameter in both CompressionStream and DecompressionSteam constructors. The deflate-raw parameter compresses or decompresses the stream by using the DEFLATE algorithm without a header and trailing checksum. This enhancement ensures consistency with the web-streams compression that modern browsers support.

For more information, see the Node.js CompressionStream and DecompressionStream documentation.

2.1.7. Full support for watch mode

Red Hat build of Node.js 22 provides watch mode as a stable feature that you can use in production environments. In earlier releases, watch mode was available as an experimental feature only.

You can run Node.js applications in watch mode by using the node --watch CLI option. Running an application in watch mode means that the process restarts if you modify an imported file, which offers the core benefit of a faster inner loop development cycle.

Watch mode includes the following options:

  • The --watch option starts Node.js in watch mode.
  • The --watch-path option starts Node.js in watch mode and specifies the path to watch.
  • The --watch-preserve-output option disables clearing of the console when watch mode restarts the process.

    Note

    This option also requires use of the --watch or --watch-path option.

For more information, see the Node.js --watch documentation.

2.2. Deprecated features

The following features are deprecated in the Red Hat build of Node.js 22 release.

Note

For more information about deprecated or removed features in this release, see the nodejs.org website.

2.2.1. Support for import assertions

This release removes support for import assertions that use the assert keyword. Import assertions are now superseded by import attributes that use the with keyword. From Red Hat build of Node.js 22 onward, ensure that any occurrences of the assert keyword are replaced by the with keyword.

For example, consider the following statement, where <module_name> represents the name of the module that you want to import:

import "<module_name>" assert { ... }

Replace the preceding example with the following statement:

import "<module_name>" with { ... }

For more information, see the Node.js Import attributes documentation.

2.2.2. Runtime deprecation of some util APIs

This release includes the runtime deprecation of the following util APIs:

  • util._extend
  • util.isArray
  • util.isBoolean
  • util.isBuffer
  • util.isDate
  • util.isError
  • util.isFunction
  • util.isNull
  • util.isNullOrUndefined
  • util.isNumber
  • util.isObject
  • util.isPrimitive
  • util.isRegExp
  • util.isString
  • util.isSymbol
  • util.isUndefined
  • util.log
Note

You can check for deprecated APIs by running your applications with the -throw-deprecation CLI flag, which generates a runtime error if your code is using a runtime deprecated API.

For more information, see the Node.js Utilities: Deprecated APIs documentation.

2.3. Technology Preview features

The following features are available as Technology Preview features in the Node.js 22 LTS release.

Red Hat build of Node.js 22 includes an experimental built-in browser-compatible implementation of the WebSocket API. This enhancement provides a WebSocket client without external dependencies.

This feature is enabled by default. If you want to disable this feature, you can use the --no-experimental-websocket CLI flag.

2.3.2. Enhancements for ESM compatibility

Red Hat build of Node.js 22 includes the following experimental enhancements for ECMAScript Modules (ESM) compatibility.

This release includes experimental support for import.meta.dirname and import.meta.filename properties, which are loaded from the local file system. For file:-based ESM, these properties are equivalent to the CommonJS __filename and __dirname global variables. The import.meta.filename property provides the full absolute path to the module as a file path rather than as a URL. The import.meta.dirname property provides the full absolute path to the folder that contains the module.

Note

These properties are not available for non file:-based ESM, such as modules that are loaded from data: or https: URLs.

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

This release includes experimental support for running ECMAScript (ES) modules automatically when ESM syntax is detected in JavaScript. For ambiguous .js or extensionless files where the nearest package.json file has no type field, Node.js parses the file to check for ESM syntax. If ESM syntax is detected, Node.js runs the file as an ES module. Otherwise, if there is uncertainty about the file type, Node.js runs the file as a CommonJS module. A typical use case for this feature is to allow the use of ES module syntax in extensionless scripts that have no nearby package.json file.

This feature is enabled by default. If you want to disable this feature, you can use the --no-experimental-detect-module CLI flag.

Note

This automatic detection feature increases startup times. To help avoid the overhead of checking for ESM syntax, consider adding a type field to the package.json file or use explicit file extensions such as .mjs or .cjs.

This release adds experimental support for using the require() function with synchronous ESM graphs. You can enable this feature by using the --experimental-require-module CLI flag.

For a module to be loaded, the module must meet the following requirements:

  • Explicitly marked as an ES module with a type:module field in the nearest package.json file or a .mjs extension
  • Fully synchronous and contains no top-level await expression

The require() function loads the requested module as an ES module and returns the module namespace object. This behavior is similar to dynamic import() functionality; however, the require() function is run synchronously and returns the namespace object directly.

For more information, see the Node.js Loading ECMAScript modules using require() documentation.

2.3.3. TypeScript support

Red Hat build of Node.js 22 introduces the following experimental features for TypeScript support.

This release includes an experimental feature that strips type annotations from .ts files, which allows these files to run without transforming TypeScript-specific syntax. You can enable this feature by using the --experimental-strip-types CLI flag.

This feature has the following limitations:

  • Supports inline type annotations only
  • Does not support features such as 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
  • Is disabled for TypeScript in node_modules by default

For more information, see the Node.js Type stripping documentation.

2.3.3.2. Transform types support

This release includes an experimental feature that enables the transformation of TypeScript-only syntax into JavaScript code. This feature allows Red Hat build of Node.js to support TypeScript syntax such as Enum and namespace. You can enable this feature by using the --experimental-transform-types CLI flag.

For more information, see the Node.js Modules: TypeScript documentation.

2.3.4. Experimental Web Storage API

Red Hat build of Node.js 22 introduces an experimental implementation of the Web Storage API that uses SQLite for data storage. You can enable this feature by using the --experimental-webstorage CLI flag.

For more information, see the Node.js --experimental-webstorage documentation.

2.3.5. Experimental sqlite API

Red Hat build of Node.js 22 introduces an experimental feature for a built-in node:sqlite module that you can enable by using the --experimental-sqlite CLI flag.

The following example shows how to use the node:sqlite module to open an in-memory database, write data to the database, and read the data back:

import { DatabaseSync } from 'node:sqlite';
const database = new DatabaseSync(':memory:');

// Execute SQL statements from strings.
database.exec(`
  CREATE TABLE data(
    key INTEGER PRIMARY KEY,
    value TEXT
  ) STRICT
`);
// Create a prepared statement to insert data into the database.
const insert = database.prepare('INSERT INTO data (key, value) VALUES (?, ?)');
// Execute the prepared statement with bound values.
insert.run(1, 'hello');
insert.run(2, 'world');
// Create a prepared statement to read data from the database.
const query = database.prepare('SELECT * FROM data ORDER BY key');
// Execute the prepared statement and log the result set.
console.log(query.all());
// Prints: [ { key: 1, value: 'hello' }, { key: 2, value: 'world' } ]

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

2.3.6. Partial support for the Navigator API

Red Hat build of Node.js 22 includes an experimental Navigator global object. The Navigator object is a partial implementation of the Navigator API, which is used to represent the identity and state of the user agent.

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

2.3.7. Text styling API

Red Hat build of Node.js 22 includes an experimental util.styleText(format, text) function that returns formatted text based on supplied format and text string parameters. You can use this new API to format text in different colors (for example, red, blue, green) and emphasis styles (for example, italic, bold, underline) based on util.inspect.colors.

The following example formats the text Hello World in green font:

const { styleText } = require('node:util');
const myMessage = styleText('green', 'Hello World');
console.log(myMessage);

The following example formats the text Error! in bold red font:

const { styleText } = require('node:util');
const myMessage = styleText(['red', 'bold'], 'Error!');
console.log(myMessage);

For more information, see the Node.js util.styleText documentation.

In addition to the existing experimental support for defining environment variables in files, Red Hat build of Node.js 22 includes the following experimental APIs for the programmatic loading and parsing of environment variables:

  • The process.loadEnvFile(path) function loads a .env file from the specified path.

    For example, the following code loads a development.env file from a test subdirectory:

    const { loadEnvFile } = require('node:process');
    loadEnvFile('./test/development.env');

    If you do not specify a path (for example, loadEnvFile()), this function loads the .env file that is in the current directory.

    For more information, see the Node.js process.loadEnvFile documentation.

  • The util.parseEnv(content) function parses a supplied string that contains environment variable assignments in attribute=value pairs.

    For example:

    const { parseEnv } = require('node:util');
    parseEnv('HELLO=world');

    For more information, see the Node.js util.parseEnv documentation.

2.3.9. On-disk code caching

Red Hat build of Node.js 22 introduces the following experimental features that offer two alternative solutions for automatic on-disk code caching.

2.3.9.1. NODE_COMPILE_CACHE environment variable

This release includes an experimental NODE_COMPILE_CACHE environment variable for enabling automatic on-disk code caching. This feature allows Node.js to use an on-disk V8 code cache that is persisted in a specified directory whenever Node.js compiles a CommonJS or ECMAScript (ES) module. This feature helps to expedite the software compilation process. You can enable this feature by using the NODE_COMPILE_CACHE environment variable to specify the path to the cache directory (for example, NODE_COMPILE_CACHE=/path/to/cache/dir).

This feature might increase the load time for the first load of a module graph. However, if the contents of the module do not change, this feature can also significantly reduce load times for any subsequent loads of the same module graph.

If you want to clear the generated cache, delete the cache directory that you specified in the NODE_COMPILE_CACHE environment variable. Red Hat build of Node.js automatically recreates the specified directory the next time this directory is used.

Note

Different versions of Red Hat build of Node.js cannot use the same compilation cache. Each product version generates its own separate cache. If the same directory is used across different product versions, the caches that are generated by different product versions are stored separately within the same directory.

Currently, when using this feature with V8 JavaScript code coverage, the coverage that V8 collects might be less precise in functions that are deserialized from the code cache. In this situation, consider disabling automatic on-disk code caching when running tests to generate precise coverage.

2.3.9.2. API module.enableCompileCache()

This release includes an experimental module.enableCompileCache() API for enabling on-disk code caching of all modules that are loaded after this API is called. This API offers an alternative solution for on-disk code caching and provides the following advantages when compared to the NODE_COMPILE_CACHE environment variable:

  • The module.enableCompileCache() API can be used by tooling and library authors to enable caching of their own code. The NODE_COMPILE_CACHE environment variable can be used by end users only.
  • The module.enableCompileCache() API is a a built-in alternative to the v8-compile-cache and v8-compile-cache-lib packages that also provides better performance and supports ECMAScript Modules (ESM).

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

2.4. Supported architectures

Node.js builder images and RPM packages are available and supported for use with the following CPU architectures:

  • AMD x86_64
  • ARM64
  • IBM Z (s390x) in the OpenShift environment
  • IBM Power Systems (ppc64le) in the OpenShift environment

Chapter 3. Release components

Chapter 4. Fixed issues

This release incorporates all of the fixed issues in the community release of Node.js 22 LTS.

Chapter 5. Known issues

There are no known issues affecting this release.

There are no known issues affecting infrastructure components required by this release.

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top