2.3. テクノロジープレビュー機能
以下の機能は、Node.js 22 LTS リリースのテクノロジープレビュー機能として利用できます。
2.3.1. ブラウザー互換の WebSocket クライアントのサポート リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Node.js 22 には、WebSocket API の実験的なブラウザー互換実装が組み込まれています。この機能拡張により、外部依存関係のない WebSocket クライアントが提供されます。
この機能はデフォルトで有効化されています。この機能を無効にする場合は、--no-experimental-websocket CLI フラグを使用できます。
2.3.2. ESM の互換性に関する機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Node.js 22 には、ECMAScript モジュール (ESM) の互換性を確保するための次の実験的な機能拡張が含まれています。
2.3.2.1. プロパティー import.meta.dirname および import.meta.filename リンクのコピーリンクがクリップボードにコピーされました!
このリリースには、ローカルファイルシステムから読み込まれる import.meta.dirname および import.meta.filename プロパティーの実験的なサポートが含まれています。file: ベースの ESM の場合、これらのプロパティーは CommonJS の __filename および __dirname グローバル変数と同等です。import.meta.filename プロパティーは、URL ではなくファイルパス形式でモジュールへの完全な絶対パスを提供します。import.meta.dirname プロパティーは、モジュールが含まれるフォルダーへの完全な絶対パスを提供します。
これらのプロパティーは、data: または https: URL からロードされるモジュールなど、file: ベース以外の ESM では使用できません。
詳細は、Node.js の import.meta ドキュメントを参照してください。
2.3.2.2. ESM 構文の自動検出と実行のサポート リンクのコピーリンクがクリップボードにコピーされました!
このリリースには、JavaScript で ESM 構文が検出された場合に ECMAScript (ES) モジュールを自動的に実行するための実験的なサポートが含まれています。最も近い package.json ファイルに type フィールドがない、あいまいな .js ファイルまたは拡張子のないファイルの場合、Node.js はファイルを解析して ESM 構文をチェックします。ESM 構文が検出されると、Node.js はファイルを ES モジュールとして実行します。構文が検出されず、ファイルの種類が不明な場合、Node.js はファイルを CommonJS モジュールとして実行します。この機能の典型的なユースケースは、近くに package.json ファイルがない拡張子のないスクリプトで、ES モジュール構文を使用可能にすることです。
この機能はデフォルトで有効化されています。この機能を無効にする場合は、--no-experimental-detect-module CLI フラグを使用できます。
この自動検出機能により起動時間が長くなります。ESM 構文のチェックによるオーバーヘッドを回避するには、package.json ファイルに type フィールドを追加するか、.mjs や .cjs などの明示的なファイル拡張子を使用することを検討してください。
2.3.2.3. 同期 ESM グラフの要求のサポート リンクのコピーリンクがクリップボードにコピーされました!
このリリースでは、同期 ESM グラフで require() 関数を使用するための実験的なサポートが追加されました。この機能は --experimental-require-module CLI フラグを使用して有効にできます。
モジュールをロードするには、モジュールが次の要件を満たしている必要があります。
-
最も近い
package.jsonファイルのtype:moduleフィールドまたは.mjs拡張子を使用して、ES モジュールとして明示的にマークされている。 -
完全に同期しており、トップレベルの
await式が含まれていない。
require() 関数は、要求されたモジュールを ES モジュールとしてロードし、モジュール名前空間オブジェクトを返します。この動作は動的 import() 機能に似ていますが、require() 関数は同期的に実行され、名前空間オブジェクトを直接返します。
詳細は、Node.js の Loading ECMAScript modules using require() ドキュメントを参照してください。
2.3.3. TypeScript のサポート リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Node.js 22 では、TypeScript のサポートに次の実験的な機能が導入されています。
2.3.3.1. 型の削除を使用した TypeScript のサポート リンクのコピーリンクがクリップボードにコピーされました!
このリリースには、.ts ファイルから型アノテーションを削除する実験的な機能が含まれています。これにより、TypeScript 固有の構文を変換せずにこの種類のファイルを実行できるようになります。この機能は --experimental-strip-types CLI フラグを使用して有効にできます。
この機能には次の制限があります。
- インライン型アノテーションだけをサポートしています。
- 列挙型や名前空間などの機能はサポートしていません。
-
importおよびrequireステートメントで明示的なファイル拡張子が必要です。 -
実行時エラーを回避するために、型のインポートに
typeキーワードを強制的に使用します。 -
node_modulesの TypeScript はデフォルトで無効になっています。
詳細は、Node.js の Type stripping ドキュメントを参照してください。
2.3.3.2. 型の変換のサポート リンクのコピーリンクがクリップボードにコピーされました!
このリリースには、TypeScript のみの構文を JavaScript コードに変換できる実験的な機能が含まれています。この機能により、Red Hat build of Node.js で Enum や namespace などの TypeScript 構文をサポートできるようになります。この機能は --experimental-transform-types CLI フラグを使用して有効にできます。
詳細は、Node.js の Modules: TypeScript ドキュメントを参照してください。
2.3.4. 実験的な Web Storage API リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Node.js 22 では、データストレージに SQLite を使用する Web Storage API の実験的な実装が導入されています。この機能は --experimental-webstorage CLI フラグを使用して有効にできます。
詳細は、Node.js の --experimental-webstorage ドキュメントを参照してください。
2.3.5. 実験的な sqlite API リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Node.js 22 では、組み込みの node:sqlite モジュールの実験的な機能が導入されています。この機能は --experimental-sqlite CLI フラグを使用して有効にできます。
次の例は、node:sqlite モジュールを使用してメモリー内データベースを開き、データベースにデータを書き込み、データを読み取る方法を示しています。
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' } ]
詳細は、Node.js の SQLite ドキュメントを参照してください。
2.3.7. テキスト書式指定 API リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Node.js 22 には、実験的な util.styleText(format, text) 関数が含まれています。この関数は、指定されたフォーマットおよびテキスト文字列パラメーターに基づいて、書式設定されたテキストを返します。この新しい API を使用すると、util.inspect.colors に基づいて、さまざまな色 (red、blue、green など) や強調スタイル (italic、bold、underline など) でテキストを書式設定できます。
次の例では、テキスト Hello World を緑のフォントで書式設定します。
const { styleText } = require('node:util');
const myMessage = styleText('green', 'Hello World');
console.log(myMessage);
次の例では、テキスト Error! を太字の赤いフォントで書式設定します。
const { styleText } = require('node:util');
const myMessage = styleText(['red', 'bold'], 'Error!');
console.log(myMessage);
詳細は、Node.js の util.styleText ドキュメントを参照してください。
2.3.8. 環境変数のロードと解析のための API リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Node.js 22 には、ファイル内で環境変数を定義するための既存の実験的なサポートに加えて、環境変数をプログラムでロードして解析するための次の実験的な API が含まれています。
process.loadEnvFile (path)関数は、指定パスから.envファイルを読み込みます。たとえば、次のコードは、
testサブディレクトリーからdevelopment.envファイルをロードします。const { loadEnvFile } = require('node:process'); loadEnvFile('./test/development.env');パスを指定しない場合 (たとえば、
loadEnvFile())、この関数はカレントディレクトリーにある.envファイルをロードします。詳細は、Node.js の
process.loadEnvFileドキュメントを参照してください。util.parseEnv(content)関数は、attribute=value ペア形式の環境変数の割り当てを含む指定文字列を解析します。以下に例を示します。
const { parseEnv } = require('node:util'); parseEnv('HELLO=world');詳細は、Node.js の
util.parseEnvドキュメントを参照してください。
2.3.9. ディスクへのコードキャッシュ保存 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Node.js 22 では、ディスク上にコードをキャッシュする別の方法として、次の 2 つの実験的な機能が導入されています。
2.3.9.1. NODE_COMPILE_CACHE 環境変数 リンクのコピーリンクがクリップボードにコピーされました!
このリリースには、ディスクへのコードキャッシュ自動保存を有効にする実験的な NODE_COMPILE_CACHE 環境変数が含まれています。この機能により、Node.js が CommonJS または ECMAScript (ES) モジュールをコンパイルするときに、指定ディレクトリーに保存されているディスク上の V8 コードキャッシュ を使用できるようになります。この機能は、ソフトウェアのコンパイルプロセスを迅速化するのに役立ちます。この機能を有効にするには、NODE_COMPILE_CACHE 環境変数を使用してキャッシュディレクトリーへのパスを指定します (例: NODE_COMPILE_CACHE=/path/to/cache/dir)。
この機能により、モジュールグラフの最初のロード時間が長くなる可能性があります。ただし、モジュールの内容が変更されなければ、この機能により、同じモジュールグラフを次回以降ロードする際にかかる時間が大幅に短縮されます。
生成されたキャッシュをクリアする場合は、NODE_COMPILE_CACHE 環境変数で指定したキャッシュディレクトリーを削除します。Red Hat build of Node.js は、次回このディレクトリーが使用されるときに、指定されたディレクトリーを自動的に再作成します。
異なるバージョンの Red Hat build of Node.js では、同じコンパイルキャッシュを使用できません。製品バージョンごとに独自のキャッシュが生成されます。複数の異なる製品バージョンで同じディレクトリーが使用されている場合、各製品バージョンによって生成されたキャッシュが、同じディレクトリー内に個別に保存されます。
現在、この機能を V8 JavaScript のコードカバレッジで使用する場合、コードキャッシュからデシリアライズされた関数で、V8 が収集するカバレッジの精度が低くなる可能性があります。このような場合は、正確なカバレッジを生成するためにテストを実行するときに、ディスクへのコードキャッシュ自動保存を無効にすることを検討してください。
2.3.9.2. module.enableCompileCache() API リンクのコピーリンクがクリップボードにコピーされました!
このリリースには、実験的な module.enableCompileCache() API が含まれています。これは、この API が呼び出された後にロードされるモジュールすべてのディスクへのコードキャッシュ保存を有効にするためのものです。この API は、ディスク上にコードをキャッシュする別の方法であり、NODE_COMPILE_CACHE 環境変数と比較して次の利点があります。
-
module.enableCompileCache()API は、ツールやライブラリーの作成者が独自のコードのキャッシュを有効にするために使用できます。NODE_COMPILE_CACHE環境変数はエンドユーザーのみが使用できます。 -
module.enableCompileCache()API は、v8-compile-cache および v8-compile-cache-lib パッケージに代わる組み込みの代替機能です。より優れたパフォーマンスを提供し、ECMAScript モジュール (ESM) をサポートしています。
詳細は、Node.js の module.EnableCompileCache ドキュメントを参照してください。