プロセス

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

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

ESM

import process from 'node:process'

CJS

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'イベントの代替として使用しないでください。

ESM

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: 0

CJS

const 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引数によって指定された終了コードを使用して呼び出されます。

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

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

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

イベント: 'message'

追加日時: v0.5.10

• message <Object> | <boolean> | <number> | <string> | <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 - 非推奨]

安定性: 0 安定性: 0 - 非推奨

• type <string> 解決の種類。'resolve'または'reject'のいずれか。
• promise <Promise> 複数回解決または拒否された Promise。
• value <any> 元の解決後に Promise が解決または拒否された値。

'multipleResolves'イベントは、Promiseが以下のいずれかの場合に発行されます。

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

これは、Promiseコンストラクタを使用する際にアプリケーションの潜在的なエラーを追跡するのに役立ちますが、このイベントの発生が必ずしもエラーを示すわけではありません。たとえば、Promise.race()は'multipleResolves'イベントをトリガーする可能性があります。

上記のPromise.race()の例のような場合におけるイベントの信頼性の低さのため、非推奨となりました。

ESM

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 call

CJS

const 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

イベント: 'rejectionHandled'

追加されたバージョン: v1.4.1

• promise <Promise> 後から処理された Promise。

'rejectionHandled' イベントは、Promise が拒否され、エラーハンドラが（例えば promise.catch() を使用して）Node.js イベントループの一巡後以降にアタッチされた場合に、いつでも発生します。

Promise オブジェクトは、以前に 'unhandledRejection' イベントで発生していましたが、処理中に拒否ハンドラを取得しました。

Promise チェーンの最上位レベルという概念はなく、そこで拒否を常に処理できます。本質的に非同期であるため、Promise の拒否は将来の時点で処理でき、'unhandledRejection' イベントが発生するイベントループの巡回後、かなり後の可能性があります。

言い換えると、同期コードでは未処理の例外のリストが常に増えるのに対し、Promise では未処理の拒否のリストが増減する可能性があるということです。

同期コードでは、'uncaughtException' イベントは、未処理の例外のリストが増加したときに発生します。

非同期コードでは、'unhandledRejection' イベントは、未処理の拒否のリストが増加したときに発生し、'rejectionHandled' イベントは、未処理の拒否のリストが減少したときに発生します。

ESM

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)
})

CJS

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)
})

この例では、unhandledRejections Map は時間の経過とともに増減し、最初に未処理で、後に処理されるようになった拒否を反映します。このようなエラーをエラーログに記録できます。定期的に（長期間実行されるアプリケーションには最適です）またはプロセスの終了時に（スクリプトには最も便利です）。

イベント: 'workerMessage'

追加バージョン: v22.5.0

• value <any> postMessageToThread()を使用して送信された値。
• source <number> 送信元ワーカスレッド ID、またはメインスレッドの場合は0。

'workerMessage'イベントは、相手方からpostMessageToThread()を使用して送信された着信メッセージごとに発生します。

イベント: 'uncaughtException'

[履歴]

バージョン	変更
v12.0.0, v10.17.0	origin引数を追加
v0.1.18	追加バージョン: v0.1.18

• err <Error> 未キャッチの例外。
• origin <string> 例外が未処理の拒否から発生したのか、同期エラーから発生したのかを示します。'uncaughtException'または'unhandledRejection'のいずれかになります。後者は、Promiseベースの非同期コンテキストで例外が発生した場合（またはPromiseが拒否された場合）、そして--unhandled-rejectionsフラグがstrictまたはthrowに設定されている場合（デフォルト）、拒否が処理されない場合、またはコマンドラインエントリポイントの ES モジュールの静的ロードフェーズ中に拒否が発生した場合に使用されます。

'uncaughtException'イベントは、未キャッチの JavaScript 例外がイベントループにまで到達したときに発生します。デフォルトでは、Node.js はスタックトレースをstderrに出力し、コード 1 で終了することでこのような例外を処理し、以前に設定されたprocess.exitCodeを上書きします。'uncaughtException'イベントのハンドラーを追加すると、このデフォルトの動作が上書きされます。あるいは、'uncaughtException'ハンドラー内でprocess.exitCodeを変更すると、指定された終了コードでプロセスが終了します。それ以外の場合は、そのようなハンドラーが存在する場合、プロセスは 0 で終了します。

ESM

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.')

CJS

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.')

'uncaughtExceptionMonitor'リスナーをインストールすることで、プロセスの終了を上書きすることなく'uncaughtException'イベントを監視できます。

Warning: 'uncaughtException'の正しい使用方法

'uncaughtException'は、例外処理のための粗雑なメカニズムであり、最後の手段としてのみ使用するように意図されています。このイベントは、On Error Resume Nextの同義語として使用すべきではありません。未処理の例外は、アプリケーションが未定義の状態にあることを本質的に意味します。例外から適切に回復することなくアプリケーションコードの実行を再開しようとすると、予期せぬ追加の問題が発生する可能性があります。

イベントハンドラ内でスローされた例外はキャッチされません。代わりに、プロセスはゼロ以外の終了コードで終了し、スタックトレースが出力されます。これは無限再帰を回避するためです。

未処理例外の後で通常どおり再開しようとすると、コンピュータのアップグレード中に電源コードを抜くようなものです。10 回中 9 回は何も起こりません。しかし、10 回目にシステムが破損する可能性があります。

'uncaughtException'の正しい使い方は、プロセスをシャットダウンする前に、割り当てられたリソース（ファイル記述子、ハンドルなど）の同期的なクリーンアップを実行することです。'uncaughtException'の後で通常の動作を再開することは安全ではありません。

クラッシュしたアプリケーションをより信頼性の高い方法で再起動するには、'uncaughtException'が発行されたかどうかにかかわらず、別のプロセスで外部モニターを使用してアプリケーションの障害を検出し、必要に応じて回復または再起動する必要があります。

イベント: 'uncaughtExceptionMonitor'

追加されたバージョン: v13.7.0, v12.17.0

• err <Error> 未処理の例外。
• origin <string> 例外が未処理の拒否から発生したのか、同期エラーから発生したのかを示します。'uncaughtException'または'unhandledRejection'のいずれかになります。後者は、Promiseベースの非同期コンテキストで例外が発生した場合（またはPromiseが拒否された場合）、そして--unhandled-rejectionsフラグがstrictまたはthrowに設定されている場合（デフォルト）、拒否が処理されない場合、またはコマンドラインエントリポイントの ES モジュールの静的ロードフェーズ中に拒否が発生した場合に使用されます。

'uncaughtExceptionMonitor'イベントは、'uncaughtException'イベントが発行される前、またはprocess.setUncaughtExceptionCaptureCallback()を介してフックがインストールされる前に発行されます。

'uncaughtExceptionMonitor'リスナーをインストールしても、'uncaughtException'イベントが発行された後の動作は変わりません。'uncaughtException'リスナーがインストールされていない場合、プロセスは依然としてクラッシュします。

ESM

import process from 'node:process'

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

// 意図的に例外を引き起こしますが、キャッチしません。
nonexistentFunc()
// Node.js は依然としてクラッシュします

CJS

const process = require('node:process')

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

// 意図的に例外を引き起こしますが、キャッチしません。
nonexistentFunc()
// Node.js は依然としてクラッシュします

イベント: 'unhandledRejection'

[履歴]

バージョン	変更
v7.0.0	Promise の拒否を処理しないことは非推奨になりました。
v6.6.0	未処理の Promise の拒否は、プロセス警告を発行するようになりました。
v1.4.1	追加: v1.4.1

• reason <Error> | <any> Promise が拒否されたオブジェクト（通常は Error オブジェクト）。
• promise <Promise> 拒否された Promise。

'unhandledRejection' イベントは、Promise が拒否され、イベントループの 1 ターン内でその Promise にエラーハンドラーがアタッチされていない場合にいつでも発生します。Promise を使用してプログラミングする場合、例外は「拒否された Promise」としてカプセル化されます。拒否は promise.catch() を使用してキャッチおよび処理でき、Promise チェーンを通じて伝播されます。'unhandledRejection' イベントは、拒否がまだ処理されていない拒否された Promise を検出して追跡するために役立ちます。

ESM

import process from 'node:process'

process.on('unhandledRejection', (reason, promise) => {
  console.log('Unhandled Rejection at:', promise, 'reason:', reason)
  // アプリケーション固有のロギング、エラーの送出、その他のロジックをここに記述
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // タイプミスに注意 (`pasre`)
}) // `.catch()` または `.then()` なし

CJS

const process = require('node:process')

process.on('unhandledRejection', (reason, promise) => {
  console.log('Unhandled Rejection at:', promise, 'reason:', reason)
  // アプリケーション固有のロギング、エラーの送出、その他のロジックをここに記述
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // タイプミスに注意 (`pasre`)
}) // `.catch()` または `.then()` なし

次の場合も、'unhandledRejection' イベントが発生します。

ESM

import process from 'node:process'

function SomeResource() {
  // 初期状態では、読み込み済みステータスを拒否された Promise に設定します
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'))
}

const resource = new SomeResource()
// 少なくとも1ターンは resource.loaded に .catch または .then がありません

CJS

const process = require('node:process')

function SomeResource() {
  // 初期状態では、読み込み済みステータスを拒否された Promise に設定します
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'))
}

const resource = new SomeResource()
// 少なくとも1ターンは resource.loaded に .catch または .then がありません

この例では、他の 'unhandledRejection' イベントの場合と同様に、開発者エラーとして拒否を追跡できます。このような障害に対処するために、非動作の .catch(() =\> { }) ハンドラーを resource.loaded にアタッチできます。これにより、'unhandledRejection' イベントの発生を防ぐことができます。

イベント: 'warning'

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

• warning <Error> 警告の主要なプロパティは以下のとおりです。
  • name <string> 警告の名前。デフォルト: 'Warning'。
  • message <string> システムが提供する警告の説明。
  • stack <string> 警告が発生したコード内の場所を示すスタックトレース。

'warning' イベントは、Node.js がプロセス警告を発行するたびに発生します。

