Chapter 2. Features
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: WebAssembly garbage collection Array.fromAsync method Set methods Iterator helpers 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 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. 2.1.3. Improved performance of AbortSignal creation 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 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 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 attempt failed and the user had already destroyed the connection. This issue caused a failed assertion in earlier releases. Note Similar to 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 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: Replace the preceding example with the following statement: 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. 2.3.1. Support for a browser-compatible WebSocket client 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. 2.3.2.1. Properties import.meta.dirname and import.meta.filename 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. 2.3.2.2. Support for automatic detection and running of ESM syntax 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 . 2.3.2.3. Support for requiring synchronous ESM graphs 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. 2.3.3.1. TypeScript support by using type stripping 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: 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: The following example formats the text Error! in bold red font: For more information, see the Node.js util.styleText documentation. 2.3.8. APIs for loading and parsing of environment variables 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: 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: 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 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
import " <module_name> " assert { ... } import " <module_name> " with { ... } 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' } ] const { styleText } = require('node:util'); const myMessage = styleText('green', 'Hello World'); console.log(myMessage); const { styleText } = require('node:util'); const myMessage = styleText(['red', 'bold'], 'Error!'); console.log(myMessage); const { loadEnvFile } = require('node:process'); loadEnvFile('./test/development.env'); const { parseEnv } = require('node:util'); parseEnv('HELLO=world');