プロセス | Node.js v21.7.2 ドキュメント

プロセス#

ソースコード: lib/process.js

process オブジェクトは、現在の Node.js プロセスの情報と制御を提供します。

import process from 'node:process';const process = require('node:process');

プロセスイベント#

process オブジェクトは、EventEmitter のインスタンスです。

イベント: `'beforeExit'`#

追加されたバージョン: v0.11.12

`'beforeExit'` イベントは、Node.js がイベントループを空にし、スケジュールする追加の作業がない場合に発生します。通常、Node.js プロセスはスケジュールされた作業がないと終了しますが、`'beforeExit'` イベントに登録されたリスナーは非同期呼び出しを行うことができ、それによって Node.js プロセスの継続を引き起こす可能性があります。

リスナーのコールバック関数は、process.exitCode の値を引数として呼び出されます。

`'beforeExit'` イベントは、process.exit() の呼び出しやキャッチされない例外など、明示的な終了を引き起こす条件に対しては発生しません。

`'beforeExit'` は、追加の作業をスケジュールする意図がない限り、`'exit'` イベントの代替として使用しないでください。

import process from 'node:process';

process.on('beforeExit', (code) => {
  console.log('Process beforeExit event with code: ', code);
});

process.on('exit', (code) => {
  console.log('Process exit event with code: ', code);
});

console.log('This message is displayed first.');

// Prints:
// This message is displayed first.
// Process beforeExit event with code: 0
// Process exit event with code: 0const process = require('node:process');

process.on('beforeExit', (code) => {
  console.log('Process beforeExit event with code: ', code);
});

process.on('exit', (code) => {
  console.log('Process exit event with code: ', code);
});

console.log('This message is displayed first.');

// Prints:
// This message is displayed first.
// Process beforeExit event with code: 0
// Process exit event with code: 0

イベント: `'disconnect'`#

追加されたバージョン: v0.7.7

Node.js プロセスが IPC チャネルを使用して生成された場合（子プロセスとクラスタのドキュメントを参照）、IPC チャネルが閉じられたときに `'disconnect'` イベントが発生します。

イベント: `'exit'`#

追加されたバージョン: v0.1.7

code <整数>

`'exit'` イベントは、次のいずれかの結果として Node.js プロセスが終了しようとしている場合に発生します。

process.exit() メソッドが明示的に呼び出された場合。
Node.js イベントループに実行する追加の作業がなくなった場合。

この時点でイベントループの終了を防ぐ方法はなく、すべての `'exit'` リスナーの実行が完了すると、Node.js プロセスは終了します。

リスナーのコールバック関数は、process.exitCode プロパティ、または process.exit() メソッドに渡された exitCode 引数によって指定された終了コードを使用して呼び出されます。

import process from 'node:process';

process.on('exit', (code) => {
  console.log(`About to exit with code: ${code}`);
});const process = require('node:process');

process.on('exit', (code) => {
  console.log(`About to exit with code: ${code}`);
});

リスナー関数は、同期操作のみを実行する必要があります。Node.js プロセスは、`'exit'` イベントリスナーを呼び出した直後に終了するため、イベントループにまだキューイングされている追加の作業は放棄されます。たとえば、次の例では、タイムアウトは発生しません。

import process from 'node:process';

process.on('exit', (code) => {
  setTimeout(() => {
    console.log('This will not run');
  }, 0);
});const process = require('node:process');

process.on('exit', (code) => {
  setTimeout(() => {
    console.log('This will not run');
  }, 0);
});

イベント: `'message'`#

追加されたバージョン: v0.5.10

message <オブジェクト> | <ブール値> | <数値> | <文字列> | <null> 解析された JSON オブジェクトまたはシリアライズ可能なプリミティブ値。
sendHandle <net.Server> | <net.Socket> net.Server または net.Socket オブジェクト、または undefined。

Node.js プロセスが IPC チャネルを使用して生成された場合（子プロセスとクラスタのドキュメントを参照）、childprocess.send() を使用して親プロセスによって送信されたメッセージが子プロセスによって受信されるたびに、`'message'` イベントが発生します。

メッセージはシリアライズとパースを経ます。結果として得られるメッセージは、最初に送信されたものとは異なる場合があります。

プロセスの生成時に `serialization` オプションが `advanced` に設定されていた場合、`message` 引数には JSON が表現できないデータが含まれる可能性があります。詳細については、child_process の高度なシリアライゼーションを参照してください。

イベント: `'multipleResolves'`#

追加されたバージョン: v10.12.0非推奨バージョン: v17.6.0, v16.15.0

安定性: 0 - 非推奨

type <文字列> 解決タイプ。'resolve' または 'reject' のいずれか。
promise <Promise> 複数回解決または拒否された Promise。
value <任意> 元の解決後に Promise が解決または拒否された値。

`'multipleResolves'` イベントは、Promise が次のいずれかの場合に発生します。

複数回解決された場合。
複数回拒否された場合。
解決後に拒否された場合。
拒否後に解決された場合。

This is useful for tracking potential errors in an application while using the Promise constructor, as multiple resolutions are silently swallowed. However, the occurrence of this event does not necessarily indicate an error. For example, Promise.race() can trigger a 'multipleResolves' event.

Because of the unreliability of the event in cases like the Promise.race() example above it has been deprecated.

import process from 'node:process';

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason);
  setImmediate(() => process.exit(1));
});

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call');
      resolve('Swallowed resolve');
      reject(new Error('Swallowed reject'));
    });
  } catch {
    throw new Error('Failed');
  }
}

main().then(console.log);
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First callconst process = require('node:process');

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason);
  setImmediate(() => process.exit(1));
});

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call');
      resolve('Swallowed resolve');
      reject(new Error('Swallowed reject'));
    });
  } catch {
    throw new Error('Failed');
  }
}

main().then(console.log);
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First call

Event: `'rejectionHandled'`#

Added in: v1.4.1

promise <Promise> The late handled promise.

The 'rejectionHandled' event is emitted whenever a Promise has been rejected and an error handler was attached to it (using promise.catch(), for example) later than one turn of the Node.js event loop.

The Promise object would have previously been emitted in an 'unhandledRejection' event, but during the course of processing gained a rejection handler.