プロセス警告は、ユーザーの注意を引く例外的な状況を記述するという点で、エラーに似ています。ただし、警告は通常の Node.js と JavaScript のエラー処理フローの一部ではありません。Node.js は、最適ではないアプリケーションのパフォーマンス、バグ、またはセキュリティの脆弱性につながる可能性のある悪いコーディングプラクティスを検出した場合に、警告を発行できます。

ESM

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // 警告の名前を出力
  console.warn(warning.message) // 警告メッセージを出力
  console.warn(warning.stack) // スタックトレースを出力
})

CJS

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // 警告の名前を出力
  console.warn(warning.message) // 警告メッセージを出力
  console.warn(warning.stack) // スタックトレースを出力
})

デフォルトでは、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' - setTimeout() 関数または setInterval() 関数に、32 ビット符号付き整数に収まらない数値が提供されたことを示します。
• 'TimeoutNegativeWarning' - setTimeout() 関数または setInterval() 関数に負の数が提供されたことを示します。
• 'TimeoutNaNWarning' - 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'）。

ESM

import process from 'node:process'

// プロセスが終了しないようにstdinからの読み取りを開始します。
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('SIGINTを受信しました。Control-Dを押して終了してください。')
})

// 複数のシグナルを処理するための単一関数を使用
function handle(signal) {
  console.log(`${signal}を受信しました`)
}

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

CJS

const process = require('node:process')

// プロセスが終了しないようにstdinからの読み取りを開始します。
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('SIGINTを受信しました。Control-Dを押して終了してください。')
})

// 複数のシグナルを処理するための単一関数を使用
function handle(signal) {
  console.log(`${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 に渡されるフラグは、先頭以外のダッシュの代わりにアンダースコアが含まれます。

ESM

import { allowedNodeEnvironmentFlags } from 'node:process'

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

CJS

const { allowedNodeEnvironmentFlags } = require('node:process')

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

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

Node.js がNODE_OPTIONSサポートなしでコンパイルされた場合（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'です。

ESM

import { arch } from 'node:process'

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

CJS

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の次のスクリプトを想定します。

ESM

import { argv } from 'node:process'

// process.argvを出力
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`)
})

CJS

const { argv } = require('node:process')

// 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

[履歴]

バージョン	変更内容
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オブジェクトの'disconnect'と'message'リスナーの数によって管理されます。ただし、このメソッドを使用して、特定の動作を明示的に要求できます。

process.chdir(directory)

追加: v0.1.17

• directory <string>

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

