Node.js v25.0.0 ドキュメンテーション

ECMAScript モジュールローダーのエントリーポイントに関する注意点#

ロード時、ES モジュールローダーがプログラムのエントリーポイントをロードする場合、node コマンドは .js、.mjs、または .cjs 拡張子を持つファイルのみを入力として受け入れます。以下のフラグを使用すると、追加のファイル拡張子が有効になります

• .node 拡張子のファイルには --experimental-addon-modules。

-#

stdin のエイリアスです。他のコマンドラインユーティリティでの - の使用に類似しており、スクリプトが stdin から読み取られ、残りのオプションがそのスクリプトに渡されることを意味します。

--#

node オプションの終わりを示します。残りの引数をスクリプトに渡します。これより前にスクリプトのファイル名や eval/print スクリプトが指定されていない場合、次の引数がスクリプトのファイル名として使用されます。

--abort-on-uncaught-exception#

終了する代わりに中止すると、デバッガー (lldb、gdb、mdb など) を使用した事後分析用のコアファイルが生成されます。

このフラグが渡された場合でも、process.setUncaughtExceptionCaptureCallback() を通じて (およびそれを使用する node:domain モジュールの使用を通じて)、中止しないように動作を設定することができます。

--allow-addons#

Permission Model を使用している場合、プロセスはデフォルトでネイティブアドオンを使用できません。使用しようとすると、ユーザーが Node.js を開始するときに明示的に --allow-addons フラグを渡さない限り、ERR_DLOPEN_DISABLED がスローされます。

例

// Attempt to require an native addon
require('nodejs-addon-example'); copy

$ node --permission --allow-fs-read=* index.js
node:internal/modules/cjs/loader:1319
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: Cannot load native addon because loading addons is disabled.
    at Module._extensions..node (node:internal/modules/cjs/loader:1319:18)
    at Module.load (node:internal/modules/cjs/loader:1091:32)
    at Module._load (node:internal/modules/cjs/loader:938:12)
    at Module.require (node:internal/modules/cjs/loader:1115:19)
    at require (node:internal/modules/helpers:130:18)
    at Object.<anonymous> (/home/index.js:1:15)
    at Module._compile (node:internal/modules/cjs/loader:1233:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1287:10)
    at Module.load (node:internal/modules/cjs/loader:1091:32)
    at Module._load (node:internal/modules/cjs/loader:938:12) {
  code: 'ERR_DLOPEN_DISABLED'
} copy

--allow-child-process#

Permission Model を使用している場合、プロセスはデフォルトで子プロセスを生成できません。生成しようとすると、ユーザーが Node.js を開始するときに明示的に --allow-child-process フラグを渡さない限り、ERR_ACCESS_DENIED がスローされます。

例

const childProcess = require('node:child_process');
// Attempt to bypass the permission
childProcess.spawn('node', ['-e', 'require("fs").writeFileSync("/new-file", "example")']); copy

$ node --permission --allow-fs-read=* index.js
node:internal/child_process:388
  const err = this._handle.spawn(options);
                           ^
Error: Access to this API has been restricted
    at ChildProcess.spawn (node:internal/child_process:388:28)
    at node:internal/main/run_main_module:17:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'ChildProcess'
} copy

child_process.fork() API は、親プロセスから実行引数を継承します。これは、Node.js が Permission Model を有効にして開始され、--allow-child-process フラグが設定されている場合、child_process.fork() を使用して作成された子プロセスは、関連するすべての Permission Model フラグを自動的に受け取ることを意味します。

この動作は child_process.spawn() にも適用されますが、その場合、フラグはプロセス引数を介して直接ではなく、NODE_OPTIONS 環境変数を介して伝播されます。

--allow-fs-read#

このフラグは、Permission Model を使用してファイルシステムの読み取り権限を設定します。

--allow-fs-read フラグの有効な引数は次のとおりです

• * - すべての FileSystemRead 操作を許可します。
• 複数の --allow-fs-read フラグを使用して複数のパスを許可できます。例: --allow-fs-read=/folder1/ --allow-fs-read=/folder1/

例は ファイルシステム権限 のドキュメントにあります。

初期化モジュールとカスタム --require モジュールには、暗黙の読み取り権限があります。

$ node --permission -r custom-require.js -r custom-require-2.js index.js copy

• custom-require.js、custom-require-2.js、index.js は、デフォルトで許可された読み取りリストに含まれます。

process.has('fs.read', 'index.js'); // true
process.has('fs.read', 'custom-require.js'); // true
process.has('fs.read', 'custom-require-2.js'); // true copy

--allow-fs-write#

このフラグは、Permission Model を使用してファイルシステムの書き込み権限を設定します。

--allow-fs-write フラグの有効な引数は次のとおりです

• * - すべての FileSystemWrite 操作を許可します。
• 複数の --allow-fs-write フラグを使用して複数のパスを許可できます。例: --allow-fs-write=/folder1/ --allow-fs-write=/folder1/

カンマ (,) で区切られたパスは許可されなくなりました。カンマを含む単一のフラグを渡すと、警告が表示されます。

例は ファイルシステム権限 のドキュメントにあります。

--allow-inspector#

Permission Model を使用している場合、プロセスはインスペクタープロトコルを介して接続できません。

接続しようとすると、ユーザーが Node.js を開始するときに明示的に --allow-inspector フラグを渡さない限り、ERR_ACCESS_DENIED がスローされます。

例

const { Session } = require('node:inspector/promises');

const session = new Session();
session.connect(); copy

$ node --permission index.js
Error: connect ERR_ACCESS_DENIED Access to this API has been restricted. Use --allow-inspector to manage permissions.
  code: 'ERR_ACCESS_DENIED',
} copy

--allow-net#

Permission Model を使用している場合、プロセスはデフォルトでネットワークにアクセスできません。アクセスしようとすると、ユーザーが Node.js を開始するときに明示的に --allow-net フラグを渡さない限り、ERR_ACCESS_DENIED がスローされます。

例

const http = require('node:http');
// Attempt to bypass the permission
const req = http.get('http://example.com', () => {});

req.on('error', (err) => {
  console.log('err', err);
}); copy

$ node --permission index.js
Error: connect ERR_ACCESS_DENIED Access to this API has been restricted. Use --allow-net to manage permissions.
  code: 'ERR_ACCESS_DENIED',
} copy

--allow-wasi#

Permission Model を使用している場合、プロセスはデフォルトで WASI インスタンスを作成できません。セキュリティ上の理由から、ユーザーがメインの Node.js プロセスで明示的に --allow-wasi フラグを渡さない限り、呼び出しは ERR_ACCESS_DENIED をスローします。

例

const { WASI } = require('node:wasi');
// Attempt to bypass the permission
new WASI({
  version: 'preview1',
  // Attempt to mount the whole filesystem
  preopens: {
    '/': '/',
  },
}); copy

$ node --permission --allow-fs-read=* index.js

Error: Access to this API has been restricted
    at node:internal/main/run_main_module:30:49 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'WASI',
} copy

--allow-worker#

Permission Model を使用している場合、プロセスはデフォルトでワーカースレッドを作成できません。セキュリティ上の理由から、ユーザーがメインの Node.js プロセスで明示的に --allow-worker フラグを渡さない限り、呼び出しは ERR_ACCESS_DENIED をスローします。

例

const { Worker } = require('node:worker_threads');
// Attempt to bypass the permission
new Worker(__filename); copy

$ node --permission --allow-fs-read=* index.js

Error: Access to this API has been restricted
    at node:internal/main/run_main_module:17:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'WorkerThreads'
} copy

--build-snapshot#

プロセスが終了するときにスナップショット BLOB を生成し、それをディスクに書き込みます。これは後で --snapshot-blob でロードできます。

スナップショットをビルドする際に --snapshot-blob が指定されていない場合、生成された BLOB はデフォルトで現在の作業ディレクトリの snapshot.blob に書き込まれます。それ以外の場合は、--snapshot-blob で指定されたパスに書き込まれます。

$ echo "globalThis.foo = 'I am from the snapshot'" > snapshot.js

# Run snapshot.js to initialize the application and snapshot the
# state of it into snapshot.blob.
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js

$ echo "console.log(globalThis.foo)" > index.js

# Load the generated snapshot and start the application from index.js.
$ node --snapshot-blob snapshot.blob index.js
I am from the snapshot copy

v8.startupSnapshot API を使用して、スナップショットビルド時にエントリーポイントを指定できます。これにより、デシリアライズ時追加のエントリスクリプトが不要になります。

$ echo "require('v8').startupSnapshot.setDeserializeMainFunction(() => console.log('I am from the snapshot'))" > snapshot.js
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js
$ node --snapshot-blob snapshot.blob
I am from the snapshot copy

詳細については、v8.startupSnapshot API のドキュメントを参照してください。

現在、ランタイムスナップショットのサポートは以下の点で実験的です

1. ユーザーランドモジュールはまだスナップショットでサポートされていないため、単一のファイルのみスナップショット化できます。ただし、ユーザーはスナップショットをビルドする前に、選択したバンドラーでアプリケーションを単一のスクリプトにバンドルできます。
2. スナップショットでは組み込みモジュールの一部しか動作しませんが、Node.js のコアテストスイートは、かなり複雑ないくつかのアプリケーションがスナップショット化できることを確認しています。より多くのモジュールのサポートが追加されています。スナップショットのビルド時にクラッシュやバグのある動作が発生した場合は、Node.js の issue トラッカーに報告し、ユーザーランドスナップショットの追跡 issue にリンクしてください。

--build-snapshot-config#

スナップショット作成の動作を構成する JSON 設定ファイルへのパスを指定します。

現在サポートされているオプションは次のとおりです

• builder <string> 必須。スナップショットをビルドする前に実行されるスクリプトの名前を指定します。--build-snapshot が builder をメインスクリプト名として渡された場合と同様です。
• withoutCodeCache <boolean> オプション。コードキャッシュを含めると、スナップショットに含まれる関数のコンパイルにかかる時間が短縮されますが、スナップショットのサイズが大きくなり、スナップショットの移植性が損なわれる可能性があります。

このフラグを使用すると、コマンドラインで提供される追加のスクリプトファイルは実行されず、代わりに通常のコマンドライン引数として解釈されます。

-c, --check#

スクリプトを実行せずに構文チェックを行います。

--completion-bash#

Node.js 用の source 可能な bash 補完スクリプトを出力します。

node --completion-bash > node_bash_completion
source node_bash_completion copy

-C condition, --conditions=condition#

カスタムの条件付きエクスポート解決条件を提供します。

任意の数のカスタム文字列条件名が許可されます。

デフォルトの Node.js 条件である "node"、"default"、"import"、"require" は、常に定義どおりに適用されます。