There is no notion of a top level for a Promise chain at which rejections can always be handled. Being inherently asynchronous in nature, a Promise rejection can be handled at a future point in time, possibly much later than the event loop turn it takes for the 'unhandledRejection' event to be emitted.

Another way of stating this is that, unlike in synchronous code where there is an ever-growing list of unhandled exceptions, with Promises there can be a growing-and-shrinking list of unhandled rejections.

In synchronous code, the 'uncaughtException' event is emitted when the list of unhandled exceptions grows.

In asynchronous code, the 'unhandledRejection' event is emitted when the list of unhandled rejections grows, and the 'rejectionHandled' event is emitted when the list of unhandled rejections shrinks.

import process from 'node:process';

const unhandledRejections = new Map();
process.on('unhandledRejection', (reason, promise) => {
  unhandledRejections.set(promise, reason);
});
process.on('rejectionHandled', (promise) => {
  unhandledRejections.delete(promise);
});const process = require('node:process');

const unhandledRejections = new Map();
process.on('unhandledRejection', (reason, promise) => {
  unhandledRejections.set(promise, reason);
});
process.on('rejectionHandled', (promise) => {
  unhandledRejections.delete(promise);
});

In this example, the unhandledRejections Map will grow and shrink over time, reflecting rejections that start unhandled and then become handled. It is possible to record such errors in an error log, either periodically (which is likely best for long-running application) or upon process exit (which is likely most convenient for scripts).

Event: `'uncaughtException'`#

History

Version	Changes
v12.0.0, v10.17.0	Added the `origin` argument.
v0.1.18	Added in: v0.1.18

err <Error> The uncaught exception.
origin <string> Indicates if the exception originates from an unhandled rejection or from a synchronous error. Can either be 'uncaughtException' or 'unhandledRejection'. The latter is used when an exception happens in a Promise based async context (or if a Promise is rejected) and --unhandled-rejections flag set to strict or throw (which is the default) and the rejection is not handled, or when a rejection happens during the command line entry point's ES module static loading phase.

The 'uncaughtException' event is emitted when an uncaught JavaScript exception bubbles all the way back to the event loop. By default, Node.js handles such exceptions by printing the stack trace to stderr and exiting with code 1, overriding any previously set process.exitCode. Adding a handler for the 'uncaughtException' event overrides this default behavior. Alternatively, change the process.exitCode in the 'uncaughtException' handler which will result in the process exiting with the provided exit code. Otherwise, in the presence of such handler the process will exit with 0.

import process from 'node:process';
import fs from 'node:fs';

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(
    process.stderr.fd,
    `Caught exception: ${err}\n` +
    `Exception origin: ${origin}\n`,
  );
});

setTimeout(() => {
  console.log('This will still run.');
}, 500);

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
console.log('This will not run.');const process = require('node:process');
const fs = require('node:fs');

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(
    process.stderr.fd,
    `Caught exception: ${err}\n` +
    `Exception origin: ${origin}\n`,
  );
});

setTimeout(() => {
  console.log('This will still run.');
}, 500);

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
console.log('This will not run.');

It is possible to monitor 'uncaughtException' events without overriding the default behavior to exit the process by installing a 'uncaughtExceptionMonitor' listener.

Warning: Using `'uncaughtException'` correctly#

'uncaughtException' is a crude mechanism for exception handling intended to be used only as a last resort. The event should not be used as an equivalent to On Error Resume Next. Unhandled exceptions inherently mean that an application is in an undefined state. Attempting to resume application code without properly recovering from the exception can cause additional unforeseen and unpredictable issues.

Exceptions thrown from within the event handler will not be caught. Instead the process will exit with a non-zero exit code and the stack trace will be printed. This is to avoid infinite recursion.

Attempting to resume normally after an uncaught exception can be similar to pulling out the power cord when upgrading a computer. Nine out of ten times, nothing happens. But the tenth time, the system becomes corrupted.

The correct use of 'uncaughtException' is to perform synchronous cleanup of allocated resources (e.g. file descriptors, handles, etc) before shutting down the process. It is not safe to resume normal operation after 'uncaughtException'.

To restart a crashed application in a more reliable way, whether 'uncaughtException' is emitted or not, an external monitor should be employed in a separate process to detect application failures and recover or restart as needed.

Event: `'uncaughtExceptionMonitor'`#

Added in: v13.7.0, v12.17.0

err <Error> The uncaught exception.
origin <string> Indicates if the exception originates from an unhandled rejection or from synchronous errors. Can either be 'uncaughtException' or 'unhandledRejection'. The latter is used when an exception happens in a Promise based async context (or if a Promise is rejected) and --unhandled-rejections flag set to strict or throw (which is the default) and the rejection is not handled, or when a rejection happens during the command line entry point's ES module static loading phase.

The 'uncaughtExceptionMonitor' event is emitted before an 'uncaughtException' event is emitted or a hook installed via process.setUncaughtExceptionCaptureCallback() is called.

Installing an 'uncaughtExceptionMonitor' listener does not change the behavior once an 'uncaughtException' event is emitted. The process will still crash if no 'uncaughtException' listener is installed.

import process from 'node:process';

process.on('uncaughtExceptionMonitor', (err, origin) => {
  MyMonitoringTool.logSync(err, origin);
});

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
// Still crashes Node.jsconst process = require('node:process');

process.on('uncaughtExceptionMonitor', (err, origin) => {
  MyMonitoringTool.logSync(err, origin);
});

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
// Still crashes Node.js

Event: `'unhandledRejection'`#

History

Version	Changes
v7.0.0	Not handling `Promise` rejections is deprecated.
v6.6.0	Unhandled `Promise` rejections will now emit a process warning.
v1.4.1	Added in: v1.4.1

reason <Error> | <any> The object with which the promise was rejected (typically an Error object).
promise <Promise> The rejected promise.

The 'unhandledRejection' event is emitted whenever a Promise is rejected and no error handler is attached to the promise within a turn of the event loop. When programming with Promises, exceptions are encapsulated as "rejected promises". Rejections can be caught and handled using promise.catch() and are propagated through a Promise chain. The 'unhandledRejection' event is useful for detecting and keeping track of promises that were rejected whose rejections have not yet been handled.