ESM

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}`)
}

CJS

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

[履歴]

バージョン	変更
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',
     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()

[履歴]

バージョン	変更
v22.0.0, v20.13.0	戻り値をuv_get_constrained_memoryと合わせました。
v19.6.0, v18.15.0	追加: v19.6.0, v18.15.0

[安定版: 1 - 試験的]

安定版: 1 安定性: 1 - 試験的

• <number>

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

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

process.availableMemory()

追加日時: v22.0.0, v20.13.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1 - 実験的

• <number>

プロセスで使用可能な空きメモリ量（バイト単位）を取得します。

詳細はuv_get_available_memoryを参照してください。

process.cpuUsage([previousValue])

追加日時: v6.1.0

• previousValue <Object> process.cpuUsage()の前回の戻り値
• 戻り値: <Object>
  • user <integer>
  • system <integer>

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

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

ESM

import { cpuUsage } from 'node:process'

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

// CPUを500ミリ秒間スピンさせる
const now = Date.now()
while (Date.now() - now < 500);

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

CJS

const { cpuUsage } = require('node:process')

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

// CPUを500ミリ秒間スピンさせる
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 プロセスの現在の作業ディレクトリを返します。

ESM

import { cwd } from 'node:process'

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

CJS

const { cwd } = require('node:process')

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

process.debugPort

追加日時: v0.7.2

• <number>

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

ESM

import process from 'node:process'

process.debugPort = 5858

CJS

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])

[履歴]

バージョン	変更
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 モジュールからのロードなど特別な理由がない限り、process.dlopen()よりもrequire()を優先する必要があります。

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

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

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

ESM

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()

CJS

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

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

ESM

import { emitWarning } from 'node:process'

// コードと追加の詳細情報を使用して警告を出力します。
emitWarning('Something happened!', {
  code: 'MY_WARNING',
  detail: 'This is some additional information',
})
// 出力:
// (node:56338) [MY_WARNING] Warning: Something happened!
// This is some additional information

CJS

const { emitWarning } = require('node:process')

// コードと追加の詳細情報を使用して警告を出力します。
emitWarning('Something happened!', {
  code: 'MY_WARNING',
  detail: 'This is some additional information',
})
// 出力:
// (node:56338) [MY_WARNING] Warning: Something happened!
// This is some additional information

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

ESM

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) // スタックトレース
  console.warn(warning.detail) // 'This is some additional information'
})

CJS

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) // スタックトレース
  console.warn(warning.detail) // 'This is some additional information'
})

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

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

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

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

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

ESM

import { emitWarning } from 'node:process'

// 文字列を使用して警告を発します。
emitWarning('Something happened!')
// 出力: (node: 56338) Warning: Something happened!

CJS

const { emitWarning } = require('node:process')

// 文字列を使用して警告を発します。
emitWarning('Something happened!')
// 出力: (node: 56338) Warning: Something happened!

ESM

import { emitWarning } from 'node:process'

// 文字列と種類を使用して警告を発します。
emitWarning('Something Happened!', 'CustomWarning')
// 出力: (node:56338) CustomWarning: Something Happened!

CJS

const { emitWarning } = require('node:process')

// 文字列と種類を使用して警告を発します。
emitWarning('Something Happened!', 'CustomWarning')
// 出力: (node:56338) CustomWarning: Something Happened!

ESM

import { emitWarning } from 'node:process'

emitWarning('Something happened!', 'CustomWarning', 'WARN001')
// 出力: (node:56338) [WARN001] CustomWarning: Something happened!

CJS

const { emitWarning } = require('node:process')

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

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

ESM

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)
})

CJS

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 引数は無視されます）。

ESM

import { emitWarning } from 'node:process'

// Error オブジェクトを使用して警告を発します。
const myWarning = new Error('Something happened!')
// Error の name プロパティを使用して種類名を指定します
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// 出力: (node:56338) [WARN001] CustomWarning: Something happened!

CJS

const { emitWarning } = require('node:process')

// Error オブジェクトを使用して警告を発します。
const myWarning = new Error('Something happened!')
// Error の name プロパティを使用して種類名を指定します
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// 出力: (node:56338) [WARN001] CustomWarning: Something happened!

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

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

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

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

重複警告の回避

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

ESM

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 nothing

CJS

const { 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

[履歴]

バージョン	変更
v11.14.0	Worker スレッドはデフォルトで親スレッドの process.env のコピーを使用するようになりました。Worker コンストラクターの env オプションで設定可能です。
v10.0.0	変数値の文字列への暗黙的な変換は非推奨となりました。
v0.1.27	追加：v0.1.27

• <オブジェクト>

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

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

ESM

import { env } from 'node:process'

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

CJS

const { env } = require('node:process')

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

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

ESM

import { env } from 'node:process'

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

CJS

const { env } = require('node:process')

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

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

ESM

import { env } from 'node:process'

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

CJS

const { env } = require('node:process')

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

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

ESM

import { env } from 'node:process'

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

CJS

const { 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 --icu-data-dir=./foo --require ./bar.js script.js --version

process.execArgv の結果は次のとおりです。

["--icu-data-dir=./foo", "--require", "./bar.js"]

そして 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])

[履歴]

バージョン	変更内容
v20.0.0	数値型、または整数を表す文字列型のみを受け付けます。
v0.1.13	追加日: v0.1.13

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

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

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

ESM

import { exit } from 'node:process'

exit(1)

CJS

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 に出力されるデータが切り捨てられ、失われる可能性があります。

ESM

import { exit } from 'node:process'

// これは*すべきではない*例です。
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

CJS

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

// これは*すべきではない*例です。
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

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

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

ESM

import process from 'node:process'

// プロセスが正常に終了するように終了コードを設定する方法。
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

CJS

const process = require('node:process')

// プロセスが正常に終了するように終了コードを設定する方法。
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

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

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

process.exitCode

[履歴]

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

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

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

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

process.features.cached_builtins

追加: v12.0.0

• <ブール値>

現在の Node.js ビルドがビルトインモジュールをキャッシュしている場合、trueとなるブール値。

process.features.debug

追加: v0.5.5

• <ブール値>

現在の Node.js ビルドがデバッグビルドの場合、trueとなるブール値。

process.features.inspector

追加: v11.10.0

• <ブール値>

現在の Node.js ビルドにインスペクターが含まれている場合、trueとなるブール値。

process.features.ipv6

追加: v0.5.3

非推奨: v23.4.0

[安定度: 0 - 非推奨]

安定度: 0 安定性: 0 - 非推奨。このプロパティは常に true であり、これに基づくチェックは冗長です。

• <ブール値>

現在の Node.js ビルドが IPv6 をサポートしている場合、trueとなるブール値。

すべての Node.js ビルドが IPv6 をサポートしているため、この値は常にtrueです。

process.features.require_module

追加日: v23.0.0

• <boolean>

require() を使用した ECMAScript モジュールの読み込みを現在の Node.js ビルドがサポートしている場合、true となるブール値。

process.features.tls

追加日: v0.5.3

• <boolean>

現在の Node.js ビルドが TLS をサポートしている場合、true となるブール値。

process.features.tls_alpn

追加日: v4.8.0

非推奨化日: v23.4.0

[安定性: 0 - 非推奨]

安定性: 0 安定性: 0 - 非推奨。代わりに process.features.tls を使用してください。

• <boolean>

現在の Node.js ビルドが TLS で ALPN をサポートしている場合、true となるブール値。

Node.js 11.0.0 以降のバージョンでは、OpenSSL 依存関係により ALPN サポートが無条件に含まれています。そのため、この値は process.features.tls と同じになります。

process.features.tls_ocsp

追加日: v0.11.13

非推奨化日: v23.4.0

[安定性: 0 - 非推奨]

安定性: 0 安定性: 0 - 非推奨。代わりに process.features.tls を使用してください。

• <boolean>

現在の Node.js ビルドが TLS で OCSP をサポートしている場合、true となるブール値。

Node.js 11.0.0 以降のバージョンでは、OpenSSL 依存関係により OCSP サポートが無条件に含まれています。そのため、この値は process.features.tls と同じになります。

process.features.tls_sni

追加日: v0.5.3

非推奨化日: v23.4.0

[安定性: 0 - 非推奨]

安定性: 0 安定性: 0 - 非推奨。代わりに process.features.tls を使用してください。

• <boolean>

現在の Node.js ビルドが TLS で SNI をサポートしている場合、true となるブール値。

Node.js 11.0.0 以降のバージョンでは、OpenSSL 依存関係により SNI サポートが無条件に含まれています。そのため、この値は process.features.tls と同じになります。

process.features.typescript

追加: v23.0.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1.1 - アクティブ開発中

• <boolean> | <string>

Node.js が --experimental-strip-types で実行されている場合は "strip"、--experimental-transform-types で実行されている場合は "transform"、それ以外の場合は false の値です。

process.features.uv

追加: v0.5.3

非推奨: v23.4.0

[安定版: 0 - 非推奨]

安定版: 0 安定性: 0 - 非推奨。このプロパティは常に true であり、これを基にしたチェックは冗長です。

• <boolean>

現在の Node.js ビルドが libuv のサポートを含む場合、true のブール値です。

libuv なしで Node.js をビルドすることは不可能であるため、この値は常に true です。

process.finalization.register(ref, callback)

追加: v22.5.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1.1 - アクティブ開発中

• ref <Object> | <Function> 追跡されているリソースへの参照。
• callback <Function> リソースがファイナライズされたときに呼び出されるコールバック関数。
  • ref <Object> | <Function> 追跡されているリソースへの参照。
  • event <string> ファイナライズをトリガーしたイベント。デフォルトは 'exit'。

この関数は、ref オブジェクトがガベージコレクションされなかった場合に、プロセスが exit イベントを発行したときに呼び出されるコールバックを登録します。exit イベントが発行される前に ref オブジェクトがガベージコレクションされた場合、コールバックはファイナライゼーションレジストリから削除され、プロセス終了時に呼び出されません。

コールバック内では、ref オブジェクトによって割り当てられたリソースを解放できます。beforeExit イベントに適用されるすべての制限は、callback 関数にも適用されることに注意してください。つまり、特別な状況下ではコールバックが呼び出されない可能性があります。

この関数の目的は、プロセス終了開始時にリソースを解放するのに役立つことですが、オブジェクトが使用されなくなった場合はガベージコレクションされることも許可します。

例: バッファを含むオブジェクトを登録できます。プロセス終了時にそのバッファが解放されるようにしたいのですが、プロセス終了前にオブジェクトがガベージコレクションされた場合、バッファを解放する必要はなくなります。そのため、この場合はコールバックをファイナライゼーションレジストリから削除するだけです。

CJS

const { finalization } = require('node:process')

// Please make sure that the function passed to finalization.register()
// does not create a closure around unnecessary objects.
function onFinalize(obj, event) {
  // You can do whatever you want with the object
  obj.dispose()
}

function setup() {
  // This object can be safely garbage collected,
  // and the resulting shutdown function will not be called.
  // There are no leaks.
  const myDisposableObject = {
    dispose() {
      // Free your resources synchronously
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

ESM

import { finalization } from 'node:process'

// Please make sure that the function passed to finalization.register()
// does not create a closure around unnecessary objects.
function onFinalize(obj, event) {
  // You can do whatever you want with the object
  obj.dispose()
}

function setup() {
  // This object can be safely garbage collected,
  // and the resulting shutdown function will not be called.
  // There are no leaks.
  const myDisposableObject = {
    dispose() {
      // Free your resources synchronously
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

上記のコードは、次の前提に基づいています。

• アロー関数は避ける
• 通常の関数はグローバルコンテキスト（ルート）内にあることが推奨される

通常の関数は obj が存在するコンテキストを参照する可能性があり、obj がガベージコレクションされなくなる可能性があります。

アロー関数は以前のコンテキストを保持します。たとえば、次のような場合です。

class Test {
  constructor() {
    finalization.register(this, ref => ref.dispose())

    // Even something like this is highly discouraged
    // finalization.register(this, () => this.dispose());
  }
  dispose() {}
}

このオブジェクトがガベージコレクションされることは非常にまれです（不可能ではありません）。しかし、ガベージコレクションされない場合、process.exit が呼び出されると dispose が呼び出されます。

すべての状況下でコールバックが呼び出されるとは保証されていないため、重要なリソースの破棄にこの機能に依存しないように注意してください。

process.finalization.registerBeforeExit(ref, callback)

追加日時: v22.5.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1.1 - 開発中

• ref <Object> | <Function> トラッキングされているリソースへの参照。
• callback <Function> リソースがファイナライズされたときに呼び出されるコールバック関数。
  • ref <Object> | <Function> トラッキングされているリソースへの参照。
  • event <string> ファイナライズをトリガーしたイベント。デフォルトは 'beforeExit'。

この関数はregisterとまったく同じ動作をします。ただし、refオブジェクトがガベージコレクションされなかった場合、beforeExitイベントがプロセスから発行されると、コールバックが呼び出されます。

beforeExitイベントに適用されるすべての制限は、callback関数にも適用されることに注意してください。つまり、特別な状況下ではコールバックが呼び出されない可能性があります。

process.finalization.unregister(ref)

追加日時: v22.5.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1.1 - 開発中

• ref <Object> | <Function> 以前登録されたリソースへの参照。

この関数は、ファイナライゼーションレジストリからオブジェクトの登録を削除するため、コールバックはそれ以上呼び出されません。

CJS

const { finalization } = require('node:process')

// Please make sure that the function passed to finalization.register()
// does not create a closure around unnecessary objects.
function onFinalize(obj, event) {
  // オブジェクトに対して何でも実行できます
  obj.dispose()
}

function setup() {
  // このオブジェクトは安全にガベージコレクションできます。
  // その結果、シャットダウン関数は呼び出されません。
  // リークはありません。
  const myDisposableObject = {
    dispose() {
      // リソースを同期的に解放します
    },
  }

  finalization.register(myDisposableObject, onFinalize)

  // 何らかの処理を実行

  myDisposableObject.dispose()
  finalization.unregister(myDisposableObject)
}

setup()

ESM

import { finalization } from 'node:process'

// Please make sure that the function passed to finalization.register()
// does not create a closure around unnecessary objects.
function onFinalize(obj, event) {
  // オブジェクトに対して何でも実行できます
  obj.dispose()
}

function setup() {
  // このオブジェクトは安全にガベージコレクションできます。
  // その結果、シャットダウン関数は呼び出されません。
  // リークはありません。
  const myDisposableObject = {
    dispose() {
      // リソースを同期的に解放します
    },
  }

  // Please make sure that the function passed to finalization.register()
  // does not create a closure around unnecessary objects.
  function onFinalize(obj, event) {
    // オブジェクトに対して何でも実行できます
    obj.dispose()
  }

  finalization.register(myDisposableObject, onFinalize)

  // 何らかの処理を実行

  myDisposableObject.dispose()
  finalization.unregister(myDisposableObject)
}

setup()

process.getActiveResourcesInfo()

追加日時: v17.3.0, v16.14.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1 - 実験的

• 戻り値: <string[]>

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

ESM

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

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

CJS

const { getActiveResourcesInfo } = require('node:process')
const { setTimeout } = require('node:timers')

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

process.getBuiltinModule(id)

追加日時: v22.3.0, v20.16.0

• id <string> 要求された組み込みモジュールの ID。
• 戻り値: <Object> | <undefined>

process.getBuiltinModule(id)は、グローバルに利用可能な関数で組み込みモジュールをロードする方法を提供します。他の環境をサポートする必要がある ES モジュールは、Node.js 以外の環境で実行される場合に、importによって発生する可能性のある解決エラーに対処したり、同期 API を非同期にする動的なimport()を使用したりすることなく、Node.js 組み込みを条件付きでロードするためにこれを使用できます。

if (globalThis.process?.getBuiltinModule) {
  // Node.jsで実行する場合、Node.jsのfsモジュールを使用します。
  const fs = globalThis.process.getBuiltinModule('fs')
  // `require()`でユーザーモジュールをロードする必要がある場合は、createRequire()を使用します。
  const module = globalThis.process.getBuiltinModule('module')
  const require = module.createRequire(import.meta.url)
  const foo = require('foo')
}

idが現在の Node.js プロセスで使用可能な組み込みモジュールを指定する場合、process.getBuiltinModule(id)メソッドは対応する組み込みモジュールを返します。idがどの組み込みモジュールにも対応しない場合、undefinedが返されます。

process.getBuiltinModule(id)は、module.isBuiltin(id)によって認識される組み込みモジュールの ID を受け入れます。一部の組み込みモジュールはnode:プレフィックスを使用してロードする必要があります。必須のnode:プレフィックスを持つ組み込みモジュールを参照してください。process.getBuiltinModule(id)によって返される参照は、ユーザーがrequire.cacheを変更してrequire(id)が別のものを返す場合でも、常にidに対応する組み込みモジュールを指します。

process.getegid()

追加日時: v2.0.0

process.getegid()メソッドは、Node.js プロセスの有効グループ ID の数字を返します。（getegid(2)を参照）

ESM

import process from 'node:process'

if (process.getegid) {
  console.log(`Current gid: ${process.getegid()}`)
}

CJS

const process = require('node:process')

if (process.getegid) {
  console.log(`Current gid: ${process.getegid()}`)
}

この関数は POSIX プラットフォームでのみ利用可能です（つまり、Windows や Android では利用できません）。

process.geteuid()

追加日時: v2.0.0

• 戻り値: <Object>

process.geteuid()メソッドは、プロセスの有効ユーザー ID の数字を返します。（geteuid(2)を参照）

ESM

import process from 'node:process'

if (process.geteuid) {
  console.log(`Current uid: ${process.geteuid()}`)
}

CJS

const process = require('node:process')

if (process.geteuid) {
  console.log(`Current uid: ${process.geteuid()}`)
}

この関数は POSIX プラットフォームでのみ利用可能です（つまり、Windows や Android では利用できません）。

process.getgid()

追加日時: v0.1.31

• 戻り値: <Object>

process.getgid()メソッドは、プロセスのグループ ID の数字を返します。（getgid(2)を参照）

ESM

import process from 'node:process'

if (process.getgid) {
  console.log(`Current gid: ${process.getgid()}`)
}

CJS

const process = require('node:process')

if (process.getgid) {
  console.log(`Current gid: ${process.getgid()}`)
}

この関数は POSIX プラットフォームでのみ利用可能です（つまり、Windows や Android では利用できません）。

process.getgroups()

追加日時: v0.9.4

• 戻り値: <integer[]>

process.getgroups()メソッドは、補助グループ ID を含む配列を返します。POSIX では、有効グループ ID が含まれるかどうかは指定されていませんが、Node.js では常に含まれるようにしています。

ESM

import process from 'node:process'

if (process.getgroups) {
  console.log(process.getgroups()) // [ 16, 21, 297 ]
}

CJS

const process = require('node:process')

if (process.getgroups) {
  console.log(process.getgroups()) // [ 16, 21, 297 ]
}

この関数は POSIX プラットフォームでのみ利用可能です（つまり、Windows や Android では利用できません）。

process.getuid()

追加日時: v0.1.28

• 戻り値: <integer>

process.getuid()メソッドは、プロセスの数値ユーザー ID を返します。（getuid(2)を参照）

ESM

import process from 'node:process'

if (process.getuid) {
  console.log(`Current uid: ${process.getuid()}`)
}

CJS

const process = require('node:process')

if (process.getuid) {
  console.log(`Current uid: ${process.getuid()}`)
}

この関数は、POSIX プラットフォーム（つまり、Windows や Android ではない）でのみ使用できます。

process.hasUncaughtExceptionCaptureCallback()

追加日時: v9.3.0

• 戻り値: <boolean>

process.setUncaughtExceptionCaptureCallback()を使用してコールバックが設定されているかどうかを示します。

process.hrtime([time])

追加日時: v0.7.6

[Stable: 3 - Legacy]

Stable: 3 Stability: 3 - レガシー。process.hrtime.bigint() を代わりに使用してください。

• time <integer[]> process.hrtime()への以前の呼び出しの結果
• 戻り値: <integer[]>

これは、JavaScript にbigintが導入される前のprocess.hrtime.bigint()のレガシーバージョンです。

process.hrtime()メソッドは、[秒、ナノ秒]タプルArrayで表される現在の高解像度リアルタイムを返します。ここで、ナノ秒は、秒の精度では表現できないリアルタイムの残りの部分です。

timeは、現在の時刻との差を計算するために、以前のprocess.hrtime()呼び出しの結果でなければならないオプションパラメーターです。渡されたパラメーターがタプルArrayでない場合、TypeErrorがスローされます。以前のprocess.hrtime()呼び出しの結果ではなく、ユーザー定義の配列を渡すと、動作が未定義になります。

これらの時間は、過去の任意の時刻を基準とした相対的な時間で、時刻とは無関係であるため、クロックドリフトの影響を受けません。主な用途は、間隔間の性能測定です。

ESM

import { hrtime } from 'node:process'

const NS_PER_SEC = 1e9
const time = hrtime()
// [ 1800216, 25 ]

setTimeout(() => {
  const diff = hrtime(time)
  // [ 1, 552 ]

  console.log(`Benchmark took ${diff[0] * NS_PER_SEC + diff[1]} nanoseconds`)
  // Benchmark took 1000000552 nanoseconds
}, 1000)

CJS

const { hrtime } = require('node:process')

const NS_PER_SEC = 1e9
const time = hrtime()
// [ 1800216, 25 ]

setTimeout(() => {
  const diff = hrtime(time)
  // [ 1, 552 ]

  console.log(`Benchmark took ${diff[0] * NS_PER_SEC + diff[1]} nanoseconds`)
  // Benchmark took 1000000552 nanoseconds
}, 1000)

process.hrtime.bigint()

追加: v10.7.0

• 戻り値: <bigint>

bigint型のprocess.hrtime()メソッドのバージョンで、ナノ秒単位の現在の高解像度リアルタイムをbigintとして返します。

process.hrtime()とは異なり、追加のtime引数はサポートされていません。2 つのbigintの減算によって直接差を計算できるためです。

ESM

import { hrtime } from 'node:process'

const start = hrtime.bigint()
// 191051479007711n

setTimeout(() => {
  const end = hrtime.bigint()
  // 191052633396993n

  console.log(`Benchmark took ${end - start} nanoseconds`)
  // Benchmark took 1154389282 nanoseconds
}, 1000)

CJS

const { hrtime } = require('node:process')

const start = hrtime.bigint()
// 191051479007711n

setTimeout(() => {
  const end = hrtime.bigint()
  // 191052633396993n

  console.log(`Benchmark took ${end - start} nanoseconds`)
  // Benchmark took 1154389282 nanoseconds
}, 1000)

process.initgroups(user, extraGroup)

追加: v0.9.4

• user <string> | <number> ユーザー名または数値識別子。
• extraGroup <string> | <number> グループ名または数値識別子。

process.initgroups()メソッドは/etc/groupファイルを読み取り、ユーザーがメンバーであるすべてのグループを使用して、グループアクセスリストを初期化します。これは特権操作であり、Node.js プロセスにrootアクセス権またはCAP_SETGID機能が必要です。

権限を削除する際は注意してください。

ESM

import { getgroups, initgroups, setgid } from 'node:process'

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // ユーザーを切り替え
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // root gidを削除
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

CJS

const { getgroups, initgroups, setgid } = require('node:process')

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // ユーザーを切り替え
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // root gidを削除
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

この関数は POSIX プラットフォームでのみ使用できます（つまり、Windows または Android では使用できません）。この機能はWorkerスレッドでは使用できません。

process.kill(pid[, signal])

追加日時: v0.0.6

• pid <number> プロセス ID
• signal <string> | <number> 送信するシグナル。文字列または数値で指定します。デフォルト: 'SIGTERM'。

process.kill() メソッドは、pid で識別されるプロセスに signal を送信します。

シグナル名は、'SIGINT' や 'SIGHUP' などの文字列です。詳細は、シグナルイベント と kill(2) を参照してください。

このメソッドは、対象の pid が存在しない場合、エラーをスローします。特別なケースとして、シグナル 0 を使用してプロセスの存在を確認できます。Windows プラットフォームでは、pid がプロセスグループをキルするために使用された場合、エラーをスローします。

この関数の名前が process.kill() であるにもかかわらず、これは kill システムコールのようなシグナル送信機能です。送信されたシグナルは、ターゲットプロセスをキルする以外の動作をする可能性があります。

ESM

import process, { kill } from 'node:process'

process.on('SIGHUP', () => {
  console.log('Got SIGHUP signal.')
})

setTimeout(() => {
  console.log('Exiting.')
  process.exit(0)
}, 100)

kill(process.pid, 'SIGHUP')

CJS

const process = require('node:process')

process.on('SIGHUP', () => {
  console.log('Got SIGHUP signal.')
})

setTimeout(() => {
  console.log('Exiting.')
  process.exit(0)
}, 100)

process.kill(process.pid, 'SIGHUP')

Node.js プロセスが SIGUSR1 を受信すると、Node.js はデバッガーを起動します。シグナルイベント を参照してください。

process.loadEnvFile(path)

追加日時: v21.7.0, v20.12.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1。1 - アクティブ開発中

• path <string> | <URL> | <Buffer> | <undefined>。デフォルト: './.env'

.env ファイルを process.env に読み込みます。.env ファイル内の NODE_OPTIONS の使用は、Node.js には影響しません。

CJS

const { loadEnvFile } = require('node:process')
loadEnvFile()

ESM

import { loadEnvFile } from 'node:process'
loadEnvFile()

process.mainModule

追加日時: v0.1.17

非推奨日時: v14.0.0

[安定版: 0 - 非推奨]

安定版: 0 安定性: 0 - 非推奨: require.main を代わりに使用してください。

• <Object>

process.mainModule プロパティは、require.main を取得する代替方法を提供します。違いは、メインモジュールがランタイムで変更された場合、require.main は、変更が発生する前に要求されたモジュールでは依然として元のメインモジュールを参照する場合があることです。一般的に、両者が同じモジュールを参照すると仮定しても安全です。

require.main と同様に、エントリスクリプトがない場合、process.mainModule は undefined になります。

process.memoryUsage()

[履歴]

バージョン	変更
v13.9.0, v12.17.0	返されるオブジェクトに arrayBuffers を追加
v7.2.0	返されるオブジェクトに external を追加
v0.1.16	追加日時: v0.1.16

• 戻り値: <Object>
  • rss <integer>
  • heapTotal <integer>
  • heapUsed <integer>
  • external <integer>
  • arrayBuffers <integer>

Node.js プロセスのメモリ使用量をバイト単位で記述したオブジェクトを返します。

ESM

import { memoryUsage } from 'node:process'

console.log(memoryUsage())
// 出力:
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }

CJS

const { memoryUsage } = require('node:process')

console.log(memoryUsage())
// 出力:
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }

• heapTotal と heapUsed は V8 のメモリ使用量を参照します。
• external は、V8 によって管理される JavaScript オブジェクトにバインドされた C++ オブジェクトのメモリ使用量を参照します。
• rss (Resident Set Size) は、すべての C++ および JavaScript オブジェクトとコードを含む、プロセスがメインメモリデバイスで占有するスペースの量です（これは割り当てられたメモリの合計のサブセットです）。
• arrayBuffers は、すべての Node.js Buffer を含む、ArrayBuffer と SharedArrayBuffer に割り当てられたメモリを参照します。これは external の値にも含まれます。Node.js が組み込みライブラリとして使用されている場合、ArrayBuffer の割り当てがそのケースでは追跡されないため、この値は 0 になる可能性があります。

Worker スレッドを使用する場合、rss はプロセス全体に対して有効な値になりますが、他のフィールドは現在のスレッドのみを参照します。

process.memoryUsage() メソッドは、メモリ使用量に関する情報を収集するために各ページを反復処理するため、プログラムのメモリ割り当てによっては速度が低下する可能性があります。

process.memoryUsage.rss()

追加日：v15.6.0、v14.18.0

• 戻り値: <integer>

process.memoryUsage.rss()メソッドは、常駐セットサイズ（RSS）をバイト単位で表す整数を返します。

常駐セットサイズとは、プロセスがメインメモリデバイスに占めるスペースの量（割り当てられたメモリの合計のサブセット）であり、すべての C++および JavaScript オブジェクトとコードを含みます。

これは、process.memoryUsage()によって提供されるrssプロパティと同じ値ですが、process.memoryUsage.rss()の方が高速です。

ESM

import { memoryUsage } from 'node:process'

console.log(memoryUsage.rss())
// 35655680

CJS

const { memoryUsage } = require('node:process')

console.log(memoryUsage.rss())
// 35655680

process.nextTick(callback[, ...args])

[履歴]

バージョン	変更
v22.7.0、v20.18.0	安定性をレガシーに変更
v18.0.0	無効なコールバックをcallback引数に渡すと、ERR_INVALID_CALLBACKではなくERR_INVALID_ARG_TYPEがスローされるようになりました。
v1.8.1	callbackの後の追加引数がサポートされるようになりました。
v0.1.26	追加日: v0.1.26

[安定版: 3 - レガシー]

安定版: 3 安定性: 3 - レガシー: 代わりにqueueMicrotask()を使用してください。

• callback <Function>
• ...args <any> callbackを呼び出す際に渡す追加引数

process.nextTick()はcallbackを「次のティックキュー」に追加します。このキューは、JavaScript スタックでの現在の操作が完了し、イベントループが続行される前に完全に排出されます。process.nextTick()を再帰的に呼び出すと、無限ループを作成する可能性があります。詳細は、イベントループガイドを参照してください。

ESM

import { nextTick } from 'node:process'

console.log('start')
nextTick(() => {
  console.log('nextTick callback')
})
console.log('scheduled')
// 出力:
// start
// scheduled
// nextTick callback

CJS

const { nextTick } = require('node:process')

console.log('start')
nextTick(() => {
  console.log('nextTick callback')
})
console.log('scheduled')
// 出力:
// start
// scheduled
// nextTick callback

これは、オブジェクトが構築された後、I/O が発生する前に、ユーザーがイベントハンドラーを割り当てる機会を与えるために、API を開発する場合に重要です。

ESM

import { nextTick } from 'node:process'

function MyThing(options) {
  this.setupOptions(options)

  nextTick(() => {
    this.startDoingStuff()
  })
}

const thing = new MyThing()
thing.getReadyForStuff()

// thing.startDoingStuff()はここで呼び出され、それより前には呼び出されません。

CJS

const { nextTick } = require('node:process')

function MyThing(options) {
  this.setupOptions(options)

  nextTick(() => {
    this.startDoingStuff()
  })
}

const thing = new MyThing()
thing.getReadyForStuff()

// thing.startDoingStuff()はここで呼び出され、それより前には呼び出されません。

API は、100％同期または 100％非同期のいずれかであることが非常に重要です。次の例を考えてみましょう。

// 警告！ 使用しないでください！ 危険な安全でないハザード！
function maybeSync(arg, cb) {
  if (arg) {
    cb()
    return
  }

  fs.stat('file', cb)
}

この API は、次の場合に危険です。

const maybeTrue = Math.random() > 0.5

maybeSync(maybeTrue, () => {
  foo()
})

bar()

foo()とbar()のどちらが先に呼び出されるかは明らかではありません。

次のアプローチの方がはるかに優れています。

ESM

import { nextTick } from 'node:process'

function definitelyAsync(arg, cb) {
  if (arg) {
    nextTick(cb)
    return
  }

  fs.stat('file', cb)
}

CJS

const { nextTick } = require('node:process')

function definitelyAsync(arg, cb) {
  if (arg) {
    nextTick(cb)
    return
  }

  fs.stat('file', cb)
}

queueMicrotask()とprocess.nextTick()の使い分け

queueMicrotask() API はprocess.nextTick()の代替手段であり、解決済みの Promise のthen、catch、finallyハンドラの実行に使用されるのと同じ microtask キューを使用して関数の処理を遅延させます。Node.js では、「next tick キュー」が空になるたびに、直後に microtask キューが空になります。

ESM

import { nextTick } from 'node:process'

Promise.resolve().then(() => console.log(2))
queueMicrotask(() => console.log(3))
nextTick(() => console.log(1))
// Output:
// 1
// 2
// 3

CJS

const { nextTick } = require('node:process')

Promise.resolve().then(() => console.log(2))
queueMicrotask(() => console.log(3))
nextTick(() => console.log(1))
// Output:
// 1
// 2
// 3

ほとんどのユーザランドのユースケースでは、queueMicrotask() API は、複数の JavaScript プラットフォーム環境で動作する移植性が高く信頼性の高い処理遅延メカニズムを提供するため、process.nextTick()よりも優先されるべきです。単純なシナリオでは、queueMicrotask()はprocess.nextTick()の直接的な置き換えとして使用できます。

console.log('start')
queueMicrotask(() => {
  console.log('microtask callback')
})
console.log('scheduled')
// Output:
// start
// scheduled
// microtask callback

2 つの API 間の注目すべき違いの 1 つは、process.nextTick()では、遅延関数が呼び出されたときに引数として渡される追加の値を指定できることです。queueMicrotask()で同じ結果を得るには、クロージャまたはバインドされた関数を使用する必要があります。

function deferred(a, b) {
  console.log('microtask', a + b)
}

console.log('start')
queueMicrotask(deferred.bind(undefined, 1, 2))
console.log('scheduled')
// Output:
// start
// scheduled
// microtask 3

next tick キューと microtask キュー内で発生したエラーの処理方法には、わずかな違いがあります。キューに入れられた microtask コールバック内でスローされたエラーは、可能な限りキューに入れられたコールバック内で処理する必要があります。処理されない場合は、process.on('uncaughtException')イベントハンドラを使用してエラーを捕捉して処理できます。

特別なprocess.nextTick()の機能が必要でない限り、迷ったらqueueMicrotask()を使用してください。

process.noDeprecation

追加：v0.8.0

• <boolean>

process.noDeprecation プロパティは、現在の Node.js プロセスで --no-deprecation フラグが設定されているかどうかを示します。このフラグの動作の詳細については、'warning' イベント と emitWarning() メソッド のドキュメントを参照してください。

process.permission

追加：v20.0.0

• <Object>

この API は、--permission フラグを介して利用可能です。

process.permission は、現在のプロセスの権限を管理するために使用されるメソッドを持つオブジェクトです。追加のドキュメントは、権限モデルにあります。

process.permission.has(scope[, reference])

追加：v20.0.0

• scope <string>
• reference <string>
• 戻り値: <boolean>

プロセスが指定されたスコープと参照にアクセスできるかどうかを確認します。参照が提供されない場合、グローバルスコープが想定されます。たとえば、process.permission.has('fs.read') は、プロセスにすべてのファイルシステム読み取り権限があるかどうかを確認します。

参照は、提供されたスコープに基づいて意味を持ちます。たとえば、スコープがファイルシステムの場合の参照は、ファイルとフォルダを意味します。

利用可能なスコープは次のとおりです。

• fs - すべてのファイルシステム
• fs.read - ファイルシステム読み取り操作
• fs.write - ファイルシステム書き込み操作
• child - 子プロセスの生成操作
• worker - ワーカートレッドの生成操作

// プロセスがREADMEファイルの読み取り権限を持っているかどうかを確認します
process.permission.has('fs.read', './README.md')
// プロセスが読み取り権限操作を持っているかどうかを確認します
process.permission.has('fs.read')

process.pid

追加日: v0.1.15

• <integer>

process.pid プロパティは、プロセスの PID を返します。

ESM

import { pid } from 'node:process'

console.log(`This process is pid ${pid}`)

CJS

const { pid } = require('node:process')

console.log(`This process is pid ${pid}`)

process.platform

追加日: v0.1.16

• <string>

process.platform プロパティは、Node.js バイナリがコンパイルされたオペレーティングシステムプラットフォームを識別する文字列を返します。

現在可能な値は次のとおりです。

• 'aix'
• 'darwin'
• 'freebsd'
• 'linux'
• 'openbsd'
• 'sunos'
• 'win32'

ESM

import { platform } from 'node:process'

console.log(`This platform is ${platform}`)

CJS

const { platform } = require('node:process')

console.log(`This platform is ${platform}`)

Node.js が Android オペレーティングシステム上でビルドされている場合、'android'も返される可能性があります。ただし、Node.js での Android サポートは実験的です。

process.ppid

追加日: v9.2.0, v8.10.0, v6.13.0

• <integer>

process.ppid プロパティは、現在のプロセスの親の PID を返します。

ESM

import { ppid } from 'node:process'

console.log(`The parent process is pid ${ppid}`)

CJS

const { ppid } = require('node:process')

console.log(`The parent process is pid ${ppid}`)

process.release

[履歴]

バージョン	変更点
v4.2.0	ltsプロパティがサポートされるようになりました。
v3.0.0	追加日: v3.0.0

• <Object>

process.release プロパティは、現在のリリースに関するメタデータを含むObjectを返します。これには、ソースターボールとヘッダーのみのターボールの URL が含まれています。

process.releaseには次のプロパティが含まれています。

• name <string> 常に'node'である値。
• sourceUrl <string> 現在のリリースのソースコードを含む*.tar.gz*ファイルを指す絶対 URL。
• headersUrl<string> 現在のリリースのソースヘッダーファイルのみを含む*.tar.gz*ファイルを指す絶対 URL。このファイルは完全なソースファイルよりもはるかに小さく、Node.js ネイティブアドオンのコンパイルに使用できます。
• libUrl <string> | <undefined> 現在のリリースのアーキテクチャとバージョンに一致する*node.lib*ファイルを指す絶対 URL。このファイルは、Node.js ネイティブアドオンのコンパイルに使用されます。このプロパティは、Node.js の Windows ビルドでのみ存在し、他のすべてのプラットフォームでは存在しません。
• lts <string> | <undefined> このリリースのLTSラベルを識別する文字列ラベル。このプロパティは LTS リリースでのみ存在し、Currentリリースを含むその他のすべてのリリースの種類ではundefinedです。有効な値には、LTS リリースのコード名（サポートされなくなったものも含む）が含まれます。
  • 14.15.0 から始まる 14.x LTS ラインの'Fermium'。
  • 16.13.0 から始まる 16.x LTS ラインの'Gallium'。
  • 18.12.0 から始まる 18.x LTS ラインの'Hydrogen'。 その他の LTS リリースコード名については、Node.js Changelog Archiveを参照してください。

{
  name: 'node',
  lts: 'Hydrogen',
  sourceUrl: 'https://nodejs.org/download/release/v18.12.0/node-v18.12.0.tar.gz',
  headersUrl: 'https://nodejs.org/download/release/v18.12.0/node-v18.12.0-headers.tar.gz',
  libUrl: 'https://nodejs.org/download/release/v18.12.0/win-x64/node.lib'
}

ソースツリーの非リリースバージョンからのカスタムビルドでは、nameプロパティのみが存在する場合があります。追加のプロパティが存在することを依存すべきではありません。

process.report

[履歴]

バージョン	変更
v13.12.0, v12.17.0	この API は実験段階ではなくなりました。
v11.8.0	追加：v11.8.0

• <Object>

process.reportは、現在のプロセスの診断レポートを生成するために使用されるメソッドを持つオブジェクトです。追加のドキュメントは、レポートドキュメントでご覧いただけます。

process.report.compact

追加：v13.12.0, v12.17.0

• <boolean>

レポートをコンパクトな形式（1 行の JSON）で書き込みます。これは、人間が読むことを目的としたデフォルトの複数行形式よりも、ログ処理システムで簡単に利用できます。

ESM

import { report } from 'node:process'

console.log(`Reports are compact? ${report.compact}`)

CJS

const { report } = require('node:process')

console.log(`Reports are compact? ${report.compact}`)

process.report.directory

[履歴]

バージョン	変更
v13.12.0, v12.17.0	この API は実験段階ではなくなりました。
v11.12.0	追加：v11.12.0

• <string>

レポートが書き込まれるディレクトリ。デフォルト値は空文字列で、レポートは Node.js プロセスの現在の作業ディレクトリに書き込まれることを示します。

ESM

import { report } from 'node:process'

console.log(`Report directory is ${report.directory}`)

CJS

const { report } = require('node:process')

console.log(`Report directory is ${report.directory}`)

process.report.filename

[履歴]

バージョン	変更
v13.12.0, v12.17.0	この API は実験段階ではなくなりました。
v11.12.0	追加：v11.12.0

• <string>

レポートが書き込まれるファイル名。空文字列に設定されている場合、出力ファイル名はタイムスタンプ、PID、シーケンス番号で構成されます。デフォルト値は空文字列です。

process.report.filenameの値が'stdout'または'stderr'に設定されている場合、レポートはそれぞれプロセスの stdout または stderr に書き込まれます。

ESM

import { report } from 'node:process'

console.log(`Report filename is ${report.filename}`)

CJS

const { report } = require('node:process')

console.log(`Report filename is ${report.filename}`)

process.report.getReport([err])

[履歴]

バージョン	変更
v13.12.0, v12.17.0	この API は実験段階ではなくなりました。
v11.8.0	追加: v11.8.0

• err <Error> JavaScript スタックをレポートするために使用されるカスタムエラー。
• 戻り値: <Object>

実行中のプロセスの診断レポートの JavaScript オブジェクト表現を返します。レポートの JavaScript スタックトレースは、存在する場合はerrから取得されます。

ESM

import { report } from 'node:process'
import util from 'node:util'

const data = report.getReport()
console.log(data.header.nodejsVersion)

// process.report.writeReport() と同様
import fs from 'node:fs'
fs.writeFileSync('my-report.log', util.inspect(data), 'utf8')

CJS

const { report } = require('node:process')
const util = require('node:util')

const data = report.getReport()
console.log(data.header.nodejsVersion)

// process.report.writeReport() と同様
const fs = require('node:fs')
fs.writeFileSync('my-report.log', util.inspect(data), 'utf8')

追加のドキュメントは、レポートドキュメントにあります。

process.report.reportOnFatalError

[履歴]

バージョン	変更
v15.0.0, v14.17.0	この API は実験段階ではなくなりました。
v11.12.0	追加: v11.12.0

• <boolean>

trueの場合、メモリ不足エラーや C++アサーションの失敗などの致命的なエラー時に診断レポートが生成されます。

ESM

import { report } from 'node:process'

console.log(`Report on fatal error: ${report.reportOnFatalError}`)

CJS

const { report } = require('node:process')

console.log(`Report on fatal error: ${report.reportOnFatalError}`)

process.report.reportOnSignal

[履歴]

バージョン	変更
v13.12.0, v12.17.0	この API は実験段階ではなくなりました。
v11.12.0	追加: v11.12.0

• <boolean>

trueの場合、プロセスがprocess.report.signalで指定されたシグナルを受信すると、診断レポートが生成されます。

ESM

import { report } from 'node:process'

console.log(`Report on signal: ${report.reportOnSignal}`)

CJS

const { report } = require('node:process')

console.log(`Report on signal: ${report.reportOnSignal}`)

process.report.reportOnUncaughtException

[履歴]

バージョン	変更
v13.12.0, v12.17.0	この API は実験段階ではなくなりました。
v11.12.0	追加: v11.12.0

• <boolean>

trueの場合、キャッチされない例外が発生すると診断レポートが生成されます。

ESM

import { report } from 'node:process'

console.log(`Report on exception: ${report.reportOnUncaughtException}`)

CJS

const { report } = require('node:process')

console.log(`Report on exception: ${report.reportOnUncaughtException}`)

process.report.excludeEnv

追加: v23.3.0

• <boolean>

trueの場合、環境変数を含まない診断レポートが生成されます。

process.report.signal

[履歴]

バージョン	変更
v13.12.0, v12.17.0	この API は実験段階ではなくなりました。
v11.12.0	追加: v11.12.0

• <string>

診断レポートの作成をトリガーするために使用されるシグナルです。デフォルトは'SIGUSR2'です。

ESM

import { report } from 'node:process'

console.log(`Report signal: ${report.signal}`)

CJS

const { report } = require('node:process')

console.log(`Report signal: ${report.signal}`)

process.report.writeReport([filename][, err])

[履歴]

バージョン	変更点
v13.12.0, v12.17.0	この API は実験的なものではなくなりました。
v11.8.0	追加：v11.8.0

• filename <string> レポートが書き込まれるファイルの名前。これは相対パスでなければならず、process.report.directoryで指定されたディレクトリ、または指定されていない場合は Node.js プロセスの現在の作業ディレクトリに追加されます。
• err <Error> JavaScript スタックのレポートに使用されるカスタムエラー。
• 戻り値: <string> 生成されたレポートのファイル名を返します。

診断レポートをファイルに書き込みます。filenameが指定されていない場合、デフォルトのファイル名には日付、時刻、PID、シーケンス番号が含まれます。レポートの JavaScript スタックトレースは、存在する場合はerrから取得されます。

filenameの値が'stdout'または'stderr'に設定されている場合、レポートはそれぞれプロセスの stdout または stderr に書き込まれます。

ESM

import { report } from 'node:process'

report.writeReport()

CJS

const { report } = require('node:process')

report.writeReport()

追加のドキュメントは、レポートドキュメントにあります。

process.resourceUsage()

追加：v12.6.0

• 戻り値: <Object> 現在のプロセスのリソース使用量。これらの値はすべて、uv_rusage_t構造体uv_getrusageコールから取得されます。
  • userCPUTime <integer> マイクロ秒単位で計算されたru_utimeにマップされます。process.cpuUsage().userと同じ値です。
  • systemCPUTime <integer> マイクロ秒単位で計算されたru_stimeにマップされます。process.cpuUsage().systemと同じ値です。
  • maxRSS <integer> キロバイト単位で使用された最大常駐セットサイズであるru_maxrssにマップされます。
  • sharedMemorySize <integer> ru_ixrssにマップされますが、どのプラットフォームでもサポートされていません。
  • unsharedDataSize <integer> ru_idrssにマップされますが、どのプラットフォームでもサポートされていません。
  • unsharedStackSize <integer> ru_isrssにマップされますが、どのプラットフォームでもサポートされていません。
  • minorPageFault <integer> プロセスのマイナーページフォールトの数であるru_minfltにマップされます。詳しくはこの記事を参照してください。
  • majorPageFault <integer> プロセスのメジャーページフォールトの数であるru_majfltにマップされます。詳しくはこの記事を参照してください。このフィールドは Windows ではサポートされていません。
  • swappedOut <integer> ru_nswapにマップされますが、どのプラットフォームでもサポートされていません。
  • fsRead <integer> ファイルシステムが入力を実行する必要があった回数を示すru_inblockにマップされます。
  • fsWrite <integer> ファイルシステムが出力を実行する必要があった回数を示すru_oublockにマップされます。
  • ipcSent <integer> ru_msgsndにマップされますが、どのプラットフォームでもサポートされていません。
  • ipcReceived <integer> ru_msgrcvにマップされますが、どのプラットフォームでもサポートされていません。
  • signalsCount <integer> ru_nsignalsにマップされますが、どのプラットフォームでもサポートされていません。
  • voluntaryContextSwitches <integer> プロセスが自発的にプロセッサを解放したために CPU コンテキストスイッチが発生した回数を示すru_nvcswにマップされます（通常はリソースの可用性を待つため）。このフィールドは Windows ではサポートされていません。
  • involuntaryContextSwitches <integer> より高い優先度のプロセスが実行可能になったか、現在のプロセスがタイムスライスを超えたために CPU コンテキストスイッチが発生した回数を示すru_nivcswにマップされます。このフィールドは Windows ではサポートされていません。

ESM

import { resourceUsage } from 'node:process'

console.log(resourceUsage())
/*
  出力例：
  {
    userCPUTime: 82872,
    systemCPUTime: 4143,
    maxRSS: 33164,
    sharedMemorySize: 0,
    unsharedDataSize: 0,
    unsharedStackSize: 0,
    minorPageFault: 2469,
    majorPageFault: 0,
    swappedOut: 0,
    fsRead: 0,
    fsWrite: 8,
    ipcSent: 0,
    ipcReceived: 0,
    signalsCount: 0,
    voluntaryContextSwitches: 79,
    involuntaryContextSwitches: 1
  }
*/

CJS

const { resourceUsage } = require('node:process')

console.log(resourceUsage())
/*
  出力例：
  {
    userCPUTime: 82872,
    systemCPUTime: 4143,
    maxRSS: 33164,
    sharedMemorySize: 0,
    unsharedDataSize: 0,
    unsharedStackSize: 0,
    minorPageFault: 2469,
    majorPageFault: 0,
    swappedOut: 0,
    fsRead: 0,
    fsWrite: 8,
    ipcSent: 0,
    ipcReceived: 0,
    signalsCount: 0,
    voluntaryContextSwitches: 79,
    involuntaryContextSwitches: 1
  }
*/

process.send(message[, sendHandle[, options]][, callback])

追加日: v0.5.9

• message <Object>

• sendHandle <net.Server> | <net.Socket>

• options <Object> 特定の種類のハンドルの送信をパラメーター化するために使用されます。options は以下のプロパティをサポートします。

  • keepOpen <boolean> net.Socket のインスタンスを渡す際に使用できる値です。true の場合、ソケットは送信プロセスで開いたままになります。デフォルト: false。

• callback <Function>

• 戻り値: <boolean>

Node.js が IPC チャネルを使用して生成された場合、process.send() メソッドを使用して親プロセスにメッセージを送信できます。メッセージは親の ChildProcess オブジェクトの 'message' イベントとして受信されます。

Node.js が IPC チャネルを使用して生成されなかった場合、process.send は undefined になります。

メッセージはシリアル化とパースを通過します。結果として得られるメッセージは、元の送信メッセージと異なる場合があります。

process.setegid(id)

追加日: v2.0.0

• id <string> | <number> グループ名または ID

process.setegid() メソッドは、プロセスの有効なグループ ID を設定します。（setegid(2) を参照してください。）id は、数値 ID またはグループ名の文字列として渡すことができます。グループ名が指定された場合、このメソッドは関連付けられた数値 ID を解決している間ブロックします。

ESM

import process from 'node:process'

if (process.getegid && process.setegid) {
  console.log(`Current gid: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`New gid: ${process.getegid()}`)
  } catch (err) {
    console.error(`Failed to set gid: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getegid && process.setegid) {
  console.log(`Current gid: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`New gid: ${process.getegid()}`)
  } catch (err) {
    console.error(`Failed to set gid: ${err}`)
  }
}