例えば、「development」解決でモジュールを実行するには

node -C development app.js copy

--cpu-prof#

起動時に V8 CPU プロファイラーを開始し、終了前に CPU プロファイルをディスクに書き込みます。

--cpu-prof-dir が指定されていない場合、生成されたプロファイルは現在の作業ディレクトリに配置されます。

--cpu-prof-name が指定されていない場合、生成されたプロファイルは CPU.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.cpuprofile という名前になります。

$ node --cpu-prof index.js
$ ls *.cpuprofile
CPU.20190409.202950.15293.0.0.cpuprofile copy

--cpu-prof-name が指定されている場合、提供された値がファイル名のテンプレートとして使用されます。次のプレースホルダーがサポートされており、実行時に置換されます

• ${pid} — 現在のプロセス ID

$ node --cpu-prof --cpu-prof-name 'CPU.${pid}.cpuprofile' index.js
$ ls *.cpuprofile
CPU.15293.cpuprofile copy

--cpu-prof-dir#

--cpu-prof によって生成された CPU プロファイルが配置されるディレクトリを指定します。

デフォルト値は --diagnostic-dir コマンドラインオプションによって制御されます。

--cpu-prof-interval#

--cpu-prof によって生成される CPU プロファイルのサンプリング間隔をマイクロ秒単位で指定します。デフォルトは 1000 マイクロ秒です。

--cpu-prof-name#

--cpu-prof によって生成される CPU プロファイルのファイル名を指定します。

--diagnostic-dir=directory#

すべての診断出力ファイルが書き込まれるディレクトリを設定します。デフォルトは現在の作業ディレクトリです。

以下のデフォルト出力ディレクトリに影響します

• --cpu-prof-dir
• --heap-prof-dir
• --redirect-warnings

--disable-proto=mode#

Object.prototype.__proto__ プロパティを無効にします。mode が delete の場合、プロパティは完全に削除されます。mode が throw の場合、プロパティへのアクセスは ERR_PROTO_ACCESS コードの例外をスローします。

--disable-sigusr1#

プロセスに SIGUSR1 シグナルを送信してデバッグセッションを開始する機能を無効にします。

--disable-warning=code-or-type#

code または type によって特定のプロセス警告を無効にします。

process.emitWarning() から発行される警告には、code と type が含まれる場合があります。このオプションは、一致する code または type を持つ警告を発行しません。

非推奨警告のリスト。

Node.js のコア警告タイプは、DeprecationWarning と ExperimentalWarning です。

例えば、以下のスクリプトは node --disable-warning=DEP0025 で実行された場合、DEP0025 require('node:sys') を発行しません。

import sys from 'node:sys';const sys = require('node:sys');copy

例えば、以下のスクリプトは、node --disable-warning=ExperimentalWarning で実行された場合、DEP0025 require('node:sys') を発行しますが、実験的な警告 (例: <=v21 での ExperimentalWarning: vm.measureMemory is an experimental feature) は発行しません。

import sys from 'node:sys';
import vm from 'node:vm';

vm.measureMemory();const sys = require('node:sys');
const vm = require('node:vm');

vm.measureMemory();copy

--disable-wasm-trap-handler#

デフォルトでは、Node.js はトラップハンドラベースの WebAssembly バウンドチェックを有効にします。その結果、V8 は WebAssembly からコンパイルされたコードにインラインのバウンドチェックを挿入する必要がなくなり、WebAssembly の実行を大幅に高速化できますが、この最適化には大きな仮想メモリケージ (現在 10GB) の割り当てが必要です。システム構成やハードウェアの制限により、Node.js プロセスが十分な大きさの仮想メモリアドレス空間にアクセスできない場合、ユーザーはこの仮想メモリケージでの割り当てを伴う WebAssembly を実行できず、メモリ不足エラーが発生します。

$ ulimit -v 5000000
$ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });"
[eval]:1
new WebAssembly.Memory({ initial: 10, maximum: 100 });
^

RangeError: WebAssembly.Memory(): could not allocate memory
    at [eval]:1:1
    at runScriptInThisContext (node:internal/vm:209:10)
    at node:internal/process/execution:118:14
    at [eval]-wrapper:6:24
    at runScript (node:internal/process/execution:101:62)
    at evalScript (node:internal/process/execution:136:3)
    at node:internal/main/eval_string:49:3
 copy

--disable-wasm-trap-handler はこの最適化を無効にするため、Node.js プロセスで利用可能な仮想メモリアドレス空間が V8 WebAssembly メモリケージが必要とするよりも小さい場合でも、ユーザーは少なくとも (最適なパフォーマンスではないものの) WebAssembly を実行できます。

--disallow-code-generation-from-strings#

eval や new Function のような、文字列からコードを生成する組み込みの言語機能が、代わりに例外をスローするようにします。これは Node.js の node:vm モジュールには影響しません。

--dns-result-order=order#

dns.lookup() および dnsPromises.lookup() の order のデフォルト値を設定します。値は次のいずれかです

• ipv4first: デフォルトの order を ipv4first に設定します。
• ipv6first: デフォルトの order を ipv6first に設定します。
• verbatim: デフォルトの order を verbatim に設定します。

デフォルトは verbatim で、dns.setDefaultResultOrder() は --dns-result-order よりも優先されます。

--enable-fips#

起動時に FIPS 準拠の暗号化を有効にします。(FIPS 互換の OpenSSL に対して Node.js がビルドされている必要があります。)

--enable-network-family-autoselection#

接続オプションで明示的に無効にされていない限り、ファミリー自動選択アルゴリズムを有効にします。

--enable-source-maps#

スタックトレースのソースマップサポートを有効にします。

TypeScript などのトランスパイラを使用する場合、アプリケーションによってスローされるスタックトレースは、元のソースの位置ではなく、トランスパイルされたコードを参照します。--enable-source-maps はソースマップのキャッシュを有効にし、元のソースファイルに対するスタックトレースを報告するよう最善を尽くします。

Error.prepareStackTrace をオーバーライドすると、--enable-source-maps がスタックトレースを変更できなくなる可能性があります。スタックトレースをソースマップで変更するには、オーバーライドする関数内で元の Error.prepareStackTrace を呼び出してその結果を返してください。

const originalPrepareStackTrace = Error.prepareStackTrace;
Error.prepareStackTrace = (error, trace) => {
  // Modify error and trace and format stack trace with
  // original Error.prepareStackTrace.
  return originalPrepareStackTrace(error, trace);
}; copy

注意: ソースマップを有効にすると、Error.stack にアクセスする際にアプリケーションに遅延が発生する可能性があります。アプリケーションで Error.stack に頻繁にアクセスする場合は、--enable-source-maps のパフォーマンスへの影響を考慮してください。

--entry-url#

存在する場合、Node.js はエントリーポイントをパスではなく URL として解釈します。

ECMAScript モジュール解決ルールに従います。

URL 内のクエリパラメータやハッシュは、import.meta.url を介してアクセスできます。

node --entry-url 'file:///path/to/file.js?queryparams=work#and-hashes-too'
node --entry-url 'file.ts?query#hash'
node --entry-url 'data:text/javascript,console.log("Hello")' copy

--env-file-if-exists=file#

動作は --env-file と同じですが、ファイルが存在しない場合でもエラーはスローされません。

--env-file=file#

現在のディレクトリからの相対パスでファイルから環境変数をロードし、process.env でアプリケーションが利用できるようにします。NODE_OPTIONS のように Node.js を設定する環境変数は、解析されて適用されます。同じ変数が環境とファイルで定義されている場合、環境からの値が優先されます。

複数の --env-file 引数を渡すことができます。後続のファイルは、前のファイルで定義された既存の変数を上書きします。

ファイルが存在しない場合はエラーがスローされます。

node --env-file=.env --env-file=.development.env index.js copy

ファイルの形式は、環境変数名と値を = で区切ったキーと値のペアを 1 行に 1 つずつ記述する必要があります。

PORT=3000 copy

# の後のテキストはコメントとして扱われます。

# This is a comment
PORT=3000 # This is also a comment copy