import process from 'node:process';

process.on('unhandledRejection', (reason, promise) => {
  console.log('Unhandled Rejection at:', promise, 'reason:', reason);
  // Application specific logging, throwing an error, or other logic here
});

somePromise.then((res) => {
  return reportToUser(JSON.pasre(res)); // Note the typo (`pasre`)
}); // No `.catch()` or `.then()`const process = require('node:process');

process.on('unhandledRejection', (reason, promise) => {
  console.log('Unhandled Rejection at:', promise, 'reason:', reason);
  // Application specific logging, throwing an error, or other logic here
});

somePromise.then((res) => {
  return reportToUser(JSON.pasre(res)); // Note the typo (`pasre`)
}); // No `.catch()` or `.then()`

The following will also trigger the 'unhandledRejection' event to be emitted

import process from 'node:process';

function SomeResource() {
  // Initially set the loaded status to a rejected promise
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'));
}

const resource = new SomeResource();
// no .catch or .then on resource.loaded for at least a turnconst process = require('node:process');

function SomeResource() {
  // Initially set the loaded status to a rejected promise
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'));
}

const resource = new SomeResource();
// no .catch or .then on resource.loaded for at least a turn

In this example case, it is possible to track the rejection as a developer error as would typically be the case for other 'unhandledRejection' events. To address such failures, a non-operational .catch(() => { }) handler may be attached to resource.loaded, which would prevent the 'unhandledRejection' event from being emitted.

Event: `'warning'`#

Added in: v6.0.0

warning <Error> Key properties of the warning are
- name <string> The name of the warning. Default: 'Warning'.
- message <string> A system-provided description of the warning.
- stack <string> A stack trace to the location in the code where the warning was issued.

The 'warning' event is emitted whenever Node.js emits a process warning.

A process warning is similar to an error in that it describes exceptional conditions that are being brought to the user's attention. However, warnings are not part of the normal Node.js and JavaScript error handling flow. Node.js can emit warnings whenever it detects bad coding practices that could lead to sub-optimal application performance, bugs, or security vulnerabilities.

import process from 'node:process';

process.on('warning', (warning) => {
  console.warn(warning.name);    // Print the warning name
  console.warn(warning.message); // Print the warning message
  console.warn(warning.stack);   // Print the stack trace
});const process = require('node:process');

process.on('warning', (warning) => {
  console.warn(warning.name);    // Print the warning name
  console.warn(warning.message); // Print the warning message
  console.warn(warning.stack);   // Print the stack trace
});

デフォルトでは、Node.js はプロセス警告を `stderr` に出力します。`--no-warnings` コマンドラインオプションを使用してデフォルトのコンソール出力を抑制できますが、`'warning'` イベントは `process` オブジェクトによって引き続き発行されます。現在、非推奨警告以外の特定の警告の種類を抑制することはできません。非推奨警告を抑制するには、`--no-deprecation` フラグを参照してください。

次の例は、イベントにリスナーが多すぎる場合に `stderr` に出力される警告を示しています。

$ node
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> (node:38638) MaxListenersExceededWarning: Possible EventEmitter memory leak
detected. 2 foo listeners added. Use emitter.setMaxListeners() to increase limit

これに対し、次の例ではデフォルトの警告出力をオフにし、`'warning'` イベントにカスタムハンドラーを追加します。

$ node --no-warnings
> const p = process.on('warning', (warning) => console.warn('Do not do that!'));
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> Do not do that!

`--trace-warnings` コマンドラインオプションを使用すると、警告のデフォルトのコンソール出力に警告の完全なスタックトレースを含めることができます。

`--throw-deprecation` コマンドラインフラグを使用して Node.js を起動すると、カスタム非推奨警告が例外としてスローされます。

`--trace-deprecation` コマンドラインフラグを使用すると、カスタム非推奨警告がスタックトレースと共に `stderr` に出力されます。

`--no-deprecation` コマンドラインフラグを使用すると、カスタム非推奨警告のすべての報告が抑制されます。

`*-deprecation` コマンドラインフラグは、`'DeprecationWarning'` という名前を使用する警告のみに影響します。

カスタム警告の発行#

カスタム警告またはアプリケーション固有の警告を発行するには、`process.emitWarning()` メソッドを参照してください。

Node.js 警告名#

Node.js によって発行される警告の種類（`name` プロパティで識別）には、厳格なガイドラインはありません。新しい種類の警告はいつでも追加される可能性があります。最も一般的な警告の種類をいくつか示します。

`'DeprecationWarning'` - 非推奨の Node.js API または機能の使用を示します。このような警告には、非推奨コードを識別する `'code'` プロパティを含める必要があります。
`'ExperimentalWarning'` - Node.js の実験的な API または機能の使用を示します。このような機能は、いつでも変更される可能性があり、サポートされている機能と同じ厳格なセマンティックバージョニングと長期サポートポリシーの対象ではないため、注意して使用する必要があります。
`'MaxListenersExceededWarning'` - 特定のイベントに対するリスナーが `EventEmitter` または `EventTarget` のいずれかに登録されすぎていることを示します。これは多くの場合、メモリリークを示しています。
`'TimeoutOverflowWarning'` - 32 ビット符号付き整数に収まらない数値が `setTimeout()` 関数または `setInterval()` 関数のいずれかに提供されたことを示します。
`'UnsupportedWarning'` - サポートされていないオプションまたは機能の使用を示します。これはエラーとして扱われるのではなく、無視されます。1 つの例として、HTTP/2 互換性 API を使用する場合の HTTP レスポンスステータスメッセージの使用があります。

イベント: `'worker'`#

追加されたバージョン: v16.2.0、v14.18.0

`worker` <Worker> 作成された<Worker>。

`'worker'` イベントは、新しい<Worker> スレッドが作成された後に発行されます。

シグナルイベント#

Node.js プロセスがシグナルを受信すると、シグナルイベントが発行されます。標準的な POSIX シグナル名（`'SIGINT'`、`'SIGHUP'` など）のリストについては、`signal(7)` を参照してください。

シグナルは、`Worker` スレッドでは使用できません。

シグナルハンドラーは、シグナル名（`'SIGINT'`、`'SIGTERM'` など）を最初の引数として受け取ります。