この関数は POSIX プラットフォームでのみ使用できます（つまり、Windows や Android では使用できません）。この機能は Worker スレッドでは使用できません。

process.seteuid(id)

追加日: v2.0.0

• id <string> | <number> ユーザー名または ID

process.seteuid()メソッドは、プロセスの実効ユーザー ID を設定します。（seteuid(2)参照）idには、数値 ID またはユーザー名文字列のいずれかを渡すことができます。ユーザー名を指定した場合、関連付けられた数値 ID が解決されるまで、このメソッドはブロックされます。

ESM

import process from 'node:process'

if (process.geteuid && process.seteuid) {
  console.log(`Current uid: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`New uid: ${process.geteuid()}`)
  } catch (err) {
    console.error(`Failed to set uid: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.geteuid && process.seteuid) {
  console.log(`Current uid: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`New uid: ${process.geteuid()}`)
  } catch (err) {
    console.error(`Failed to set uid: ${err}`)
  }
}

この関数は、POSIX プラットフォーム（つまり、Windows または Android ではない）でのみ使用できます。この機能は、Worker スレッドでは使用できません。

process.setgid(id)

追加日: v0.1.31

• id <string> | <number> グループ名または ID

process.setgid()メソッドは、プロセスのグループ ID を設定します。（setgid(2)参照）idには、数値 ID またはグループ名文字列のいずれかを渡すことができます。グループ名を指定した場合、関連付けられた数値 ID が解決されるまで、このメソッドはブロックされます。

ESM

import process from 'node:process'

if (process.getgid && process.setgid) {
  console.log(`Current gid: ${process.getgid()}`)
  try {
    process.setgid(501)
    console.log(`New gid: ${process.getgid()}`)
  } catch (err) {
    console.error(`Failed to set gid: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getgid && process.setgid) {
  console.log(`Current gid: ${process.getgid()}`)
  try {
    process.setgid(501)
    console.log(`New gid: ${process.getgid()}`)
  } catch (err) {
    console.error(`Failed to set gid: ${err}`)
  }
}

この関数は、POSIX プラットフォーム（つまり、Windows または Android ではない）でのみ使用できます。この機能は、Worker スレッドでは使用できません。

process.setgroups(groups)

追加日時: v0.9.4

• groups <integer[]>

process.setgroups()メソッドは、Node.js プロセスの補足グループ ID を設定します。これは特権操作であり、Node.js プロセスがrootまたはCAP_SETGID capability を持っている必要があります。

groups配列には、数値のグループ ID、グループ名、またはその両方を格納できます。

ESM

import process from 'node:process'

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // 新しいグループ
  } catch (err) {
    console.error(`Failed to set groups: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // 新しいグループ
  } catch (err) {
    console.error(`Failed to set groups: ${err}`)
  }
}

この関数は POSIX プラットフォームでのみ使用可能です（つまり、Windows または Android では使用できません）。この機能はWorker スレッドでは使用できません。

process.setuid(id)

追加日時: v0.1.28

• id <integer> | <string>

process.setuid(id)メソッドは、プロセスのユーザー ID を設定します。（setuid(2)を参照）。idは、数値 ID またはユーザー名文字列として渡すことができます。ユーザー名を指定した場合、メソッドは関連付けられた数値 ID を解決しながらブロックします。

ESM

import process from 'node:process'

if (process.getuid && process.setuid) {
  console.log(`Current uid: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`New uid: ${process.getuid()}`)
  } catch (err) {
    console.error(`Failed to set uid: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getuid && process.setuid) {
  console.log(`Current uid: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`New uid: ${process.getuid()}`)
  } catch (err) {
    console.error(`Failed to set uid: ${err}`)
  }
}