値は次の引用符で開始および終了できます: `、"、または '。これらは値から省略されます。

USERNAME="nodejs" # will result in `nodejs` as the value. copy

複数行の値がサポートされています。

MULTI_LINE="THIS IS
A MULTILINE"
# will result in `THIS IS\nA MULTILINE` as the value. copy

キーの前の export キーワードは無視されます。

export USERNAME="nodejs" # will result in `nodejs` as the value. copy

存在しない可能性のあるファイルから環境変数をロードしたい場合は、代わりに --env-file-if-exists フラグを使用できます。

-e, --eval "script"#

次の引数を JavaScript として評価します。REPL で事前定義されているモジュールは、script でも使用できます。

Windows では、cmd.exe は引用符として二重引用符 " のみ認識するため、単一引用符は正しく機能しません。Powershell または Git bash では、' と " の両方が使用できます。

--no-experimental-strip-types フラグが指定されていない限り、インライン型を含むコードを実行できます。

--experimental-addon-modules#

.node アドオンの実験的なインポートサポートを有効にします。

--experimental-config-file=config#

存在する場合、Node.js は指定されたパスで設定ファイルを検索します。Node.js は設定ファイルを読み取り、設定を適用します。設定ファイルは、次の構造を持つ JSON ファイルである必要があります。$schema の vX.Y.Z は、使用している Node.js のバージョンに置き換える必要があります。

{
  "$schema": "https://node.dokyumento.jp/dist/vX.Y.Z/docs/node-config-schema.json",
  "nodeOptions": {
    "import": [
      "amaro/strip"
    ],
    "watch-path": "src",
    "watch-preserve-output": true
  },
  "testRunner": {
    "test-isolation": "process"
  }
} copy

設定ファイルは、名前空間固有のオプションをサポートします

• nodeOptions フィールドには、NODE_OPTIONS で許可されている CLI フラグが含まれます。

• testRunner のような名前空間フィールドには、そのサブシステム固有の設定が含まれます。

No-op フラグはサポートされていません。現在、すべての V8 フラグがサポートされているわけではありません。

公式の JSON スキーマを使用して設定ファイルを検証できます。これは Node.js のバージョンによって異なる場合があります。設定ファイルの各キーは、コマンドライン引数として渡すことができるフラグに対応します。キーの値は、フラグに渡される値です。

例えば、上記の設定ファイルは、次のコマンドライン引数と同等です

node --import amaro/strip --watch-path=src --watch-preserve-output --test-isolation=process copy

設定の優先順位は次のとおりです

1. NODE_OPTIONS とコマンドラインオプション
2. 設定ファイル
3. Dotenv NODE_OPTIONS

設定ファイルの値は、環境変数やコマンドラインオプションの値を上書きしませんが、--env-file フラグによって解析された NODE_OPTIONS 環境ファイルの値は上書きします。

同じ名前空間または異なる名前空間内でキーを重複させることはできません。

設定パーサーは、設定ファイルに不明なキーや名前空間で使用できないキーが含まれている場合、エラーをスローします。

Node.js は、ユーザーが提供した設定をサニタイズしたり検証したりしないため、信頼できない設定ファイルは決して使用しないでください。

--experimental-default-config-file#

--experimental-default-config-file フラグが存在する場合、Node.js は現在の作業ディレクトリで node.config.json ファイルを検索し、設定ファイルとしてロードします。

--experimental-eventsource#

グローバルスコープでの EventSource Web API の公開を有効にします。

--experimental-import-meta-resolve#

実験的な import.meta.resolve() 親 URL サポートを有効にします。これにより、コンテキストに応じた解決のために 2 番目の parentURL 引数を渡すことができます。

以前は import.meta.resolve 機能全体をゲートしていました。

--experimental-inspector-network-resource#

インスペクターネットワークリソースの実験的なサポートを有効にします。

--experimental-loader=module#

このフラグは非推奨であり、Node.js の将来のバージョンで削除される可能性があります。代わりに register() を伴う --import を使用してください。

エクスポートされたモジュールカスタマイズフックを含む module を指定します。module は、import 指定子として受け入れられる任意の文字列です。

この機能は、Permission Model と一緒に使用する場合、--allow-worker が必要です。

--experimental-network-inspection#

Chrome DevTools を使用したネットワークインスペクションの実験的なサポートを有効にします。

--experimental-print-required-tla#

require() される ES モジュールにトップレベルの await が含まれている場合、このフラグを使用すると、Node.js はモジュールを評価し、トップレベルの await を見つけようとし、ユーザーがそれらを見つけるのに役立つようにその場所を出力できます。

--experimental-quic#

QUIC プロトコルの実験的なサポートを有効にします。

--experimental-require-module#

require() で同期 ES モジュールグラフのロードをサポートします。

require() を使用した ECMAScript モジュールのロードを参照してください。

--experimental-sea-config#

このフラグを使用して、Node.js バイナリに注入して単一実行可能アプリケーションを作成できる BLOB を生成します。詳細については、この設定に関するドキュメントを参照してください。

--experimental-shadow-realm#

このフラグを使用して ShadowRealm のサポートを有効にします。

--experimental-test-coverage#

node:test モジュールと組み合わせて使用すると、テストランナーの出力の一部としてコードカバレッジレポートが生成されます。テストが実行されない場合、カバレッジレポートは生成されません。詳細については、テストからコードカバレッジを収集するのドキュメントを参照してください。

--experimental-test-module-mocks#

テストランナーでモジュールのモックを有効にします。

この機能は、Permission Model と一緒に使用する場合、--allow-worker が必要です。

--experimental-transform-types#

TypeScript のみ構文を JavaScript コードに変換することを有効にします。--enable-source-maps を暗黙的に含みます。

--experimental-vm-modules#

node:vm モジュールで実験的な ES モジュールサポートを有効にします。

--experimental-wasi-unstable-preview1#

実験的な WebAssembly System Interface (WASI) サポートを有効にします。

--experimental-worker-inspection#

Chrome DevTools を使用したワーカーインスペクションの実験的なサポートを有効にします。

--expose-gc#

このフラグは V8 から gc 拡張を公開します。

if (globalThis.gc) {
  globalThis.gc();
} copy

--force-context-aware#

コンテキストアウェアではないネイティブアドオンの読み込みを無効にします。

--force-fips#

起動時に FIPS 準拠の暗号化を強制します。(スクリプトコードから無効にすることはできません。)(--enable-fips と同じ要件です。)

--force-node-api-uncaught-exceptions-policy#

Node-API の非同期コールバックで uncaughtException イベントを強制します。

既存のアドオンがプロセスをクラッシュさせるのを防ぐため、このフラグはデフォルトでは有効になっていません。将来的には、正しい動作を強制するためにこのフラグはデフォルトで有効になります。

--frozen-intrinsics#

Array や Object のような実験的な凍結された組み込みオブジェクトを有効にします。

ルートコンテキストのみがサポートされています。globalThis.Array が実際にデフォルトの組み込み参照であるという保証はありません。このフラグの下ではコードが壊れる可能性があります。

ポリフィルを追加できるようにするため、--require と --import の両方が、組み込みオブジェクトを凍結する前に実行されます。

--heap-prof#

起動時に V8 ヒーププロファイラーを開始し、終了前にヒーププロファイルをディスクに書き込みます。

--heap-prof-dir が指定されていない場合、生成されたプロファイルは現在の作業ディレクトリに配置されます。

--heap-prof-name が指定されていない場合、生成されたプロファイルは Heap.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.heapprofile という名前になります。

$ node --heap-prof index.js
$ ls *.heapprofile
Heap.20190409.202950.15293.0.001.heapprofile copy

--heap-prof-dir#

--heap-prof によって生成されたヒーププロファイルが配置されるディレクトリを指定します。

デフォルト値は --diagnostic-dir コマンドラインオプションによって制御されます。

--heap-prof-interval#

--heap-prof によって生成されるヒーププロファイルの平均サンプリング間隔をバイト単位で指定します。デフォルトは 512 * 1024 バイトです。

--heap-prof-name#

--heap-prof によって生成されるヒーププロファイルのファイル名を指定します。

--heapsnapshot-near-heap-limit=max_count#

V8 ヒープの使用量がヒープ制限に近づいたときに V8 ヒープスナップショットをディスクに書き込みます。count は非負の整数でなければなりません (この場合、Node.js はディスクに max_count を超えるスナップショットを書き込みません)。

スナップショットを生成する際、ガベージコレクションがトリガーされ、ヒープ使用量が減少することがあります。そのため、Node.js インスタンスが最終的にメモリ不足になる前に、複数のスナップショットがディスクに書き込まれる可能性があります。これらのヒープスナップショットを比較することで、連続したスナップショットが取得される間にどのオブジェクトが割り当てられているかを判断できます。Node.js がディスクに正確に max_count 個のスナップショットを書き込むことは保証されていませんが、max_count が 0 より大きい場合、Node.js インスタンスがメモリ不足になる前に、少なくとも 1 つ、最大で max_count 個のスナップショットを生成しようとします。

V8 スナップショットの生成には時間とメモリ (V8 ヒープによって管理されるメモリと V8 ヒープ外のネイティブメモリの両方) がかかります。ヒープが大きいほど、より多くのリソースが必要です。Node.js は、追加の V8 ヒープメモリのオーバーヘッドに対応するために V8 ヒープを調整し、プロセスで利用可能なすべてのメモリを使い果たすことを避けるよう最善を尽くします。プロセスがシステムが適切と判断する以上のメモリを使用すると、システム構成によってはプロセスがシステムによって突然終了されることがあります。

$ node --max-old-space-size=100 --heapsnapshot-near-heap-limit=3 index.js
Wrote snapshot to Heap.20200430.100036.49580.0.001.heapsnapshot
Wrote snapshot to Heap.20200430.100037.49580.0.002.heapsnapshot
Wrote snapshot to Heap.20200430.100038.49580.0.003.heapsnapshot

<--- Last few GCs --->

[49580:0x110000000]     4826 ms: Mark-sweep 130.6 (147.8) -> 130.5 (147.8) MB, 27.4 / 0.0 ms  (average mu = 0.126, current mu = 0.034) allocation failure scavenge might not succeed
[49580:0x110000000]     4845 ms: Mark-sweep 130.6 (147.8) -> 130.6 (147.8) MB, 18.8 / 0.0 ms  (average mu = 0.088, current mu = 0.031) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
.... copy

--heapsnapshot-signal=signal#

指定されたシグナルを受信したときに Node.js プロセスがヒープダンプを書き込むシグナルハンドラを有効にします。signal は有効なシグナル名でなければなりません。デフォルトでは無効です。

$ node --heapsnapshot-signal=SIGUSR2 index.js &
$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
node         1  5.5  6.1 787252 247004 ?       Ssl  16:43   0:02 node --heapsnapshot-signal=SIGUSR2 index.js
$ kill -USR2 1
$ ls
Heap.20190718.133405.15554.0.001.heapsnapshot copy

-h, --help#

node コマンドラインオプションを出力します。このオプションの出力は、このドキュメントよりも詳細ではありません。

--icu-data-dir=file#

ICU データ読み込みパスを指定します。(NODE_ICU_DATA をオーバーライドします。)

--import=module#

起動時に指定されたモジュールをプリロードします。フラグが複数回指定された場合、各モジュールは表示順に、NODE_OPTIONS で指定されたものから順に実行されます。

ECMAScript モジュール解決ルールに従います。CommonJS モジュールをロードするには --require を使用してください。--require でプリロードされたモジュールは、--import でプリロードされたモジュールの前に実行されます。

モジュールは、メインスレッドだけでなく、ワーカースレッド、フォークされたプロセス、またはクラスタ化されたプロセスにもプリロードされます。

--input-type=type#

これにより、Node.js は --eval または STDIN の入力を CommonJS または ES モジュールとして解釈するように設定されます。有効な値は "commonjs"、"module"、"module-typescript"、"commonjs-typescript" です。"-typescript" 値は、フラグ --no-experimental-strip-types と一緒には使用できません。デフォルトは値なし、または --no-experimental-detect-module が渡された場合は "commonjs" です。

--input-type が指定されていない場合、Node.js は次の手順で構文を検出しようとします

1. 入力を CommonJS として実行します。
2. ステップ 1 が失敗した場合、入力を ES モジュールとして実行します。
3. ステップ 2 が SyntaxError で失敗した場合、型を削除します。
4. ステップ 3 がエラーコード ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX または ERR_INVALID_TYPESCRIPT_SYNTAX で失敗した場合、TypeScript エラーをメッセージに含めてステップ 2 のエラーをスローします。それ以外の場合は CommonJS として実行します。
5. ステップ 4 が失敗した場合、入力を ES モジュールとして実行します。

複数回の構文検出パスの遅延を避けるために、--input-type=type フラグを使用して --eval 入力をどのように解釈するかを指定できます。

REPL はこのオプションをサポートしていません。--print で --input-type=module を使用すると、--print は ES モジュール構文をサポートしていないため、エラーがスローされます。

--insecure-http-parser#

HTTP パーサーの寛容性フラグを有効にします。これにより、非準拠の HTTP 実装との相互運用性が可能になる場合があります。

有効にすると、パーサーは以下を受け入れます

• 無効な HTTP ヘッダー値。
• 無効な HTTP バージョン。
• Transfer-Encoding と Content-Length ヘッダーの両方を含むメッセージを許可します。
• Connection: close が存在する場合、メッセージの後の余分なデータを許可します。
• chunked が提供された後、追加の転送エンコーディングを許可します。
• \r\n の代わりに \n をトークン区切り文字として使用することを許可します。
• チャンクの後に \r\n が提供されないことを許可します。
• チャンクサイズの後に、\r\n の前にスペースが存在することを許可します。

上記のすべては、アプリケーションをリクエストスマグリングまたはポイズニング攻撃にさらします。このオプションの使用は避けてください。

--inspect-brk[=[host:]port]#

host:port でインスペクターを有効にし、ユーザースクリプトの開始時に中断します。デフォルトの host:port は 127.0.0.1:9229 です。ポート 0 が指定された場合、ランダムな利用可能なポートが使用されます。

Node.js デバッガーの詳細については、Node.js の V8 インスペクター統合を参照してください。

--inspect-port=[host:]port#

インスペクターが有効化されたときに使用される host:port を設定します。SIGUSR1 シグナルを送信してインスペクターを有効にする場合に便利です。--disable-sigusr1 が渡された場合を除きます。

デフォルトのホストは 127.0.0.1 です。ポート 0 が指定された場合、ランダムな利用可能なポートが使用されます。

host パラメータの使用に関する下のセキュリティ警告を参照してください。

--inspect-publish-uid=stderr,http#

インスペクターの Web ソケット URL の公開方法を指定します。

デフォルトでは、インスペクターの WebSocket URL は stderr と http://host:port/json/list の /json/list エンドポイントで利用できます。

--inspect-wait[=[host:]port]#

host:port でインスペクターを有効にし、デバッガーがアタッチされるのを待ちます。デフォルトの host:port は 127.0.0.1:9229 です。ポート 0 が指定された場合、ランダムな利用可能なポートが使用されます。

Node.js デバッガーの詳細については、Node.js の V8 インスペクター統合を参照してください。

--inspect[=[host:]port]#

host:port でインスペクターを有効にします。デフォルトは 127.0.0.1:9229 です。ポート 0 が指定された場合、ランダムな利用可能なポートが使用されます。

V8 インスペクター統合により、Chrome DevTools や IDE などのツールが Node.js インスタンスをデバッグおよびプロファイルできます。ツールは TCP ポートを介して Node.js インスタンスにアタッチし、Chrome DevTools Protocol を使用して通信します。Node.js デバッガーの詳細については、Node.js の V8 インスペクター統合を参照してください。

-i, --interactive#

stdin がターミナルではないように見える場合でも REPL を開きます。

--jitless#

実行可能メモリのランタイム割り当てを無効にします。これは、一部のプラットフォームでセキュリティ上の理由から必要になる場合があります。他のプラットフォームでも攻撃対象領域を減らすことができますが、パフォーマンスへの影響は深刻になる可能性があります。

--localstorage-file=file#

localStorage データを格納するために使用されるファイル。ファイルが存在しない場合、localStorage が初めてアクセスされたときに作成されます。同じファイルを複数の Node.js プロセスで同時に共有できます。Node.js が --no-webstorage (または --no-experimental-webstorage) フラグで開始された場合、このフラグは no-op (何もしない) です。

--max-http-header-size=size#

HTTP ヘッダーの最大サイズをバイト単位で指定します。デフォルトは 16 KiB です。

--max-old-space-size-percentage=percentage#

V8 の old メモリセクションの最大メモリサイズを、利用可能なシステムメモリのパーセンテージとして設定します。両方が指定された場合、このフラグは --max-old-space-size よりも優先されます。

percentage パラメータは、0 より大きく 100 以下の数値でなければならず、V8 ヒープに割り当てる利用可能なシステムメモリのパーセンテージを表します。

注: このフラグは --max-old-space-size を利用しますが、整数オーバーフローの問題により、32 ビットプラットフォームでは信頼できない場合があります。

# Using 50% of available system memory
node --max-old-space-size-percentage=50 index.js

# Using 75% of available system memory
node --max-old-space-size-percentage=75 index.js copy

--napi-modules#

このオプションは no-op です。互換性のために保持されています。

--network-family-autoselection-attempt-timeout#

ネットワークファミリー自動選択試行タイムアウトのデフォルト値を設定します。詳細については、net.getDefaultAutoSelectFamilyAttemptTimeout() を参照してください。

--no-addons#

node-addons エクスポート条件を無効にし、ネイティブアドオンの読み込みも無効にします。--no-addons が指定されている場合、process.dlopen の呼び出しやネイティブ C++ アドオンの require は失敗し、例外をスローします。

--no-async-context-frame#

AsyncContextFrame に裏付けられた AsyncLocalStorage の使用を無効にし、async_hooks に依存していた以前の実装を使用します。以前のモデルは、Electron との互換性や、コンテキストフローが異なる場合のために保持されています。ただし、フローの違いが見つかった場合は報告してください。

--no-deprecation#

非推奨の警告を抑制します。

--no-experimental-detect-module#

構文検出を使用したモジュールタイプの決定を無効にします。

--no-experimental-global-navigator#

グローバルスコープでの Navigator API の公開を無効にします。

--no-experimental-repl-await#

REPL でのトップレベル await を無効にするには、このフラグを使用します。

--no-experimental-require-module#

require() での同期的な ES モジュールグラフの読み込みサポートを無効にします。

require() を使用した ECMAScript モジュールのロードを参照してください。

--no-experimental-sqlite#

実験的な node:sqlite モジュールを無効にします。

--no-experimental-strip-types#

TypeScript ファイルの実験的な型削除を無効にします。詳細については、TypeScript の型削除ドキュメントを参照してください。

--no-experimental-websocket#

グローバルスコープでの <WebSocket> の公開を無効にします。

--no-extra-info-on-fatal-exception#

終了を引き起こす致命的な例外に関する追加情報を隠します。

--no-force-async-hooks-checks#

async_hooks のランタイムチェックを無効にします。これらは async_hooks が有効になっている場合には動的に有効になります。

--no-global-search-paths#

$HOME/.node_modules や $NODE_PATH のようなグローバルパスからモジュールを検索しません。

--no-network-family-autoselection#

接続オプションで明示的に有効にされていない限り、ファミリー自動選択アルゴリズムを無効にします。

--no-warnings#

すべてのプロセス警告（非推奨の警告を含む）を抑制します。

--no-webstorage#

Web Storage サポートを無効にします。

--node-memory-debug#

Node.js の内部でのメモリリークに対する追加のデバッグチェックを有効にします。これは通常、Node.js 自体をデバッグする開発者にのみ役立ちます。

--openssl-config=file#

起動時に OpenSSL 設定ファイルを読み込みます。他の用途の中でも、Node.js が FIPS 対応の OpenSSL に対してビルドされている場合、FIPS 準拠の暗号化を有効にするために使用できます。

--openssl-legacy-provider#

OpenSSL 3.0 のレガシープロバイダを有効にします。詳細については OSSL_PROVIDER-legacy を参照してください。

--openssl-shared-config#

OpenSSL のデフォルト設定セクションである openssl_conf が OpenSSL 設定ファイルから読み込まれるようにします。デフォルトの設定ファイル名は openssl.cnf ですが、これは環境変数 OPENSSL_CONF を使用するか、コマンドラインオプション --openssl-config を使用して変更できます。デフォルトの OpenSSL 設定ファイルの場所は、OpenSSL が Node.js にどのようにリンクされているかによって異なります。OpenSSL 設定を共有すると望ましくない影響が出る可能性があるため、Node.js 固有の設定セクションである nodejs_conf を使用することが推奨されます。このオプションが使用されない場合、これがデフォルトです。

--pending-deprecation#

ペンディング中の非推奨の警告を出力します。

ペンディング中の非推奨は、デフォルトで *オフ* になっており、--pending-deprecation コマンドラインフラグまたは NODE_PENDING_DEPRECATION=1 環境変数が設定されていない限り出力されないという顕著な例外を除いて、一般的にランタイムの非推奨と同じです。ペンディング中の非推奨は、開発者が非推奨 API の使用を検出するために利用できる、一種の選択的な「早期警告」メカニズムを提供するために使用されます。

--permission#

現在のプロセスに対して権限モデルを有効にします。有効にすると、次の権限が制限されます。

• ファイルシステム - --allow-fs-read、--allow-fs-write フラグで管理可能
• ネットワーク - --allow-net フラグで管理可能
• 子プロセス - --allow-child-process フラグで管理可能
• ワーカースレッド - --allow-worker フラグで管理可能
• WASI - --allow-wasi フラグで管理可能
• アドオン - --allow-addons フラグで管理可能

--preserve-symlinks#

モジュールの解決とキャッシュ時にシンボリックリンクを保持するようモジュールローダに指示します。

デフォルトでは、Node.js はディスク上の別の場所にシンボリックリンクされているパスからモジュールを読み込むとき、リンクをデリファレンスし、モジュールの実際のディスク上の「実パス」を識別子として、また他の依存モジュールを見つけるためのルートパスとして使用します。ほとんどの場合、このデフォルトの動作で問題ありません。しかし、以下の例で示されるように、シンボリックリンクされたピア依存関係を使用する場合、moduleA が moduleB をピア依存関係として require しようとすると、デフォルトの動作では例外がスローされます。

{appDir}
 ├── app
 │   ├── index.js
 │   └── node_modules
 │       ├── moduleA -> {appDir}/moduleA
 │       └── moduleB
 │           ├── index.js
 │           └── package.json
 └── moduleA
     ├── index.js
     └── package.json copy

--preserve-symlinks コマンドラインフラグは、Node.js にモジュールの実パスではなくシンボリックリンクのパスを使用するよう指示し、シンボリックリンクされたピア依存関係が見つかるようにします。

ただし、--preserve-symlinks を使用すると他の副作用が生じる可能性があることに注意してください。具体的には、シンボリックリンクされた *ネイティブ* モジュールが依存関係ツリー内の複数の場所からリンクされている場合、読み込みに失敗することがあります (Node.js はそれらを 2 つの別々のモジュールと見なし、モジュールを複数回読み込もうとして例外をスローします)。

--preserve-symlinks フラグはメインモジュールには適用されないため、node --preserve-symlinks node_module/.bin/<foo> は機能します。メインモジュールに同じ動作を適用するには、--preserve-symlinks-main も使用してください。

--preserve-symlinks-main#

メインモジュール (require.main) の解決とキャッシュ時にシンボリックリンクを保持するようモジュールローダに指示します。

このフラグは、メインモジュールが --preserve-symlinks が他のすべてのインポートに与えるのと同じ動作を選択できるように存在します。ただし、古い Node.js バージョンとの後方互換性のために、これらは別々のフラグです。

--preserve-symlinks-main は --preserve-symlinks を意味しません。相対パスを解決する前にシンボリックリンクをたどることが望ましくない場合は、--preserve-symlinks に加えて --preserve-symlinks-main を使用してください。

詳細については --preserve-symlinks を参照してください。

-p, --print "script"#

-e と同じですが、結果を出力します。

--prof#

V8 プロファイラ出力を生成します。

--prof-process#

V8 オプション --prof を使用して生成された V8 プロファイラ出力を処理します。

--redirect-warnings=file#

プロセスの警告を stderr に出力する代わりに、指定されたファイルに書き込みます。ファイルが存在しない場合は作成され、存在する場合は追記されます。ファイルへの警告の書き込み試行中にエラーが発生した場合、警告は代わりに stderr に書き込まれます。

file 名は絶対パスでもかまいません。そうでない場合、書き込まれるデフォルトのディレクトリは --diagnostic-dir コマンドラインオプションによって制御されます。

--report-compact#

人間が消費するために設計されたデフォルトの複数行形式よりも、ログ処理システムで消費しやすい、単一行の JSON のコンパクトな形式でレポートを書き込みます。

--report-dir=directory, report-directory=directory#

レポートが生成される場所。

--report-exclude-env#

--report-exclude-env が渡されると、生成される診断レポートには environmentVariables データが含まれなくなります。

--report-exclude-network#

診断レポートから header.networkInterfaces を除外します。デフォルトではこれは設定されておらず、ネットワークインターフェイスが含まれます。

--report-filename=filename#

レポートが書き込まれるファイルの名前。

ファイル名が 'stdout' または 'stderr' に設定されている場合、レポートはそれぞれプロセスの標準出力または標準エラー出力に書き込まれます。

--report-on-fatalerror#

アプリケーションの終了につながる致命的なエラー（メモリ不足などの Node.js ランタイム内の内部エラー）でレポートがトリガーされるようにします。ヒープ、スタック、イベントループの状態、リソース消費など、さまざまな診断データ要素を調査して、致命的なエラーの原因を究明するのに役立ちます。

--report-on-signal#

実行中の Node.js プロセスが指定された（または事前定義された）シグナルを受信したときにレポートが生成されるようにします。レポートをトリガーするシグナルは --report-signal を通じて指定されます。

--report-signal=signal#

レポート生成用のシグナルを設定またはリセットします（Windows ではサポートされていません）。デフォルトのシグナルは SIGUSR2 です。

--report-uncaught-exception#

キャッチされない例外によってプロセスが終了するときにレポートが生成されるようにします。JavaScript スタックをネイティブスタックや他のランタイム環境データと併せて調査する際に役立ちます。

-r, --require module#

起動時に指定されたモジュールをプリロードします。

require() のモジュール解決ルールに従います。module はファイルへのパス、または node モジュール名のいずれかです。

--require でプリロードされたモジュールは、--import でプリロードされたモジュールの前に実行されます。

モジュールは、メインスレッドだけでなく、ワーカースレッド、フォークされたプロセス、またはクラスタ化されたプロセスにもプリロードされます。

--run#

これは、package.json の "scripts" オブジェクトから指定されたコマンドを実行します。存在しない "command" が提供された場合、利用可能なスクリプトを一覧表示します。

--run は、ルートディレクトリまでさかのぼり、コマンドを実行するための package.json ファイルを見つけます。

--run は、複数の node_modules ディレクトリが存在する場合に、異なるフォルダからバイナリを実行するために、カレントディレクトリの各祖先ディレクトリの ./node_modules/.bin を PATH の先頭に追加します (ただし、ancestor-folder/node_modules/.bin がディレクトリである場合)。

--run は、関連する package.json を含むディレクトリでコマンドを実行します。

例えば、次のコマンドはカレントフォルダの package.json の test スクリプトを実行します。

$ node --run test copy

コマンドに引数を渡すこともできます。-- の後の引数はスクリプトに追加されます。

$ node --run test -- --verbose copy

--secure-heap-min=n#

--secure-heap を使用する場合、--secure-heap-min フラグはセキュアヒープからの最小割り当てを指定します。最小値は 2 です。最大値は --secure-heap または 2147483647 の小さい方です。指定する値は 2 のべき乗でなければなりません。

--secure-heap=n#

n バイトの OpenSSL セキュアヒープを初期化します。初期化されると、セキュアヒープは鍵生成やその他の操作中に OpenSSL 内の選択されたタイプの割り当てに使用されます。これは、例えば、ポインタのオーバーランやアンダーランによる機密情報の漏洩を防ぐのに役立ちます。

セキュアヒープは固定サイズであり、実行時にリサイズできないため、使用する場合は、すべてのアプリケーションの使用をカバーするのに十分な大きさのヒープを選択することが重要です。

指定するヒープサイズは 2 のべき乗でなければなりません。2 未満の値はセキュアヒープを無効にします。

セキュアヒープはデフォルトで無効です。

セキュアヒープは Windows では利用できません。

詳細については CRYPTO_secure_malloc_init を参照してください。

--snapshot-blob=path#

--build-snapshot と共に使用する場合、--snapshot-blob は生成されたスナップショットブロブが書き込まれるパスを指定します。指定しない場合、生成されたブロブは現在の作業ディレクトリの snapshot.blob に書き込まれます。

--build-snapshot なしで使用する場合、--snapshot-blob はアプリケーションの状態を復元するために使用されるブロブへのパスを指定します。

スナップショットを読み込む際、Node.js は以下を確認します。

1. 実行中の Node.js バイナリのバージョン、アーキテクチャ、プラットフォームが、スナップショットを生成したバイナリのものと完全に同じであること。
2. V8 フラグと CPU 機能が、スナップショットを生成したバイナリのものと互換性があること。

一致しない場合、Node.js はスナップショットの読み込みを拒否し、ステータスコード 1 で終了します。

--test#

Node.js のコマンドラインテストランナーを開始します。このフラグは --watch-path, --check, --eval, --interactive, またはインスペクタと組み合わせることはできません。詳細については、コマンドラインからのテスト実行に関するドキュメントを参照してください。

--test-concurrency#

テストランナー CLI が並行して実行するテストファイルの最大数。--test-isolation が 'none' に設定されている場合、このフラグは無視され、並行数は 1 になります。それ以外の場合、並行数はデフォルトで os.availableParallelism() - 1 になります。

--test-coverage-branches=threshold#

カバーされるブランチの最小パーセントを要求します。コードカバレッジが指定されたしきい値に達しない場合、プロセスはコード 1 で終了します。

--test-coverage-exclude#

絶対パスと相対パスの両方に一致する glob パターンを使用して、特定のファイルをコードカバレッジから除外します。

このオプションは、複数の glob パターンを除外するために複数回指定できます。

--test-coverage-exclude と --test-coverage-include の両方が提供された場合、ファイルはカバレッジレポートに含まれるために **両方** の基準を満たす必要があります。

デフォルトでは、一致するすべてのテストファイルがカバレッジレポートから除外されます。このオプションを指定すると、デフォルトの動作が上書きされます。

--test-coverage-functions=threshold#

カバーされる関数の最小パーセントを要求します。コードカバレッジが指定されたしきい値に達しない場合、プロセスはコード 1 で終了します。

--test-coverage-include#

絶対パスと相対パスの両方に一致する glob パターンを使用して、特定のファイルをコードカバレッジに含めます。

このオプションは、複数の glob パターンを含めるために複数回指定できます。

--test-coverage-exclude と --test-coverage-include の両方が提供された場合、ファイルはカバレッジレポートに含まれるために **両方** の基準を満たす必要があります。

--test-coverage-lines=threshold#

カバーされる行の最小パーセントを要求します。コードカバレッジが指定されたしきい値に達しない場合、プロセスはコード 1 で終了します。

--test-force-exit#

テストランナーを設定して、イベントループがアクティブなままであっても、既知のすべてのテストの実行が完了したらプロセスを終了するようにします。

--test-global-setup=module#

すべてのテストが実行される前に評価されるモジュールを指定します。これは、テストのグローバルな状態やフィクスチャをセットアップするために使用できます。

詳細については、グローバルなセットアップとティアダウンに関するドキュメントを参照してください。

--test-isolation=mode#

テストランナーで使用されるテスト分離のタイプを設定します。mode が 'process' の場合、各テストファイルは別の子プロセスで実行されます。mode が 'none' の場合、すべてのテストファイルはテストランナーと同じプロセスで実行されます。デフォルトの分離モードは 'process' です。このフラグは --test フラグが存在しない場合は無視されます。詳細については、テストランナーの実行モデルのセクションを参照してください。

--test-name-pattern#

提供されたパターンに名前が一致するテストのみを実行するようにテストランナーを設定する正規表現。詳細については、名前によるテストのフィルタリングに関するドキュメントを参照してください。

--test-name-pattern と --test-skip-pattern の両方が指定された場合、テストは実行されるために **両方** の要件を満たす必要があります。

--test-only#

only オプションが設定されているトップレベルのテストのみを実行するようにテストランナーを設定します。テスト分離が無効になっている場合、このフラグは必要ありません。

--test-reporter#

テスト実行時に使用するテストレポータ。詳細については、テストレポータに関するドキュメントを参照してください。

--test-reporter-destination#

対応するテストレポータの出力先。詳細については、テストレポータに関するドキュメントを参照してください。

--test-rerun-failures#

テストランナーが実行間でテストスイートの状態を永続化できるようにするファイルへのパス。テストランナーはこのファイルを使用して、どのテストがすでに成功または失敗したかを判断し、テストスイート全体を再実行することなく、失敗したテストのみを再実行できるようにします。テストランナーは、このファイルが存在しない場合に作成します。詳細については、テストの再実行に関するドキュメントを参照してください。

--test-shard#

実行するテストスイートのシャードを <index>/<total> の形式で指定します。ここで、

• index は正の整数で、分割された部分のインデックスです。
• total は正の整数で、分割された部分の合計です。

このコマンドは、すべてのテストファイルを total 個の等しい部分に分割し、index 番目の部分にあるものだけを実行します。

例えば、テストスイートを3つの部分に分割するには、次のようにします。

node --test --test-shard=1/3
node --test --test-shard=2/3
node --test --test-shard=3/3 copy

--test-skip-pattern#

提供されたパターンに名前が一致するテストをスキップするようにテストランナーを設定する正規表現。詳細については、名前によるテストのフィルタリングに関するドキュメントを参照してください。

--test-name-pattern と --test-skip-pattern の両方が指定された場合、テストは実行されるために **両方** の要件を満たす必要があります。

--test-timeout#

テスト実行がこのミリ秒数後に失敗します。指定されていない場合、サブテストはこの値を親から継承します。デフォルト値は Infinity です。

--test-update-snapshots#

スナップショットテストのためにテストランナーが使用するスナップショットファイルを再生成します。

--throw-deprecation#

非推奨に対してエラーをスローします。

--title=title#

起動時に process.title を設定します。

--tls-cipher-list=list#

代替のデフォルト TLS 暗号リストを指定します。Node.js が暗号化サポート付きでビルドされている必要があります（デフォルト）。

--tls-keylog=file#

TLS 鍵情報をファイルに記録します。鍵情報は NSS SSLKEYLOGFILE 形式であり、ソフトウェア（Wireshark など）で TLS トラフィックを復号化するために使用できます。

--tls-max-v1.2#

tls.DEFAULT_MAX_VERSION を 'TLSv1.2' に設定します。TLSv1.3 のサポートを無効にするために使用します。

--tls-max-v1.3#

デフォルトの tls.DEFAULT_MAX_VERSION を 'TLSv1.3' に設定します。TLSv1.3 のサポートを有効にするために使用します。

--tls-min-v1.0#

デフォルトの tls.DEFAULT_MIN_VERSION を 'TLSv1' に設定します。古い TLS クライアントまたはサーバーとの互換性のために使用します。

--tls-min-v1.1#

デフォルトの tls.DEFAULT_MIN_VERSION を 'TLSv1.1' に設定します。古い TLS クライアントまたはサーバーとの互換性のために使用します。

--tls-min-v1.2#

デフォルトの tls.DEFAULT_MIN_VERSION を 'TLSv1.2' に設定します。これは 12.x 以降のデフォルトですが、このオプションは古い Node.js バージョンとの互換性のためにサポートされています。

--tls-min-v1.3#

デフォルトの tls.DEFAULT_MIN_VERSION を 'TLSv1.3' に設定します。TLSv1.3 ほど安全ではない TLSv1.2 のサポートを無効にするために使用します。

--trace-deprecation#

非推奨に対するスタックトレースを出力します。

--trace-env#

現在の Node.js インスタンスで行われた環境変数へのアクセスに関する情報を stderr に出力します。これには以下が含まれます。

• Node.js が内部的に行う環境変数の読み取り。
• process.env.KEY = "SOME VALUE" 形式の書き込み。
• process.env.KEY 形式の読み取り。
• Object.defineProperty(process.env, 'KEY', {...}) 形式の定義。
• Object.hasOwn(process.env, 'KEY'), process.env.hasOwnProperty('KEY') または 'KEY' in process.env 形式のクエリ。
• delete process.env.KEY 形式の削除。
• ...process.env または Object.keys(process.env) 形式の列挙。

アクセスされている環境変数の名前のみが出力されます。値は出力されません。

アクセスのスタックトレースを出力するには、--trace-env-js-stack および/または --trace-env-native-stack を使用します。

--trace-env-js-stack#

--trace-env が行うことに加えて、これはアクセスの JavaScript スタックトレースを出力します。

--trace-env-native-stack#

--trace-env が行うことに加えて、これはアクセスのネイティブスタックトレースを出力します。

--trace-event-categories#

--trace-events-enabled を使用してトレースイベントのトレースが有効になっている場合にトレースされるべきカテゴリのコンマ区切りリスト。

--trace-event-file-pattern#

トレースイベントデータのファイルパスを指定するテンプレート文字列で、${rotation} と ${pid} をサポートします。

--trace-events-enabled#

トレースイベントのトレース情報の収集を有効にします。

--trace-exit#

環境がプロアクティブに終了されるたび、つまり process.exit() を呼び出すたびにスタックトレースを出力します。

--trace-require-module=mode#

require() を使用した ECMAScript モジュールの読み込みの使用に関する情報を出力します。

mode が all の場合、すべての使用状況が出力されます。mode が no-node-modules の場合、node_modules フォルダからの使用状況は除外されます。

--trace-sigint#

SIGINT でスタックトレースを出力します。

--trace-sync-io#

イベントループの最初のターン後に同期 I/O が検出されるたびにスタックトレースを出力します。

--trace-tls#

TLS パケットのトレース情報を stderr に出力します。これは TLS 接続の問題をデバッグするために使用できます。

--trace-uncaught#

キャッチされない例外のスタックトレースを出力します。通常、Error の作成に関連付けられたスタックトレースが出力されますが、これにより Node.js は値をスローすることに関連付けられたスタックトレースも出力します (これは Error インスタンスである必要はありません)。

このオプションを有効にすると、ガベージコレクションの動作に悪影響を与える可能性があります。

--trace-warnings#

プロセス警告（非推奨を含む）のスタックトレースを出力します。

--track-heap-objects#

ヒープスナップショットのためにヒープオブジェクトの割り当てを追跡します。

--unhandled-rejections=mode#

このフラグを使用すると、未処理の拒否が発生した場合に何が起こるかを変更できます。以下のモードのいずれかを選択できます。

• throw: unhandledRejection を発行します。このフックが設定されていない場合、未処理の拒否をキャッチされない例外として発生させます。これがデフォルトです。
• strict: 未処理の拒否をキャッチされない例外として発生させます。例外が処理された場合、unhandledRejection が発行されます。
• warn: unhandledRejection フックが設定されているかどうかに関わらず常に警告をトリガーしますが、非推奨の警告は出力しません。
• warn-with-error-code: unhandledRejection を発行します。このフックが設定されていない場合、警告をトリガーし、プロセス終了コードを 1 に設定します。
• none: すべての警告を抑制します。

コマンドラインエントリポイントの ES モジュール静的読み込みフェーズ中に拒否が発生した場合、それは常にキャッチされない例外として発生します。

--use-bundled-ca, --use-openssl-ca#

現在の Node.js バージョンで提供されるバンドルされた Mozilla CA ストアを使用するか、OpenSSL のデフォルト CA ストアを使用します。デフォルトのストアはビルド時に選択可能です。

Node.js によって提供されるバンドルされた CA ストアは、リリース時に固定された Mozilla CA ストアのスナップショットです。サポートされているすべてのプラットフォームで同一です。

OpenSSL ストアを使用すると、ストアの外部からの変更が可能になります。ほとんどの Linux および BSD ディストリビューションでは、このストアはディストリビューションのメンテナーとシステム管理者によって維持されます。OpenSSL CA ストアの場所は OpenSSL ライブラリの設定に依存しますが、これは実行時に環境変数を使用して変更できます。

SSL_CERT_DIR と SSL_CERT_FILE を参照してください。

--use-env-proxy#

有効にすると、Node.js は起動時に HTTP_PROXY、HTTPS_PROXY、NO_PROXY 環境変数を解析し、指定されたプロキシ経由でリクエストをトンネリングします。

これは NODE_USE_ENV_PROXY=1 環境変数を設定するのと同じです。両方が設定されている場合、--use-env-proxy が優先されます。

--use-largepages=mode#

起動時に Node.js の静的コードをラージメモリページに再マッピングします。ターゲットシステムでサポートされている場合、これにより Node.js の静的コードは 4 KiB ページではなく 2 MiB ページに移動されます。

mode には以下の値が有効です。

• off: マッピングは試みられません。これがデフォルトです。
• on: OS でサポートされている場合、マッピングが試みられます。マッピングに失敗しても無視され、標準エラーにメッセージが出力されます。
• silent: OS でサポートされている場合、マッピングが試みられます。マッピングに失敗しても無視され、報告されません。

--use-system-ca#

Node.js は、--use-bundled-ca オプションおよび NODE_EXTRA_CA_CERTS 環境変数と共に、システムストアに存在する信頼された CA 証明書を使用します。Windows および macOS 以外のプラットフォームでは、これは --use-openssl-ca と同様に OpenSSL によって信頼されたディレクトリとファイルから証明書を読み込みますが、最初の読み込み後に証明書をキャッシュする点が異なります。

Windows と macOS では、証明書の信頼ポリシーは ローカルで信頼された証明書に対する Chromium のポリシーに従うことが計画されています。

macOS では、以下の設定が尊重されます。

• デフォルトおよびシステムキーチェーン
  • 信頼
    • 「この証明書を使用するとき」フラグが「常に信頼」に設定されている証明書、または
    • 「Secure Sockets Layer (SSL)」フラグが「常に信頼」に設定されている証明書。
  • 信頼しない
    • 「この証明書を使用するとき」フラグが「信頼しない」に設定されている証明書、または
    • 「Secure Sockets Layer (SSL)」フラグが「信頼しない」に設定されている証明書。

Windows では、以下の設定が尊重されます（Chromium のポリシーとは異なり、信頼しない設定と中間 CA は現在サポートされていません）。

• ローカルマシン（certlm.msc でアクセス）
  • 信頼
    • 信頼されたルート証明機関
    • 信頼された人々
    • エンタープライズの信頼 -> エンタープライズ -> 信頼されたルート証明機関
    • エンタープライズの信頼 -> エンタープライズ -> 信頼された人々
    • エンタープライズの信頼 -> グループポリシー -> 信頼されたルート証明機関
    • エンタープライズの信頼 -> グループポリシー -> 信頼された人々
• 現在のユーザー（certmgr.msc でアクセス）
  • 信頼
    • 信頼されたルート証明機関
    • エンタープライズの信頼 -> グループポリシー -> 信頼されたルート証明機関

Windows と macOS では、Node.js は証明書を使用する前に、ユーザー設定が TLS サーバー認証を禁止していないことを確認します。

他のシステムでは、Node.js は、Node.js がリンクする OpenSSL のバージョンが尊重するデフォルトの証明書ファイル（通常は /etc/ssl/cert.pem）とデフォルトの証明書ディレクトリ（通常は /etc/ssl/certs）から証明書をロードします。これは通常、主要な Linux ディストリビューションや他の Unix ライクなシステムでの慣習と一致します。上書きする OpenSSL 環境変数（通常は Node.js がリンクする OpenSSL の設定に応じて SSL_CERT_FILE と SSL_CERT_DIR）が設定されている場合、指定されたパスが代わりに証明書のロードに使用されます。これらの環境変数は、何らかの理由で Node.js がリンクする OpenSSL のバージョンが使用する慣習的なパスがユーザーのシステム構成と一致しない場合の回避策として使用できます。

--v8-options#

V8 のコマンドラインオプションを出力します。

--v8-pool-size=num#

バックグラウンドジョブの割り当てに使用される V8 のスレッドプールサイズを設定します。

0 に設定すると、Node.js は並列処理の量の推定に基づいて適切なスレッドプールサイズを選択します。

並列処理の量とは、特定の機械で同時に実行できる計算の数を指します。一般的には CPU の数と同じですが、VM やコンテナなどの環境では異なる場合があります。

-v, --version#

node のバージョンを出力します。

--watch#

Node.js をウォッチモードで開始します。ウォッチモードでは、監視対象のファイルに変更があると Node.js プロセスが再起動します。デフォルトでは、ウォッチモードはエントリポイントと、require または import されたモジュールを監視します。監視するパスを指定するには --watch-path を使用してください。

このフラグは --check, --eval, --interactive, または REPL と組み合わせることはできません。

注: --watch フラグは引数としてファイルパスを必要とし、--run またはインラインスクリプト入力とは互換性がありません。--run が優先され、ウォッチモードは無視されるためです。ファイルが提供されない場合、Node.js はステータスコード 9 で終了します。

node --watch index.js copy

--watch-kill-signal#

ウォッチモードの再起動時にプロセスに送信されるシグナルをカスタマイズします。

node --watch --watch-kill-signal SIGINT test.js copy

--watch-path#

Node.js をウォッチモードで開始し、監視するパスを指定します。ウォッチモードでは、監視対象のパスに変更があると Node.js プロセスが再起動します。これは、--watch と組み合わせて使用した場合でも、require または import されたモジュールの監視をオフにします。

このフラグは --check, --eval, --interactive, --test, または REPL と組み合わせることはできません。

注: --watch-path を使用すると暗黙的に --watch が有効になります。これはファイルパスを必要とし、--run とは互換性がありません。--run が優先され、ウォッチモードが無視されるためです。

node --watch-path=./src --watch-path=./tests index.js copy

このオプションは macOS と Windows でのみサポートされています。サポートされていないプラットフォームでオプションが使用されると、ERR_FEATURE_UNAVAILABLE_ON_PLATFORM 例外がスローされます。

--watch-preserve-output#

ウォッチモードがプロセスを再起動するときにコンソールがクリアされるのを無効にします。

node --watch --watch-preserve-output test.js copy

--zero-fill-buffers#

新しく割り当てられたすべての Buffer インスタンスを自動的にゼロで埋めます。

FORCE_COLOR=[1, 2, 3]#

FORCE_COLOR 環境変数は、ANSI カラー出力を有効にするために使用されます。値は次のいずれかです。

• 1、true、または空文字列 '' は 16 色サポートを示します。
• 2 は 256 色サポートを示します。
• 3 は 1600 万色サポートを示します。

FORCE_COLOR が使用され、サポートされている値に設定されている場合、NO_COLOR と NODE_DISABLE_COLORS の両方の環境変数は無視されます。

その他の値は、カラー出力が無効になります。

NODE_COMPILE_CACHE=dir#

Node.js インスタンスの モジュールコンパイルキャッシュを有効にします。詳細については、モジュールコンパイルキャッシュのドキュメントを参照してください。

NODE_COMPILE_CACHE_PORTABLE=1#

1 に設定すると、キャッシュディレクトリに対するモジュールのレイアウトが同じである限り、モジュールコンパイルキャッシュを異なるディレクトリの場所で再利用できます。

NODE_DEBUG=module[,…]#

デバッグ情報を出力すべきコアモジュールの ',' 区切りリスト。

NODE_DEBUG_NATIVE=module[,…]#

デバッグ情報を出力すべきコア C++ モジュールの ',' 区切りリスト。

NODE_DISABLE_COLORS=1#

設定すると、REPL で色は使用されません。

NODE_DISABLE_COMPILE_CACHE=1#

Node.js インスタンスの モジュールコンパイルキャッシュを無効にします。詳細については、モジュールコンパイルキャッシュのドキュメントを参照してください。

NODE_EXTRA_CA_CERTS=file#

設定すると、既知の「ルート」CA（VeriSignなど）が file 内の追加の証明書で拡張されます。ファイルは PEM 形式の 1 つ以上の信頼された証明書で構成されている必要があります。ファイルが見つからないか、形式が不正な場合、メッセージが（一度）process.emitWarning() で発行されますが、その他のエラーは無視されます。

TLS または HTTPS クライアントまたはサーバーに対して ca オプションプロパティが明示的に指定されている場合、既知の証明書も追加の証明書も使用されません。

この環境変数は、node が setuid root として実行されるか、Linux ファイルケーパビリティが設定されている場合は無視されます。

NODE_EXTRA_CA_CERTS 環境変数は、Node.js プロセスが最初に起動されるときにのみ読み取られます。実行時に process.env.NODE_EXTRA_CA_CERTS を使用して値を変更しても、現在のプロセスには影響しません。

NODE_ICU_DATA=file#

ICU (Intl オブジェクト) データのデータパス。small-icu サポートでコンパイルされた場合、リンクされたデータを拡張します。

NODE_NO_WARNINGS=1#

1 に設定すると、プロセスの警告は抑制されます。

NODE_OPTIONS=options...#

スペース区切りのコマンドラインオプションのリスト。options... はコマンドラインオプションの前に解釈されるため、コマンドラインオプションは options... の内容を上書きまたは追加します。-p やスクリプトファイルなど、環境で許可されていないオプションが使用された場合、Node.js はエラーで終了します。

オプションの値にスペースが含まれる場合、二重引用符を使用してエスケープできます。

NODE_OPTIONS='--require "./my path/file.js"' copy

コマンドラインオプションとして渡されたシングルトンフラグは、NODE_OPTIONS に渡された同じフラグを上書きします。

# The inspector will be available on port 5555
NODE_OPTIONS='--inspect=localhost:4444' node --inspect=localhost:5555 copy

複数回渡すことができるフラグは、まず NODE_OPTIONS のインスタンスが渡され、その後でコマンドラインのインスタンスが渡されたかのように扱われます。

NODE_OPTIONS='--require "./a.js"' node --require "./b.js"
# is equivalent to:
node --require "./a.js" --require "./b.js" copy

許可されている Node.js オプションは以下のリストにあります。オプションが --XX と --no-XX の両方のバリアントをサポートしている場合、両方がサポートされていますが、以下のリストには片方のみが含まれています。

• --allow-addons
• --allow-child-process
• --allow-fs-read
• --allow-fs-write
• --allow-inspector
• --allow-net
• --allow-wasi
• --allow-worker
• --conditions, -C
• --cpu-prof-dir
• --cpu-prof-interval
• --cpu-prof-name
• --cpu-prof
• --diagnostic-dir
• --disable-proto
• --disable-sigusr1
• --disable-warning
• --disable-wasm-trap-handler
• --dns-result-order
• --enable-fips
• --enable-network-family-autoselection
• --enable-source-maps
• --entry-url
• --experimental-abortcontroller
• --experimental-addon-modules
• --experimental-detect-module
• --experimental-eventsource
• --experimental-import-meta-resolve
• --experimental-json-modules
• --experimental-loader
• --experimental-modules
• --experimental-print-required-tla
• --experimental-quic
• --experimental-require-module
• --experimental-shadow-realm
• --experimental-specifier-resolution
• --experimental-test-isolation
• --experimental-top-level-await
• --experimental-transform-types
• --experimental-vm-modules
• --experimental-wasi-unstable-preview1
• --force-context-aware
• --force-fips
• --force-node-api-uncaught-exceptions-policy
• --frozen-intrinsics
• --heap-prof-dir
• --heap-prof-interval
• --heap-prof-name
• --heap-prof
• --heapsnapshot-near-heap-limit
• --heapsnapshot-signal
• --http-parser
• --icu-data-dir
• --import
• --input-type
• --insecure-http-parser
• --inspect-brk
• --inspect-port, --debug-port
• --inspect-publish-uid
• --inspect-wait
• --inspect
• --localstorage-file
• --max-http-header-size
• --max-old-space-size-percentage
• --napi-modules
• --network-family-autoselection-attempt-timeout
• --no-addons
• --no-async-context-frame
• --no-deprecation
• --no-experimental-global-navigator
• --no-experimental-repl-await
• --no-experimental-sqlite
• --no-experimental-strip-types
• --no-experimental-websocket
• --no-experimental-webstorage
• --no-extra-info-on-fatal-exception
• --no-force-async-hooks-checks
• --no-global-search-paths
• --no-network-family-autoselection
• --no-warnings
• --no-webstorage
• --node-memory-debug
• --openssl-config
• --openssl-legacy-provider
• --openssl-shared-config
• --pending-deprecation
• --permission
• --preserve-symlinks-main
• --preserve-symlinks
• --prof-process
• --redirect-warnings
• --report-compact
• --report-dir, --report-directory
• --report-exclude-env
• --report-exclude-network
• --report-filename
• --report-on-fatalerror
• --report-on-signal
• --report-signal
• --report-uncaught-exception
• --require, -r
• --secure-heap-min
• --secure-heap
• --snapshot-blob
• --test-coverage-branches
• --test-coverage-exclude
• --test-coverage-functions
• --test-coverage-include
• --test-coverage-lines
• --test-global-setup
• --test-isolation
• --test-name-pattern
• --test-only
• --test-reporter-destination
• --test-reporter
• --test-rerun-failures
• --test-shard
• --test-skip-pattern
• --throw-deprecation
• --title
• --tls-cipher-list
• --tls-keylog
• --tls-max-v1.2
• --tls-max-v1.3
• --tls-min-v1.0
• --tls-min-v1.1
• --tls-min-v1.2
• --tls-min-v1.3
• --trace-deprecation
• --trace-env-js-stack
• --trace-env-native-stack
• --trace-env
• --trace-event-categories
• --trace-event-file-pattern
• --trace-events-enabled
• --trace-exit
• --trace-require-module
• --trace-sigint
• --trace-sync-io
• --trace-tls
• --trace-uncaught
• --trace-warnings
• --track-heap-objects
• --unhandled-rejections
• --use-bundled-ca
• --use-env-proxy
• --use-largepages
• --use-openssl-ca
• --use-system-ca
• --v8-pool-size
• --watch-kill-signal
• --watch-path
• --watch-preserve-output
• --watch
• --zero-fill-buffers

許可されている V8 オプションは次のとおりです。

• --abort-on-uncaught-exception
• --disallow-code-generation-from-strings
• --enable-etw-stack-walking
• --expose-gc
• --interpreted-frames-native-stack
• --jitless
• --max-old-space-size
• --max-semi-space-size
• --perf-basic-prof-only-functions
• --perf-basic-prof
• --perf-prof-unwinding-info
• --perf-prof
• --stack-trace-limit

--perf-basic-prof-only-functions, --perf-basic-prof, --perf-prof-unwinding-info, および --perf-prof は Linux でのみ利用可能です。

--enable-etw-stack-walking は Windows でのみ利用可能です。

NODE_PATH=path[:…]#

モジュール検索パスの先頭に追加されるディレクトリの ':' 区切りリスト。

Windows では、これは ';' 区切りのリストです。

NODE_PENDING_DEPRECATION=1#

1 に設定すると、ペンディング中の非推奨の警告を出力します。

ペンディング中の非推奨は、デフォルトで *オフ* になっており、--pending-deprecation コマンドラインフラグまたは NODE_PENDING_DEPRECATION=1 環境変数が設定されていない限り出力されないという顕著な例外を除いて、一般的にランタイムの非推奨と同じです。ペンディング中の非推奨は、開発者が非推奨 API の使用を検出するために利用できる、一種の選択的な「早期警告」メカニズムを提供するために使用されます。

NODE_PENDING_PIPE_INSTANCES=instances#

パイプサーバーが接続を待機しているときの保留中のパイプインスタンスハンドルの数を設定します。この設定は Windows にのみ適用されます。

NODE_PRESERVE_SYMLINKS=1#

1 に設定すると、モジュールの解決とキャッシュ時にシンボリックリンクを保持するようモジュールローダに指示します。

NODE_REDIRECT_WARNINGS=file#

設定すると、プロセスの警告は stderr に出力される代わりに指定されたファイルに出力されます。ファイルが存在しない場合は作成され、存在する場合は追記されます。ファイルへの警告の書き込み試行中にエラーが発生した場合、警告は代わりに stderr に書き込まれます。これは --redirect-warnings=file コマンドラインフラグを使用するのと同じです。

NODE_REPL_EXTERNAL_MODULE=file#

組み込み REPL の代わりにロードされる Node.js モジュールへのパス。この値を空文字列 ('') に上書きすると、組み込み REPL が使用されます。

NODE_REPL_HISTORY=file#

永続的な REPL 履歴を保存するために使用されるファイルへのパス。デフォルトのパスは ~/.node_repl_history で、この変数によって上書きされます。値を空文字列 ('' または ' ') に設定すると、永続的な REPL 履歴が無効になります。

NODE_SKIP_PLATFORM_CHECK=value#

value が '1' に等しい場合、Node.js の起動時にサポートされているプラットフォームのチェックがスキップされます。Node.js は正しく実行されない可能性があります。サポートされていないプラットフォームで発生した問題は修正されません。

NODE_TEST_CONTEXT=value#

value が 'child' に等しい場合、テストレポータのオプションは上書きされ、テスト出力は TAP 形式で標準出力に送信されます。他の値が提供された場合、Node.js は使用されるレポータ形式やその安定性について保証しません。

NODE_TLS_REJECT_UNAUTHORIZED=value#

value が '0' に等しい場合、TLS 接続の証明書検証が無効になります。これにより、TLS および HTTPS が安全でなくなります。この環境変数の使用は強く非推奨です。

NODE_USE_ENV_PROXY=1#

有効にすると、Node.js は起動時に HTTP_PROXY、HTTPS_PROXY、NO_PROXY 環境変数を解析し、指定されたプロキシ経由でリクエストをトンネリングします。

これは --use-env-proxy コマンドラインフラグを使用して有効にすることもできます。両方が設定されている場合、--use-env-proxy が優先されます。

NODE_USE_SYSTEM_CA=1#

Node.js は、--use-bundled-ca オプションおよび NODE_EXTRA_CA_CERTS 環境変数と共に、システムストアに存在する信頼された CA 証明書を使用します。

これは --use-system-ca コマンドラインフラグを使用して有効にすることもできます。両方が設定されている場合、--use-system-ca が優先されます。

NODE_V8_COVERAGE=dir#

設定すると、Node.js は V8 JavaScript コードカバレッジ と ソースマップデータを引数として提供されたディレクトリに出力し始めます（カバレッジ情報は coverage プレフィックスの付いたファイルに JSON として書き込まれます）。

NODE_V8_COVERAGE はサブプロセスに自動的に伝播するため、child_process.spawn() ファミリの関数を呼び出すアプリケーションの計測が容易になります。NODE_V8_COVERAGE は、伝播を防ぐために空文字列に設定することができます。

{
  "result": [
    {
      "scriptId": "67",
      "url": "internal/tty.js",
      "functions": []
    }
  ]
} copy

{
  "result": [
    {
      "scriptId": "68",
      "url": "file:///absolute/path/to/source.js",
      "functions": []
    }
  ],
  "source-map-cache": {
    "file:///absolute/path/to/source.js": {
      "url": "./path-to-map.json",
      "data": {
        "version": 3,
        "sources": [
          "file:///absolute/path/to/original.js"
        ],
        "names": [
          "Foo",
          "console",
          "info"
        ],
        "mappings": "MAAMA,IACJC,YAAaC",
        "sourceRoot": "./"
      },
      "lineLengths": [
        13,
        62,
        38,
        27
      ]
    }
  }
} copy

NO_COLOR=<any>#

NO_COLOR は NODE_DISABLE_COLORS のエイリアスです。環境変数の値は任意です。

OPENSSL_CONF=file#

起動時に OpenSSL 設定ファイルを読み込みます。他の用途の中でも、Node.js が ./configure --openssl-fips でビルドされている場合、FIPS 準拠の暗号化を有効にするために使用できます。

--openssl-config コマンドラインオプションが使用されている場合、環境変数は無視されます。

SSL_CERT_DIR=dir#

--use-openssl-ca が有効になっている場合、または macOS および Windows 以外のプラットフォームで --use-system-ca が有効になっている場合、これは OpenSSL の信頼された証明書を含むディレクトリを上書きして設定します。

子環境が明示的に設定されていない限り、この環境変数は任意の子プロセスに継承され、それらが OpenSSL を使用している場合、node と同じ CA を信頼する原因となる可能性があることに注意してください。

SSL_CERT_FILE=file#

--use-openssl-ca が有効になっている場合、または macOS および Windows 以外のプラットフォームで --use-system-ca が有効になっている場合、これは OpenSSL の信頼された証明書を含むファイルを上書きして設定します。

子環境が明示的に設定されていない限り、この環境変数は任意の子プロセスに継承され、それらが OpenSSL を使用している場合、node と同じ CA を信頼する原因となる可能性があることに注意してください。

TZ#

TZ 環境変数は、タイムゾーン設定を指定するために使用されます。

Node.js は 他の環境で TZ が処理されるさまざまな方法のすべてをサポートしているわけではありませんが、基本的なタイムゾーン ID（'Etc/UTC', 'Europe/Paris', 'America/New_York' など）はサポートしています。他のいくつかの略語やエイリアスをサポートするかもしれませんが、これらは強く非推奨であり、保証されていません。

$ TZ=Europe/Dublin node -pe "new Date().toString()"
Wed May 12 2021 20:30:48 GMT+0100 (Irish Standard Time) copy

UV_THREADPOOL_SIZE=size#

libuv のスレッドプールで使用されるスレッド数を size スレッドに設定します。

非同期システム API は可能な限り Node.js で使用されますが、存在しない場合は、libuv のスレッドプールが同期システム API に基づいて非同期ノード API を作成するために使用されます。スレッドプールを使用する Node.js API は次のとおりです。

• ファイルウォッチャー API および明示的に同期であるものを除く、すべての fs API
• crypto.pbkdf2(), crypto.scrypt(), crypto.randomBytes(), crypto.randomFill(), crypto.generateKeyPair() などの非同期暗号 API
• dns.lookup()
• 明示的に同期であるものを除く、すべての zlib API

libuv のスレッドプールは固定サイズであるため、何らかの理由でこれらの API のいずれかが長時間かかると、libuv のスレッドプールで実行される他の（一見無関係な）API のパフォーマンスが低下することを意味します。この問題を軽減するための潜在的な解決策の 1 つは、'UV_THREADPOOL_SIZE' 環境変数を 4（現在のデフォルト値）より大きい値に設定して、libuv のスレッドプールのサイズを増やすことです。ただし、プロセス内から process.env.UV_THREADPOOL_SIZE=size を使用してこれを設定しても、スレッドプールはユーザーコードが実行されるずっと前のランタイム初期化の一部として作成されているため、機能する保証はありません。詳細については、libuv スレッドプールのドキュメントを参照してください。

--abort-on-uncaught-exception#

--disallow-code-generation-from-strings#

--enable-etw-stack-walking#

--expose-gc#

--harmony-shadow-realm#

--interpreted-frames-native-stack#

--jitless#

--max-old-space-size=SIZE (MiB 単位)#

V8 の old メモリセクションの最大メモリサイズを設定します。メモリ消費が制限に近づくと、V8 は未使用のメモリを解放するためにガベージコレクションにより多くの時間を費やします。

2 GiB のメモリを持つマシンでは、他の用途のためにメモリを残し、スワッピングを避けるために、これを 1536 (1.5 GiB) に設定することを検討してください。

node --max-old-space-size=1536 index.js copy

--max-semi-space-size=SIZE (MiB 単位)#

V8 のスカベンジガベージコレクタの最大セミスペースサイズを MiB（メビバイト）単位で設定します。セミスペースの最大サイズを増やすと、より多くのメモリ消費を犠牲にして Node.js のスループットが向上する可能性があります。

V8 ヒープの若い世代のサイズはセミスペースのサイズの 3 倍（V8 の YoungGenerationSizeFromSemiSpaceSize を参照）であるため、セミスペースに 1 MiB を増やすと、3 つの個々のセミスペースのそれぞれに適用され、ヒープサイズが 3 MiB 増加します。スループットの向上はワークロードに依存します（#42511 を参照）。

デフォルト値はメモリ制限に依存します。例えば、メモリ制限が 512 MiB の 64 ビットシステムでは、セミスペースの最大サイズはデフォルトで 1 MiB です。メモリ制限が 2GiB までの場合、64 ビットシステムでのセミスペースのデフォルトの最大サイズは 16 MiB 未満になります。

アプリケーションに最適な設定を得るには、アプリケーションのベンチマークを実行する際に、さまざまな max-semi-space-size の値を試してみるべきです。

例えば、64 ビットシステムでのベンチマーク

for MiB in 16 32 64 128; do
    node --max-semi-space-size=$MiB index.js
done copy

--perf-basic-prof#

--perf-basic-prof-only-functions#

--perf-prof#

--perf-prof-unwinding-info#

--prof#

--security-revert#

--stack-trace-limit=limit#

エラーのスタックトレースで収集するスタックフレームの最大数。0に設定するとスタックトレースの収集が無効になります。デフォルト値は10です。

node --stack-trace-limit=12 -p -e "Error.stackTraceLimit" # prints 12 copy