各イベントの名前は、シグナルの大文字の一般的な名前になります（例：`SIGINT` シグナルの場合は `'SIGINT'`）。

import process from 'node:process';

// Begin reading from stdin so the process does not exit.
process.stdin.resume();

process.on('SIGINT', () => {
  console.log('Received SIGINT. Press Control-D to exit.');
});

// Using a single function to handle multiple signals
function handle(signal) {
  console.log(`Received ${signal}`);
}

process.on('SIGINT', handle);
process.on('SIGTERM', handle);const process = require('node:process');

// Begin reading from stdin so the process does not exit.
process.stdin.resume();

process.on('SIGINT', () => {
  console.log('Received SIGINT. Press Control-D to exit.');
});

// Using a single function to handle multiple signals
function handle(signal) {
  console.log(`Received ${signal}`);
}

process.on('SIGINT', handle);
process.on('SIGTERM', handle);

`'SIGUSR1'` は、デバッガーを起動するために Node.js によって予約されています。リスナーをインストールすることは可能ですが、そうするとデバッガーの動作に干渉する可能性があります。
`'SIGTERM'` と `'SIGINT'` は、Windows 以外のプラットフォームでデフォルトのハンドラーがあり、コード `128 + シグナル番号` で終了する前にターミナルモードをリセットします。これらのシグナルのいずれかにリスナーがインストールされている場合、そのデフォルトの動作は削除されます（Node.js はもはや終了しません）。
`'SIGPIPE'` はデフォルトで無視されます。リスナーをインストールできます。
`'SIGHUP'` は、コンソールウィンドウが閉じられたときに Windows で生成され、他のプラットフォームではさまざまな同様の状況で生成されます。`signal(7)` を参照してください。リスナーをインストールできますが、Node.js は約 10 秒後に Windows によって無条件に終了されます。Windows 以外のプラットフォームでは、`SIGHUP` のデフォルトの動作は Node.js を終了することですが、リスナーがインストールされると、そのデフォルトの動作は削除されます。
`'SIGTERM'` は Windows ではサポートされていませんが、リスナーをインストールできます。
ターミナルからの `'SIGINT'` はすべてのプラットフォームでサポートされており、通常は Ctrl+C で生成できます（ただし、これは構成可能です）。ターミナルの raw モードが有効になっていて Ctrl+C が使用されている場合は生成されません。
`'SIGBREAK'` は、Ctrl+Break が押されたときに Windows で配信されます。Windows 以外のプラットフォームでは、リスナーをインストールできますが、送信または生成する方法はありません。
`'SIGWINCH'` は、コンソールがサイズ変更されたときに配信されます。Windows では、これはカーソルが移動されているとき、または raw モードで読み取り可能な tty が使用されている場合にのみ、コンソールへの書き込み時に発生します。
`'SIGKILL'` にはリスナーをインストールできません。すべてのプラットフォームで Node.js を無条件に終了します。
`'SIGSTOP'` にはリスナーをインストールできません。
`'SIGBUS'`、`'SIGFPE'`、`'SIGSEGV'`、`'SIGILL'` は、`kill(2)` を使用して人工的に発生させない場合、プロセスを JS リスナーを呼び出すのが安全ではない状態に残します。そうすると、プロセスが応答しなくなる可能性があります。
`0` を送信してプロセスの存在を確認できます。プロセスが存在する場合は影響しませんが、プロセスが存在しない場合はエラーをスローします。

Windows はシグナルをサポートしていないため、シグナルによる終了と同等のものはありませんが、Node.js は `process.kill()` と `subprocess.kill()` でいくつかのエミュレーションを提供しています。

`SIGINT`、`SIGTERM`、`SIGKILL` を送信すると、ターゲットプロセスが無条件に終了し、その後、サブプロセスはプロセスがシグナルによって終了したことを報告します。
シグナル `0` を送信すると、プロセスの存在を確認するためのプラットフォームに依存しない方法として使用できます。

`process.abort()`#

追加されたバージョン: v0.7.0

`process.abort()` メソッドは、Node.js プロセスをすぐに終了し、コアファイルを生成させます。

この機能は、`Worker` スレッドでは使用できません。

`process.allowedNodeEnvironmentFlags`#

追加されたバージョン: v10.10.0

<Set>

`process.allowedNodeEnvironmentFlags` プロパティは、`NODE_OPTIONS` 環境変数内で許可される特別な読み取り専用の `Set` のフラグです。

`process.allowedNodeEnvironmentFlags` は `Set` を拡張しますが、いくつかの異なるフラグ表現を認識するように `Set.prototype.has` をオーバーライドします。`process.allowedNodeEnvironmentFlags.has()` は、次の場合に `true` を返します。

フラグの先頭の単一ダッシュ（`-`）または二重ダッシュ（`--`）を省略できます。例：`--inspect-brk` の場合 `inspect-brk`、`-r` の場合 `r`。
V8 に渡されるフラグ（`--v8-options` にリストされている）では、先頭以外のダッシュをアンダースコアに置き換えることができます。またはその逆も可能です。例：`--perf_basic_prof`、`--perf-basic-prof`、`--perf_basic-prof` など。
フラグには、1 つ以上の等号（`=`）文字を含めることができます。最初の等号以降のすべての文字は無視されます。例：`--stack-trace-limit=100`。
フラグは、`NODE_OPTIONS` 内で許可されている必要があります。

`process.allowedNodeEnvironmentFlags` を反復処理するとき、フラグは一度だけ表示されます。それぞれは 1 つ以上のダッシュで始まります。V8 に渡されるフラグには、先頭以外のダッシュの代わりにアンダースコアが含まれます。

import { allowedNodeEnvironmentFlags } from 'node:process';

allowedNodeEnvironmentFlags.forEach((flag) => {
  // -r
  // --inspect-brk
  // --abort_on_uncaught_exception
  // ...
});const { allowedNodeEnvironmentFlags } = require('node:process');

allowedNodeEnvironmentFlags.forEach((flag) => {
  // -r
  // --inspect-brk
  // --abort_on_uncaught_exception
  // ...
});

`process.allowedNodeEnvironmentFlags` の `add()`、`clear()`、`delete()` メソッドは何も行わず、サイレントに失敗します。