この関数は POSIX プラットフォームでのみ使用可能です（つまり、Windows または Android では使用できません）。この機能はWorker スレッドでは使用できません。

process.setSourceMapsEnabled(val)

追加: v16.6.0, v14.18.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1 - 実験的

• val <boolean>

この関数は、スタックトレースに対するSource Map v3のサポートを有効または無効にします。

これは、コマンドラインオプション--enable-source-mapsで Node.js プロセスを起動した場合と同じ機能を提供します。

ソースマップが有効になってからロードされた JavaScript ファイル内のソースマップのみが解析およびロードされます。

process.setUncaughtExceptionCaptureCallback(fn)

追加: v9.3.0

• fn <Function> | <null>

process.setUncaughtExceptionCaptureCallback()関数は、キャッチされない例外が発生したときに呼び出される関数を設定します。この関数は、例外値自体を最初の引数として受け取ります。

このような関数が設定されている場合、'uncaughtException'イベントは発生しません。コマンドラインから--abort-on-uncaught-exceptionを渡した場合、またはv8.setFlagsFromString()で設定した場合、プロセスは異常終了しません。レポート生成などの例外発生時に実行するように設定されたアクションにも影響します。

キャプチャ関数を設定解除するには、process.setUncaughtExceptionCaptureCallback(null)を使用できます。別のキャプチャ関数が設定されている間にnull以外の引数でこのメソッドを呼び出すと、エラーが発生します。

