Release Notes for Node.js 22
For use with Node.js 22 LTS
Abstract
Preface Copy linkLink copied to clipboard!
Date of release: 2025-02-24
Chapter 1. Required Infrastructure Component Versions Copy linkLink copied to clipboard!
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.
Chapter 2. Features Copy linkLink copied to clipboard!
This section contains information about feature changes in the Red Hat build of Node.js 22 release.
2.1. New and Changed features Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
2.1.2. Increased default high water mark for Node.js streams Copy linkLink copied to clipboard!
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.
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.
2.1.3. Improved performance of AbortSignal creation Copy linkLink copied to clipboard!
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.
2.1.4. Improved performance of synchronous file-system APIs Copy linkLink copied to clipboard!
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.
2.1.5. Improved handling of bad IPV6 configurations Copy linkLink copied to clipboard!
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
connectionAttemptevent is emitted when a new connection attempt is established. When using Happy Eyeballs, this event might be emitted multiple times. -
A
connectionAttemptFailedevent is emitted when a connection attempt fails. When using Happy Eyeballs, this event might be emitted multiple times. -
A
connectionAttemptTimeoutevent 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.
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.
2.1.6. Support for the deflate-raw compression format for Web Streams Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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
--watchoption starts Node.js in watch mode. -
The
--watch-pathoption starts Node.js in watch mode and specifies the path to watch. The
--watch-preserve-outputoption disables clearing of the console when watch mode restarts the process.NoteThis option also requires use of the
--watchor--watch-pathoption.
For more information, see the Node.js --watch documentation.
2.2. Deprecated features Copy linkLink copied to clipboard!
The following features are deprecated in the Red Hat build of Node.js 22 release.
For more information about deprecated or removed features in this release, see the nodejs.org website.
2.2.1. Support for import assertions Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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
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 Copy linkLink copied to clipboard!
The following features are available as Technology Preview features in the Node.js 22 LTS release.
2.3.1. Support for a browser-compatible WebSocket client Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
Red Hat build of Node.js 22 includes the following experimental enhancements for ECMAScript Modules (ESM) compatibility.
2.3.2.1. Properties import.meta.dirname and import.meta.filename Copy linkLink copied to clipboard!
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.
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.
2.3.2.2. Support for automatic detection and running of ESM syntax Copy linkLink copied to clipboard!
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.
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.
2.3.2.3. Support for requiring synchronous ESM graphs Copy linkLink copied to clipboard!
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:modulefield in the nearestpackage.jsonfile or a.mjsextension -
Fully synchronous and contains no top-level
awaitexpression
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 Copy linkLink copied to clipboard!
Red Hat build of Node.js 22 introduces the following experimental features for TypeScript support.
2.3.3.1. TypeScript support by using type stripping Copy linkLink copied to clipboard!
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
importandrequirestatements -
Enforces the use of the
typekeyword for type imports to avoid runtime errors -
Is disabled for TypeScript in
node_modulesby default
For more information, see the Node.js Type stripping documentation.
2.3.3.2. Transform types support Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.7. Text styling API Copy linkLink copied to clipboard!
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.
2.3.8. APIs for loading and parsing of environment variables Copy linkLink copied to clipboard!
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.envfile from the specified path.For example, the following code loads a
development.envfile from atestsubdirectory:const { loadEnvFile } = require('node:process'); loadEnvFile('./test/development.env');If you do not specify a path (for example,
loadEnvFile()), this function loads the.envfile that is in the current directory.For more information, see the Node.js
process.loadEnvFiledocumentation.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.parseEnvdocumentation.
2.3.9. On-disk code caching Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
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() Copy linkLink copied to clipboard!
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. TheNODE_COMPILE_CACHEenvironment 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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
- Node.js 22 LTS Builder Image for RHEL 8
- Node.js 22 LTS Universal Base Image 8
- Node.js 22 LTS Minimal Stand-alone Image for RHEL 8
- Node.js 22 LTS Minimal Universal Base Image 8
- Node.js 22 LTS Builder Image for RHEL 9
- Node.js 22 LTS Universal Base Image 9
- Node.js 22 LTS Minimal Stand-alone Image for RHEL 9
- Node.js 22 LTS Minimal Universal Base Image 9
Chapter 4. Fixed issues Copy linkLink copied to clipboard!
This release incorporates all of the fixed issues in the community release of Node.js 22 LTS.
Chapter 5. Known issues Copy linkLink copied to clipboard!
There are no known issues affecting this release.
Chapter 6. Known issues affecting required infrastructure components Copy linkLink copied to clipboard!
There are no known issues affecting infrastructure components required by this release.