`NODE_OPTIONS` サポートなしで Node.js がコンパイルされた場合（`process.config` に表示）、`process.allowedNodeEnvironmentFlags` には、許可されていたものが含まれます。

`process.arch`#

追加されたバージョン: v0.5.0

<string>

Node.js バイナリがコンパイルされたオペレーティングシステムの CPU アーキテクチャ。可能な値は、`'arm'`、`'arm64'`、`'ia32'`、`'loong64'`、`'mips'`、`'mipsel'`、`'ppc'`、`'ppc64'`、`'riscv64'`、`'s390'`、`'s390x'`、`'x64'` です。

import { arch } from 'node:process';

console.log(`This processor architecture is ${arch}`);const { arch } = require('node:process');

console.log(`This processor architecture is ${arch}`);

`process.argv`#

追加されたバージョン: v0.1.27

<string[]>

`process.argv` プロパティは、Node.js プロセスが起動されたときに渡されたコマンドライン引数を含む配列を返します。最初の要素は `process.execPath` になります。`argv[0]` の元の値にアクセスする必要がある場合は、`process.argv0` を参照してください。2 番目の要素は、実行される JavaScript ファイルへのパスになります。残りの要素は、追加のコマンドライン引数になります。

例えば、process-args.js のスクリプトが以下のようになっているとします。

import { argv } from 'node:process';

// print process.argv
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`);
});const { argv } = require('node:process');

// print process.argv
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`);
});

Node.js プロセスを以下のように起動すると

node process-args.js one two=three four

以下の出力が生成されます。

0: /usr/local/bin/node
1: /Users/mjr/work/node/process-args.js
2: one
3: two=three
4: four

`process.argv0`#

追加されたバージョン: v6.4.0

<string>

process.argv0 プロパティは、Node.js の起動時に渡された argv[0] の元の値の読み取り専用のコピーを格納します。

$ bash -c 'exec -a customArgv0 ./node'
> process.argv[0]
'/Volumes/code/external/node/out/Release/node'
> process.argv0
'customArgv0'

`process.channel`#

History

Version	Changes
v14.0.0	このオブジェクトは、ネイティブの C++ バインディングを誤って公開しなくなりました。
v7.1.0	追加されたバージョン: v7.1.0

<Object>

Node.js プロセスが IPC チャンネルを使用して生成された場合（子プロセスのドキュメントを参照）、process.channel プロパティは IPC チャンネルへの参照になります。IPC チャンネルが存在しない場合、このプロパティは undefined です。

`process.channel.ref()`#

追加されたバージョン: v7.1.0

このメソッドは、事前に .unref() が呼び出されていた場合でも、プロセスのイベントループを動作させ続けるために IPC チャンネルを使用します。

通常、これは process オブジェクトの 'disconnect' と 'message' リスナーの数によって管理されます。しかし、このメソッドを使用して、特定の動作を明示的に要求できます。

`process.channel.unref()`#

追加されたバージョン: v7.1.0

このメソッドは、IPC チャンネルがプロセスのイベントループを動作させなくなり、チャンネルが開いている間でも終了することを許可します。

`process.chdir(directory)`#

追加されたバージョン: v0.1.17

directory <string>

process.chdir() メソッドは、Node.js プロセスの現在の作業ディレクトリを変更するか、変更に失敗した場合（例えば、指定された directory が存在しない場合）、例外をスローします。

import { chdir, cwd } from 'node:process';

console.log(`Starting directory: ${cwd()}`);
try {
  chdir('/tmp');
  console.log(`New directory: ${cwd()}`);
} catch (err) {
  console.error(`chdir: ${err}`);
}const { chdir, cwd } = require('node:process');

console.log(`Starting directory: ${cwd()}`);
try {
  chdir('/tmp');
  console.log(`New directory: ${cwd()}`);
} catch (err) {
  console.error(`chdir: ${err}`);
}

この機能は、`Worker` スレッドでは使用できません。

`process.config`#

History

Version	Changes
v19.0.0	`process.config` オブジェクトは、 теперь заморожен。
v16.0.0	`process.config` の変更は非推奨となりました。
v0.7.7	追加されたバージョン: v0.7.7

<Object>

process.config プロパティは、現在の Node.js 実行可能ファイルのコンパイルに使用された構成オプションの JavaScript 表現を含む、凍結された Object を返します。これは、./configure スクリプトを実行したときに生成された config.gypi ファイルと同じです。

出力例は以下のようになります。

{
  target_defaults:
   { cflags: [],
     default_configuration: 'Release',
     defines: [],
     include_dirs: [],
     libraries: [] },
  variables:
   {
     host_arch: 'x64',
     napi_build_version: 5,
     node_install_npm: 'true',
     node_prefix: '',
     node_shared_cares: 'false',
     node_shared_http_parser: 'false',
     node_shared_libuv: 'false',
     node_shared_zlib: 'false',
     node_use_openssl: 'true',
     node_shared_openssl: 'false',
     strict_aliasing: 'true',
     target_arch: 'x64',
     v8_use_snapshot: 1
   }
}

`process.connected`#

追加されたバージョン: v0.7.2

<boolean>

Node.js プロセスが IPC チャンネルを使用して生成された場合（子プロセスとクラスタのドキュメントを参照）、process.connected プロパティは、IPC チャンネルが接続されている限り true を返し、process.disconnect() が呼び出された後は false を返します。

process.connected が false になると、process.send() を使用して IPC チャンネルを介してメッセージを送信することはできなくなります。

`process.constrainedMemory()`#

追加されたバージョン: v19.6.0, v18.15.0

安定性: 1 - 実験的

<number> | <undefined>

OSによって課せられた制限に基づいて、プロセスが使用できるメモリの量（バイト単位）を取得します。そのような制約がない場合、または制約が不明な場合は、undefined が返されます。

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

`process.cpuUsage([previousValue])`#

追加されたバージョン: v6.1.0

previousValue <Object> process.cpuUsage() を呼び出した際の以前の戻り値
戻り値: <Object>
- user <integer>
- system <integer>