この関数の使用は、非推奨のdomain組み込みモジュールを使用することと相互に排他的です。

process.sourceMapsEnabled

追加: v20.7.0, v18.19.0

[安定版: 1 - 実験的]

安定版: 1 安定性: 1 - 実験的

• <boolean>

process.sourceMapsEnabledプロパティは、スタックトレースに対するSource Map v3のサポートが有効かどうかを返します。

process.stderr

• <Stream>

process.stderr プロパティは、stderr（fd 2）に接続されたストリームを返します。fd 2 がファイルを参照する場合、Writable ストリームになりますが、それ以外の場合はnet.Socket（Duplex ストリーム）です。

process.stderr は、他の Node.js ストリームとは重要な点で異なります。詳細は、process I/O に関する注記を参照してください。

process.stderr.fd

• <number>

このプロパティは、process.stderr の基になるファイル記述子の値を参照します。値は 2 に固定されています。Worker スレッドでは、このフィールドは存在しません。

process.stdin

• <Stream>

process.stdin プロパティは、stdin（fd 0）に接続されたストリームを返します。fd 0 がファイルを参照する場合、Readable ストリームになりますが、それ以外の場合はnet.Socket（Duplex ストリーム）です。

stdin からの読み取り方法の詳細については、readable.read()を参照してください。