process.cpuUsage() メソッドは、現在のプロセスのユーザーとシステムの CPU 使用時間を、user と system プロパティを持つオブジェクトで返します。これらの値はマイクロ秒単位（100万分の1秒）です。これらの値はそれぞれユーザーコードとシステムコードで費やされた時間を測定し、複数の CPU コアがこのプロセスの作業を実行している場合、実際の経過時間よりも大きくなる可能性があります。

process.cpuUsage() への以前の呼び出しの結果を引数として関数に渡して、差分を読み取ることができます。

import { cpuUsage } from 'node:process';

const startUsage = cpuUsage();
// { user: 38579, system: 6986 }

// spin the CPU for 500 milliseconds
const now = Date.now();
while (Date.now() - now < 500);

console.log(cpuUsage(startUsage));
// { user: 514883, system: 11226 }const { cpuUsage } = require('node:process');

const startUsage = cpuUsage();
// { user: 38579, system: 6986 }

// spin the CPU for 500 milliseconds
const now = Date.now();
while (Date.now() - now < 500);

console.log(cpuUsage(startUsage));
// { user: 514883, system: 11226 }

`process.cwd()`#

追加されたバージョン: v0.1.8

戻り値: <string>

process.cwd() メソッドは、Node.js プロセスの現在の作業ディレクトリを返します。

import { cwd } from 'node:process';

console.log(`Current directory: ${cwd()}`);const { cwd } = require('node:process');

console.log(`Current directory: ${cwd()}`);

`process.debugPort`#

追加されたバージョン: v0.7.2

<number>

有効になっている場合の Node.js デバッガーで使用されるポート。

import process from 'node:process';

process.debugPort = 5858;const process = require('node:process');

process.debugPort = 5858;

`process.disconnect()`#

追加されたバージョン: v0.7.2

Node.js プロセスが IPC チャンネルを使用して生成された場合（子プロセスとクラスタのドキュメントを参照）、process.disconnect() メソッドは親プロセスへの IPC チャンネルを閉じ、他の接続によって存続させられていない限り、子プロセスが正常に終了できるようにします。

process.disconnect() を呼び出す効果は、親プロセスから ChildProcess.disconnect() を呼び出すことと同じです。

Node.js プロセスが IPC チャンネルを使用して生成されなかった場合、process.disconnect() は undefined になります。

`process.dlopen(module, filename[, flags])`#

History

Version	Changes
v9.0.0	`flags` 引数のサポートを追加しました。
v0.1.16	追加されたバージョン: v0.1.16

module <Object>
filename <string>
flags <os.constants.dlopen> デフォルト: os.constants.dlopen.RTLD_LAZY

process.dlopen() メソッドを使用すると、共有オブジェクトを動的にロードできます。これは主に require() によって C++ アドオンをロードするために使用され、特別な場合を除いて直接使用しないでください。つまり、カスタム dlopen フラグや ES モジュールからのロードなどの特別な理由がない限り、require() の方が process.dlopen() よりも優先されます。

flags 引数は、dlopen の動作を指定するために使用する整数です。詳細については、os.constants.dlopen のドキュメントを参照してください。

process.dlopen() を呼び出す際の重要な要件は、module インスタンスを渡す必要があることです。C++ アドオンによってエクスポートされた関数は、その後 module.exports を介してアクセスできます。

以下の例は、foo 関数をエクスポートする local.node という名前の C++ アドオンをロードする方法を示しています。RTLD_NOW 定数を渡すことで、すべてのシンボルが呼び出しが戻る前にロードされます。この例では、定数は使用可能であると仮定しています。

import { dlopen } from 'node:process';
import { constants } from 'node:os';
import { fileURLToPath } from 'node:url';

const module = { exports: {} };
dlopen(module, fileURLToPath(new URL('local.node', import.meta.url)),
       constants.dlopen.RTLD_NOW);
module.exports.foo();const { dlopen } = require('node:process');
const { constants } = require('node:os');
const { join } = require('node:path');

const module = { exports: {} };
dlopen(module, join(__dirname, 'local.node'), constants.dlopen.RTLD_NOW);
module.exports.foo();

`process.emitWarning(warning[, options])`#

追加されたバージョン: v8.0.0

warning <string> | <Error> 発行する警告。
options <Object>
- type <string> warning が String の場合、type は発行される警告の種類に使用される名前です。デフォルト: 'Warning'。
- code <string> 発行される警告インスタンスの一意の識別子。
- ctor <Function> warning が String の場合、ctor は生成されたスタックトレースを制限するために使用されるオプションの関数です。デフォルト: process.emitWarning。
- detail <string> エラーに含める追加のテキスト。

process.emitWarning() メソッドは、カスタムまたはアプリケーション固有のプロセス警告を発行するために使用できます。'warning' イベントにハンドラーを追加することで、これらをリッスンできます。

import { emitWarning } from 'node:process';

// Emit a warning with a code and additional detail.
emitWarning('Something happened!', {
  code: 'MY_WARNING',
  detail: 'This is some additional information',
});
// Emits:
// (node:56338) [MY_WARNING] Warning: Something happened!
// This is some additional informationconst { emitWarning } = require('node:process');

// Emit a warning with a code and additional detail.
emitWarning('Something happened!', {
  code: 'MY_WARNING',
  detail: 'This is some additional information',
});
// Emits:
// (node:56338) [MY_WARNING] Warning: Something happened!
// This is some additional information

この例では、process.emitWarning() によって内部的に Error オブジェクトが生成され、'warning' ハンドラーに渡されます。

import process from 'node:process';

process.on('warning', (warning) => {
  console.warn(warning.name);    // 'Warning'
  console.warn(warning.message); // 'Something happened!'
  console.warn(warning.code);    // 'MY_WARNING'
  console.warn(warning.stack);   // Stack trace
  console.warn(warning.detail);  // 'This is some additional information'
});const process = require('node:process');

process.on('warning', (warning) => {
  console.warn(warning.name);    // 'Warning'
  console.warn(warning.message); // 'Something happened!'
  console.warn(warning.code);    // 'MY_WARNING'
  console.warn(warning.stack);   // Stack trace
  console.warn(warning.detail);  // 'This is some additional information'
});

warning が Error オブジェクトとして渡された場合、options 引数は無視されます。

`process.emitWarning(warning[, type[, code]][, ctor])`#