Duplex ストリームとして、process.stdin は、v0.10 より前の Node.js 用に記述されたスクリプトと互換性のある「古い」モードでも使用できます。詳細は、Stream の互換性を参照してください。

「古い」ストリームモードでは、stdin ストリームはデフォルトで一時停止されているため、process.stdin.resume() を呼び出してから読み取る必要があります。また、process.stdin.resume() を呼び出すこと自体が、ストリームを「古い」モードに切り替えることに注意してください。

process.stdin.fd

• <number>

このプロパティは、process.stdin の基になるファイル記述子の値を参照します。値は 0 に固定されています。Worker スレッドでは、このフィールドは存在しません。

process.stdout

• <Stream>

process.stdout プロパティは、stdout (fd 1) に接続されたストリームを返します。fd 1 がファイルを参照する場合、Writable ストリームになりますが、それ以外の場合は net.Socket (Duplex ストリーム) です。

例えば、process.stdin を process.stdout にコピーするには：

ESM

import { stdin, stdout } from 'node:process'

stdin.pipe(stdout)

CJS

const { stdin, stdout } = require('node:process')

stdin.pipe(stdout)

process.stdout は、他の Node.js ストリームとは重要な点で異なります。詳しくはプロセス I/O に関する注記 を参照してください。

process.stdout.fd