Added in: v6.0.0

warning <string> | <Error> 発行する警告。
type <string> warning が String の場合、type は発行される警告の種類に使用される名前です。デフォルト: 'Warning'。
code <string> 発行される警告インスタンスの一意の識別子。
ctor <Function> warning が String の場合、ctor は生成されたスタックトレースを制限するために使用されるオプションの関数です。デフォルト: process.emitWarning。

import { emitWarning } from 'node:process';

// Emit a warning using a string.
emitWarning('Something happened!');
// Emits: (node: 56338) Warning: Something happened!const { emitWarning } = require('node:process');

// Emit a warning using a string.
emitWarning('Something happened!');
// Emits: (node: 56338) Warning: Something happened!

import { emitWarning } from 'node:process';

// Emit a warning using a string and a type.
emitWarning('Something Happened!', 'CustomWarning');
// Emits: (node:56338) CustomWarning: Something Happened!const { emitWarning } = require('node:process');

// Emit a warning using a string and a type.
emitWarning('Something Happened!', 'CustomWarning');
// Emits: (node:56338) CustomWarning: Something Happened!

import { emitWarning } from 'node:process';

emitWarning('Something happened!', 'CustomWarning', 'WARN001');
// Emits: (node:56338) [WARN001] CustomWarning: Something happened!const { emitWarning } = require('node:process');

process.emitWarning('Something happened!', 'CustomWarning', 'WARN001');
// Emits: (node:56338) [WARN001] CustomWarning: Something happened!

前の各例では、process.emitWarning() によって内部的に Error オブジェクトが生成され、'warning' ハンドラーに渡されます。

import process from 'node:process';

process.on('warning', (warning) => {
  console.warn(warning.name);
  console.warn(warning.message);
  console.warn(warning.code);
  console.warn(warning.stack);
});const process = require('node:process');

process.on('warning', (warning) => {
  console.warn(warning.name);
  console.warn(warning.message);
  console.warn(warning.code);
  console.warn(warning.stack);
});

warning が Error オブジェクトとして渡された場合、変更されずに 'warning' イベントハンドラーに渡されます（オプションの type、code、ctor 引数は無視されます）。

import { emitWarning } from 'node:process';

// Emit a warning using an Error object.
const myWarning = new Error('Something happened!');
// Use the Error name property to specify the type name
myWarning.name = 'CustomWarning';
myWarning.code = 'WARN001';

emitWarning(myWarning);
// Emits: (node:56338) [WARN001] CustomWarning: Something happened!const { emitWarning } = require('node:process');

// Emit a warning using an Error object.
const myWarning = new Error('Something happened!');
// Use the Error name property to specify the type name
myWarning.name = 'CustomWarning';
myWarning.code = 'WARN001';

emitWarning(myWarning);
// Emits: (node:56338) [WARN001] CustomWarning: Something happened!

warning が文字列または Error オブジェクト以外の場合は、TypeError がスローされます。

プロセス警告は Error オブジェクトを使用しますが、プロセス警告メカニズムは、通常のエラー処理メカニズムの代替ではありません。

警告の type が 'DeprecationWarning' の場合、以下の追加処理が実行されます。

--throw-deprecation コマンドラインフラグを使用すると、非推奨警告はイベントとして発行されるのではなく、例外としてスローされます。
--no-deprecation コマンドラインフラグを使用すると、非推奨警告は抑制されます。
--trace-deprecation コマンドラインフラグを使用すると、非推奨警告は完全なスタックトレースと共に stderr に出力されます。

重複する警告の回避#

ベストプラクティスとして、警告はプロセスごとに一度だけ発行する必要があります。そのためには、emitWarning() をブール値の後ろに配置します。

import { emitWarning } from 'node:process';

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true;
    emitWarning('Only warn once!');
  }
}
emitMyWarning();
// Emits: (node: 56339) Warning: Only warn once!
emitMyWarning();
// Emits nothingconst { emitWarning } = require('node:process');

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true;
    emitWarning('Only warn once!');
  }
}
emitMyWarning();
// Emits: (node: 56339) Warning: Only warn once!
emitMyWarning();
// Emits nothing

`process.env`#

History

Version	Changes
v11.14.0	ワーカースレッドは、デフォルトで親スレッドの `process.env` のコピーを使用するようになります。`Worker` コンストラクターの `env` オプションで構成できます。
v10.0.0	変数値を文字列に暗黙的に変換することは非推奨となりました。
v0.1.27	追加されたバージョン: v0.1.27

<Object>

process.env プロパティは、ユーザー環境を含むオブジェクトを返します。 environ(7) を参照してください。

このオブジェクトの例を以下に示します。

{
  TERM: 'xterm-256color',
  SHELL: '/usr/local/bin/bash',
  USER: 'maciej',
  PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
  PWD: '/Users/maciej',
  EDITOR: 'vim',
  SHLVL: '1',
  HOME: '/Users/maciej',
  LOGNAME: 'maciej',
  _: '/usr/local/bin/node'
}

このオブジェクトを変更することはできますが、そのような変更はNode.jsプロセス外、または（明示的に要求されない限り）他のWorker スレッドには反映されません。つまり、次の例は機能しません。

node -e 'process.env.foo = "bar"' && echo $foo

一方、以下は機能します。

import { env } from 'node:process';

env.foo = 'bar';
console.log(env.foo);const { env } = require('node:process');

env.foo = 'bar';
console.log(env.foo);

process.env にプロパティを代入すると、値は暗黙的に文字列に変換されます。**この動作は非推奨です。**将来のバージョンのNode.jsでは、値が文字列、数値、またはブール値でない場合にエラーがスローされる可能性があります。

import { env } from 'node:process';

env.test = null;
console.log(env.test);
// => 'null'
env.test = undefined;
console.log(env.test);
// => 'undefined'const { env } = require('node:process');

env.test = null;
console.log(env.test);
// => 'null'
env.test = undefined;
console.log(env.test);
// => 'undefined'

process.env からプロパティを削除するには、delete を使用します。

import { env } from 'node:process';

env.TEST = 1;
delete env.TEST;
console.log(env.TEST);
// => undefinedconst { env } = require('node:process');

env.TEST = 1;
delete env.TEST;
console.log(env.TEST);
// => undefined

Windowsオペレーティングシステムでは、環境変数は大文字と小文字が区別されません。

import { env } from 'node:process';

env.TEST = 1;
console.log(env.test);
// => 1const { env } = require('node:process');

env.TEST = 1;
console.log(env.test);
// => 1

Worker インスタンスの作成時に明示的に指定しない限り、各Worker スレッドには、親スレッドのprocess.envに基づいた、またはWorker コンストラクタのenvオプションとして指定されたprocess.envの独自の複製があります。process.env の変更はWorker スレッド間では表示されず、メインスレッドだけがオペレーティングシステムまたはネイティブアドオンに表示される変更を行うことができます。Windowsでは、Worker インスタンス上のprocess.envのコピーは、メインスレッドとは異なり、大文字と小文字が区別されます。

`process.execArgv`#

追加されたバージョン: v0.7.7

<string[]>

process.execArgv プロパティは、Node.jsプロセスが起動されたときに渡されたNode.js固有のコマンドラインオプションのセットを返します。process.argvプロパティによって返される配列にはこれらのオプションは表示されず、Node.js実行可能ファイル、スクリプト名、またはスクリプト名に続くオプションは含まれません。これらのオプションは、親と同じ実行環境で子プロセスを生成するために役立ちます。

node --harmony script.js --version

process.execArgvの結果

['--harmony']

そしてprocess.argv

['/usr/local/bin/node', 'script.js', '--version']

Worker コンストラクタを参照して、このプロパティを持つワーカースレッドの詳細な動作を確認してください。

`process.execPath`#

追加されたバージョン: v0.1.100

<string>

process.execPath プロパティは、Node.jsプロセスを開始した実行可能ファイルの絶対パス名を返します。シンボリックリンクがある場合は、解決されます。

'/usr/local/bin/node'

`process.exit([code])`#

History

Version	Changes
v20.0.0	数値型、または整数を表す文字列型のみを受け付けます。
v0.1.13	追加されたバージョン: v0.1.13

code <整数> | <文字列> | <null> | <undefined> 終了コード。文字列型の場合、整数文字列（例:'1'）のみが許可されます。**デフォルト:** 0。

process.exit() メソッドは、code の終了ステータスでプロセスを同期的に終了するようにNode.jsに指示します。code が省略された場合、終了ステータスは「成功」コード0、またはprocess.exitCodeが設定されている場合はその値を使用します。すべての'exit' イベントリスナーが呼び出されるまで、Node.jsは終了しません。

「失敗」コードで終了するには

import { exit } from 'node:process';

exit(1);const { exit } = require('node:process');

exit(1);

Node.jsを実行したシェルは、終了コードを1として認識するはずです。

process.exit() を呼び出すと、未完了の非同期操作（process.stdout と process.stderr へのI/O操作を含む）が残っていても、プロセスはできるだけ早く強制終了されます。

ほとんどの場合、process.exit() を明示的に呼び出す必要はありません。イベントループに保留中の作業がない場合、Node.jsプロセスは自動的に終了します。プロセスが正常に終了する際に使用する終了コードを指定するには、process.exitCode プロパティを設定します。

たとえば、次の例は、process.exit() メソッドの誤用を示しており、stdoutに出力されるデータが切り捨てられて失われる可能性があります。

import { exit } from 'node:process';

// This is an example of what *not* to do:
if (someConditionNotMet()) {
  printUsageToStdout();
  exit(1);
}const { exit } = require('node:process');

// This is an example of what *not* to do:
if (someConditionNotMet()) {
  printUsageToStdout();
  exit(1);
}

これが問題となる理由は、Node.jsでのprocess.stdoutへの書き込みが非同期であることがあり、Node.jsイベントループの複数のティックにわたって発生する可能性があるためです。しかし、process.exit()を呼び出すと、それらの追加のstdoutへの書き込みが実行される前にプロセスが強制終了されます。

process.exit() を直接呼び出すのではなく、process.exitCode を設定し、イベントループに追加の作業をスケジュールしないことで、プロセスが自然に終了できるようにする必要があります。

import process from 'node:process';

// How to properly set the exit code while letting
// the process exit gracefully.
if (someConditionNotMet()) {
  printUsageToStdout();
  process.exitCode = 1;
}const process = require('node:process');

// How to properly set the exit code while letting
// the process exit gracefully.
if (someConditionNotMet()) {
  printUsageToStdout();
  process.exitCode = 1;
}

エラー状態のためにNode.jsプロセスを終了する必要がある場合は、キャッチされないエラーをスローし、プロセスがそれに応じて終了できるようにすることが、process.exit()を呼び出すよりも安全です。

Worker スレッドでは、この関数は現在のプロセスではなく、現在のスレッドを停止します。

`process.exitCode`#

History

Version	Changes
v20.0.0	数値型、または整数を表す文字列型のみを受け付けます。
v0.11.8	追加されたバージョン: v0.11.8

<整数> | <文字列> | <null> | <undefined> 終了コード。文字列型の場合、整数文字列（例:'1'）のみが許可されます。**デフォルト:** undefined。

プロセスが正常に終了するか、コードを指定せずにprocess.exit() を介して終了した場合のプロセス終了コードとなる数値。

process.exit(code) にコードを指定すると、それ以前のprocess.exitCodeの設定は上書きされます。

`process.getActiveResourcesInfo()`#

追加されたバージョン: v17.3.0, v16.14.0

安定性: 1 - 実験的

戻り値: <文字列[]>

process.getActiveResourcesInfo() メソッドは、現在イベントループをアクティブに維持しているアクティブなリソースの種類を含む文字列の配列を返します。

import { getActiveResourcesInfo } from 'node:process';
import { setTimeout } from 'node:timers';

console.log('Before:', getActiveResourcesInfo());
setTimeout(() => {}, 1000);
console.log('After:', getActiveResourcesInfo());
// Prints:
//   Before: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   After: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]const { getActiveResourcesInfo } = require('node:process');
const { setTimeout } = require('node:timers');

console.log('Before:', getActiveResourcesInfo());
setTimeout(() => {}, 1000);
console.log('After:', getActiveResourcesInfo());
// Prints:
//   Before: [ 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   After: [ 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]