• <number>

このプロパティは、process.stdout の基となるファイル記述子の値を参照します。値は 1 に固定されています。Worker スレッドでは、このフィールドは存在しません。

プロセス I/O に関する注記

process.stdout と process.stderr は、他の Node.js ストリームとは重要な点で異なります。

これらの動作は、歴史的な理由（変更すると下位互換性がなくなるため）と、一部のユーザーが期待しているため、部分的にそうなっています。

同期書き込みは、console.log() や console.error() で書き込まれた出力が予期せずインターリーブされたり、非同期書き込みが完了する前に process.exit() が呼び出された場合に全く書き込まれなかったりするといった問題を回避します。詳しくはprocess.exit() を参照してください。

• 警告: 同期書き込みは、書き込みが完了するまでイベントループをブロックします。ファイルへの出力の場合、ほぼ瞬時に行われますが、システム負荷が高い場合、受信側で読み取られていないパイプ、または遅い端末やファイルシステムでは、イベントループが頻繁に、そして十分な時間ブロックされる可能性があり、深刻なパフォーマンスの悪化につながる可能性があります。対話型のターミナルセッションに書き込む場合は問題ないかもしれませんが、プロダクションログをプロセスの出力ストリームに書き込む場合は、特に注意してください。

ストリームがTTY コンテキストに接続されているかどうかを確認するには、isTTY プロパティを確認します。

例えば：

$ node -p "Boolean(process.stdin.isTTY)"
true
$ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
false
$ node -p "Boolean(process.stdout.isTTY)"
true
$ node -p "Boolean(process.stdout.isTTY)" | cat
false

詳しくはTTY のドキュメントを参照してください。

process.throwDeprecation

追加日時: v0.9.12

• <boolean>

process.throwDeprecationの初期値は、現在の Node.js プロセスで--throw-deprecationフラグが設定されているかどうかを示します。process.throwDeprecationは変更可能なので、非推奨警告がエラーになるかどうかは、実行時に変更できます。詳細については、'warning'イベントとemitWarning()メソッドのドキュメントを参照してください。

$ node --throw-deprecation -p "process.throwDeprecation"
true
$ node -p "process.throwDeprecation"
undefined
$ node
> process.emitWarning('test', 'DeprecationWarning');
undefined
> (node:26598) DeprecationWarning: test
> process.throwDeprecation = true;
true
> process.emitWarning('test', 'DeprecationWarning');
Thrown:
[DeprecationWarning: test] { name: 'DeprecationWarning' }

process.title

追加日時: v0.1.104

• <string>

process.titleプロパティは、現在のプロセスタイトルを返します（つまり、psの現在の値を返します）。process.titleに新しい値を代入すると、psの現在の値が変更されます。

新しい値が代入されると、プラットフォームによってタイトルの最大長に異なる制限が課せられます。通常、そのような制限は非常に限定的です。たとえば、Linux と macOS では、process.titleはバイナリ名とコマンドライン引数の長さの合計に制限されます。これは、process.titleの設定によってプロセスのargvメモリが上書きされるためです。Node.js v0.8 では、environメモリも上書きすることでより長いプロセスタイトル文字列を許可していましたが、これはいくつかの（かなり分かりにくい）ケースで潜在的に安全性が低く、混乱を招く可能性がありました。

process.titleに値を代入しても、macOS アクティビティモニタや Windows サービスマネージャーなどのプロセス管理アプリケーション内で正確なラベルが表示されるとは限りません。

process.traceDeprecation

追加: v0.8.0

• <boolean>

process.traceDeprecationプロパティは、現在の Node.js プロセスで--trace-deprecationフラグが設定されているかどうかを示します。このフラグの動作の詳細については、'warning'イベントとemitWarning()メソッドのドキュメントを参照してください。

process.umask()

[履歴]

バージョン	変更
v14.0.0, v12.19.0	引数なしでprocess.umask()を呼び出すことは非推奨となりました。
v0.1.19	追加: v0.1.19

[安定版: 0 - 非推奨]

安定版: 0 安定性: 0 - 非推奨。引数なしでprocess.umask()を呼び出すと、プロセス全体の umask が 2 回書き込まれます。これは、スレッド間の競合状態を引き起こし、潜在的なセキュリティ脆弱性となります。安全でクロスプラットフォームの代替 API はありません。

process.umask()は、Node.js プロセスのファイルモード作成マスクを返します。子プロセスは、親プロセスからマスクを継承します。

process.umask(mask)

追加: v0.1.19

• mask <string> | <integer>

process.umask(mask)は、Node.js プロセスのファイルモード作成マスクを設定します。子プロセスは、親プロセスからマスクを継承します。以前のマスクを返します。

ESM

import { umask } from 'node:process'

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`)

CJS

const { umask } = require('node:process')

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`)

Worker スレッドでは、process.umask(mask)は例外をスローします。

process.uptime()

追加日時: v0.5.0

• 戻り値: <number>

process.uptime()メソッドは、現在の Node.js プロセスが実行されている秒数を返します。

戻り値には、秒の小数部が含まれます。整数秒を取得するにはMath.floor()を使用してください。

process.version

追加日時: v0.1.3

• <string>

process.versionプロパティには、Node.js のバージョン文字列が含まれています。

ESM

import { version } from 'node:process'

console.log(`Version: ${version}`)
// Version: v14.8.0

CJS

const { version } = require('node:process')

console.log(`Version: ${version}`)
// Version: v14.8.0

先頭のvを除いたバージョン文字列を取得するには、process.versions.nodeを使用します。

process.versions

[履歴]

バージョン	変更点
v9.0.0	v8プロパティに、Node.js 固有のサフィックスが含まれるようになりました。
v4.2.0	icuプロパティがサポートされるようになりました。
v0.2.0	追加日時: v0.2.0

• <Object>

process.versionsプロパティは、Node.js とその依存関係のバージョン文字列をリストしたオブジェクトを返します。process.versions.modulesは現在の ABI バージョンを示しており、C++ API が変更されるたびに増加します。Node.js は、異なるモジュール ABI バージョンに対してコンパイルされたモジュールのロードを拒否します。

ESM

import { versions } from 'node:process'

console.log(versions)

CJS

const { versions } = require('node:process')

console.log(versions)

以下の様なオブジェクトを生成します。

{ node: '23.0.0',
  acorn: '8.11.3',
  ada: '2.7.8',
  ares: '1.28.1',
  base64: '0.5.2',
  brotli: '1.1.0',
  cjs_module_lexer: '1.2.2',
  cldr: '45.0',
  icu: '75.1',
  llhttp: '9.2.1',
  modules: '127',
  napi: '9',
  nghttp2: '1.61.0',
  nghttp3: '0.7.0',
  ngtcp2: '1.3.0',
  openssl: '3.0.13+quic',
  simdjson: '3.8.0',
  simdutf: '5.2.4',
  sqlite: '3.46.0',
  tz: '2024a',
  undici: '6.13.0',
  unicode: '15.1',
  uv: '1.48.0',
  uvwasi: '0.0.20',
  v8: '12.4.254.14-node.11',
  zlib: '1.3.0.1-motley-7d77fb7' }

終了コード

Node.js は、非同期操作が保留されていない場合、通常は 0 のステータスコードで終了します。他のケースでは、以下のステータスコードが使用されます。

• 1 キャッチされない致命的な例外: キャッチされない例外が発生し、ドメインまたは 'uncaughtException' イベントハンドラによって処理されませんでした。
• 2: 未使用（Bash によって組み込みの誤用のために予約済み）
• 3 内部 JavaScript パースエラー: Node.js ブートストラッププロセス内部の JavaScript ソースコードでパースエラーが発生しました。これは非常にまれであり、一般的には Node.js 自体の開発中にのみ発生します。
• 4 内部 JavaScript 評価失敗: Node.js ブートストラッププロセス内部の JavaScript ソースコードが評価時に関数値を返せませんでした。これは非常にまれであり、一般的には Node.js 自体の開発中にのみ発生します。
• 5 致命的なエラー: V8 で回復不可能な致命的なエラーが発生しました。通常、FATAL ERROR というプレフィックスが付いたメッセージが stderr に出力されます。
• 6 非関数内部例外ハンドラ: キャッチされない例外が発生しましたが、内部の致命的な例外ハンドラ関数が何らかの理由で関数に設定されておらず、呼び出すことができませんでした。
• 7 内部例外ハンドラのランタイム失敗: キャッチされない例外が発生し、内部の致命的な例外ハンドラ関数自体が処理を試行中にエラーをスローしました。これは、たとえば、'uncaughtException' または domain.on('error') ハンドラがエラーをスローした場合に発生する可能性があります。
• 8: 未使用。以前のバージョンの Node.js では、終了コード 8 はキャッチされない例外を示すことがありました。
• 9 無効な引数: 未知のオプションが指定されているか、値を必要とするオプションに値が提供されていません。
• 10 内部 JavaScript ランタイム失敗: Node.js ブートストラッププロセス内部の JavaScript ソースコードが、ブートストラップ関数が呼び出されたときにエラーをスローしました。これは非常にまれであり、一般的には Node.js 自体の開発中にのみ発生します。
• 12 無効なデバッグ引数: --inspect および/または --inspect-brk オプションが設定されていましたが、選択されたポート番号が無効であるか、使用できませんでした。
• 13 未解決のトップレベル Await: トップレベルコードの関数外で await が使用されましたが、渡された Promise が解決しませんでした。
• 14 スナップショット失敗: V8 スタートアップスナップショットをビルドするために Node.js が起動されましたが、アプリケーションの状態に関する特定の要件が満たされなかったため失敗しました。
• \>128 シグナルによる終了: Node.js が SIGKILL や SIGHUP などの致命的なシグナルを受信した場合、その終了コードはシグナルコードの値に 128 を加えたものになります。これは標準的な POSIX の慣習であり、終了コードは 7 ビット整数として定義されており、シグナルによる終了は最上位ビットを設定し、シグナルコードの値を含みます。たとえば、シグナル SIGABRT の値は 6 なので、予想される終了コードは 128 + 6 、つまり 134 になります。