Процесс

Исходный код: lib/process.js

Объект process — это global, предоставляющий информацию о текущем процессе Node.js и позволяющий управлять им. Как глобальный объект, он всегда доступен приложениям Node.js без использования require(). Его также можно явно получить с помощью require().

const process = require('process');

События процесса

Объект process является экземпляром EventEmitter.

Событие: `'beforeExit'`

Добавлен в: v0.11.12

Событие 'beforeExit' генерируется, когда Node.js очищает свой цикл событий и не имеет дополнительных задач для планирования. Обычно процесс Node.js завершается, когда нет запланированных задач, но обработчик, зарегистрированный на событии 'beforeExit', может выполнять асинхронные вызовы и, таким образом, заставить процесс Node.js продолжить работу.

Обработчик вызывается с значением process.exitCode в качестве единственного аргумента.

Событие 'beforeExit' не генерируется для условий явного завершения, таких как вызов process.exit() или необработанных исключений.

Событие 'beforeExit' не следует использовать в качестве альтернативы событию 'exit', если только не планируется выполнить дополнительные задачи.

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 (см. документацию Процесс-потомка и Кластер), событие 'disconnect' будет генерироваться при закрытии канала IPC.

Событие: `'exit'`

Добавлен в: v0.1.7

code <целое число>

Событие 'exit' генерируется при предстоящем завершении процесса Node.js в результате:

Явного вызова метода process.exit();
Отсутствия дополнительных задач в цикле событий Node.js.

Нет возможности предотвратить завершение цикла событий на этом этапе, и после завершения работы всех обработчиков события 'exit' процесс Node.js завершится.

Обработчик вызывается с кодом завершения, указанным либо свойством process.exitCode, либо аргументом exitCode метода process.exit().

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

Функции-обработчики обязаны выполнять только синхронные операции. Процесс Node.js завершится сразу после вызова обработчиков события 'exit', что приведёт к отказу от любых дополнительных задач, ожидающих выполнения в цикле событий. Например, в следующем примере таймаут никогда не произойдёт:

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

Событие: `'message'`

Добавлен в: v0.5.10

message <объект> | <булево> | <число> | <строка> | <null> — распарсенный JSON-объект или сериализуемое примитивное значение.
sendHandle <net.Сервер> | <net.Сокет> объект net.Server или net.Socket, или undefined.

Если процесс Node.js запущен с каналом IPC (см. документацию Процесс-потомка и Кластер), событие 'message' генерируется всякий раз, когда сообщение, отправленное родительским процессом с помощью childprocess.send(), получает дочерний процесс.

Сообщение проходит сериализацию и парсинг. Результирующее сообщение может отличаться от исходного.

Если опция serialization была установлена в advanced при запуске процесса, аргумент message может содержать данные, которые JSON не может представить. Дополнительные сведения см. в разделе Расширенная сериализация для child_process.

Событие: `'multipleResolves'`

Добавлен в: v10.12.0

type <строка> Тип разрешения. Один из 'resolve' или 'reject'.
promise <Promise> Promise, который был разрешён или отклонён более одного раза.
value <любое> Значение, с помощью которого Promise был разрешён или отклонён после первоначального разрешения.

Событие 'multipleResolves' генерируется всякий раз, когда Promise был:

Разрешён более одного раза.
Отклонён более одного раза.
Отклонён после разрешения.
Разрешён после отклонения.

Это полезно для отслеживания потенциальных ошибок в приложении при использовании конструктора Promise, поскольку несколько разрешений проглатываются безвозвратно. Однако возникновение этого события не обязательно означает ошибку. Например, Promise.race() может вызвать событие 'multipleResolves'.

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' генерируется при уменьшении списка необработанных отклонений.

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

В этом примере, список unhandledRejections Map будет расти и уменьшаться со временем, отражая отклонения, которые начинаются как необработанные, а затем становятся обработанными. Такие ошибки можно регистрировать в журнале ошибок либо периодически (что, вероятно, лучше для долгоработающих приложений), либо при выходе из процесса (что, вероятно, удобнее для скриптов).

Событие: `'uncaughtException'`

История

Версия	Изменения
v12.0.0	Добавлен аргумент `origin`.
v0.1.18	Добавлен в: v0.1.18

err <Ошибка> Необработанное исключение.
origin <строка> Указывает, происходит ли исключение из-за необработанного отклонения или синхронной ошибки. Может быть 'uncaughtException' или 'unhandledRejection'. Последний используется только в сочетании со флагом --unhandled-rejections , установленным в strict, и необработанным отклонением.

Событие 'uncaughtException' генерируется, когда необработанное JavaScript-исключение возвращается в цикл событий. По умолчанию Node.js обрабатывает такие исключения, выводя отладочную информацию в stderr и завершая работу с кодом 1, игнорируя любой ранее заданный process.exitCode. Добавление обработчика для события 'uncaughtException' переопределяет это поведение по умолчанию. Альтернативно, измените process.exitCode в обработчике события 'uncaughtException', что приведёт к завершению процесса с указанным кодом завершения. В противном случае, в присутствии такого обработчика, процесс завершится с кодом 0.

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

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

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

Можно отслеживать события 'uncaughtException' без переопределения поведения по умолчанию по завершению процесса, установив обработчик для события 'uncaughtExceptionMonitor'.

Предупреждение: Правильное использование `'uncaughtException'`

'uncaughtException' — это грубый механизм обработки исключений, который следует использовать только в крайних случаях. Его не следует применять в качестве замены On Error Resume Next . Необработанные исключения подразумевают, что приложение находится в неопределённом состоянии. Попытка продолжить работу приложения без надлежащего восстановления после исключения может привести к дополнительным непредвиденным и непредсказуемым проблемам.

Исключения, сгенерированные внутри обработчика события, не будут перехвачены. Вместо этого процесс завершится с ненулевым кодом завершения, и будет выведен стек вызовов. Это делается для предотвращения бесконечной рекурсии.

Попытка продолжить работу приложения после необработанного исключения может быть подобна отключению питания при обновлении компьютера. В девяти случаях из десяти ничего не произойдёт. Но в десятом случае система может быть повреждена.

Правильное использование 'uncaughtException' заключается в выполнении синхронной очистки выделенных ресурсов (например, дескрипторов файлов, дескрипторов, и т.д.) перед завершением процесса. После 'uncaughtException' безопасно продолжать обычную работу.

Для более надёжного перезапуска аварийного приложения, независимо от того, был ли выведен 'uncaughtException', следует использовать внешний монитор в отдельном процессе для обнаружения сбоев приложения и последующего восстановления или перезапуска по мере необходимости.

Событие: `'uncaughtExceptionMonitor'`

Добавлен в: v12.17.0

err <Error> Необработанное исключение.
origin <string> Указывает, происходит ли исключение от необработанного отклонения или от синхронных ошибок. Может быть либо 'uncaughtException', либо 'unhandledRejection'.

Событие 'uncaughtExceptionMonitor' генерируется перед событием 'uncaughtException' или вызовом обработчика, установленного через process.setUncaughtExceptionCaptureCallback().

Установка обработчика события 'uncaughtExceptionMonitor' не изменяет поведение после генерации события 'uncaughtException'. Процесс всё равно аварийно завершится, если обработчик события 'uncaughtException' не установлен.

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

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

Событие: `'unhandledRejection'`

История

Версия	Изменения
v7.0.0	Отказ от обработки `Promise` отклонений устарел.
v6.6.0	Необработанные `Promise` отклонения теперь генерируют предупреждение процесса.
v1.4.1	Добавлен в: v1.4.1

reason <Error> | <any> Объект, с помощью которого было отклонено обещание (обычно объект Error).
promise <Promise> Отклоненное обещание.

Событие 'unhandledRejection' генерируется всякий раз, когда Promise отклоняется, и к обещанию не прикреплён обработчик ошибок в течение одного цикла событий. При программировании с обещаниями исключения инкапсулируются в виде «отклоненных обещаний». Отклонения могут быть перехвачены и обработаны с помощью promise.catch() и распространяются через цепочку Promise. Событие 'unhandledRejection' полезно для обнаружения и отслеживания отклонений обещаний, которые ещё не обработаны.

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

Следующие события также вызовут генерацию события %%%CODE_BLOCK_115%%:

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

В этом примере можно отслеживать отклонение как ошибку разработчика, как обычно бывает для других событий '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 может генерировать предупреждения всякий раз, когда обнаруживает плохие практические приемы программирования, которые могут привести к неэффективному исполнению приложения, ошибкам или уязвимостям.

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.

Следующий пример демонстрирует предупреждение, которое выводится в 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 командной строки позволяет включить вывод полного стека следов в стандартный вывод предупреждений в консоли.

Запуск Node.js с флагом командной строки --throw-deprecation приведет к тому, что пользовательские предупреждения об устаревании будут выбрасываться как исключения.

Использование флага командной строки --trace-deprecation выведет пользовательское предупреждение об устаревании в stderr вместе с трассировкой стека.

Использование флага командной строки --no-deprecation подавит весь вывод пользовательского предупреждения об устаревании.

Флаги командной строки *-deprecation влияют только на предупреждения, использующие имя 'DeprecationWarning'.

Генерация пользовательских предупреждений

См. метод process.emitWarning() для выдачи пользовательских или специфичных для приложения предупреждений.

События сигналов

События сигналов генерируются, когда процесс Node.js получает сигнал. Справочную информацию по стандартным именам сигналов POSIX, таким как 'SIGINT', 'SIGHUP', и т.д., можно найти в signal(7).

Сигналы недоступны в потоках Worker.

Обработчик сигнала получит имя сигнала ('SIGINT', 'SIGTERM', и т.д.) в качестве первого аргумента.

Имя каждого события будет общим заглавным именем сигнала (например, 'SIGINT' для SIGINT сигналов).

// 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 + signal number. Если для одного из этих сигналов установлен обработчик, его поведение по умолчанию будет удалено (Node.js больше не завершится).
'SIGPIPE' игнорируется по умолчанию. Его можно обработать.
'SIGHUP' генерируется в Windows при закрытии окна консоли и на других платформах в различных аналогичных ситуациях. См. signal(7). Его можно обработать, однако Node.js будет безусловно завершён Windows примерно через 10 секунд. На платформах, отличных от Windows, поведение по умолчанию для SIGHUP — завершение Node.js, но после установки обработчика его поведение по умолчанию будет удалено.
'SIGTERM' не поддерживается в Windows, но его можно обработать.
'SIGINT' из терминала поддерживается на всех платформах и обычно генерируется нажатием Ctrl+C (хотя это может быть настраиваемо). Он не генерируется, когда включен режим терминала raw и используется Ctrl+C.
'SIGBREAK' выдаётся в Windows при нажатии Ctrl+Break. На платформах, отличных от Windows, его можно обработать, но нет способа его отправить или сгенерировать.
'SIGWINCH' выдаётся при изменении размера консоли. В Windows это произойдёт только при записи в консоль, когда курсор перемещается или используется читабельный tty в режиме raw.
'SIGKILL' не может быть обработан, он безусловно завершит Node.js на всех платформах.
'SIGSTOP' не может быть обработан.
'SIGBUS', 'SIGFPE', 'SIGSEGV' и 'SIGILL', если они не сгенерированы искусственно с помощью kill(2), оставляют процесс в состоянии, в котором небезопасно вызывать обработчики JS. Это может привести к зависанию процесса в бесконечном цикле, так как обработчики, подключенные с помощью process.on(), вызываются асинхронно и, следовательно, не способны исправить основную проблему.
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 — специальный, только для чтения Set разрешённых флагов в среде NODE_OPTIONS.

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, и т. д.
Флаги могут содержать один или несколько символов равно (=); все символы после и включая первый символ равно будут проигнорированы; например, --stack-trace-limit=100.
Флаги должны быть допустимы в NODE_OPTIONS.

При итерации по process.allowedNodeEnvironmentFlags, флаги будут появляться только один раз; каждый начнётся с одного или нескольких дефисов. Флаги, передаваемые в V8, будут содержать подчёркивания вместо неведущих дефисов:

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

Методы add(), clear(), и delete() из process.allowedNodeEnvironmentFlags ничего не делают и завершатся без ошибок.

Если Node.js был скомпилирован без поддержки NODE_OPTIONS (показано в process.config), process.allowedNodeEnvironmentFlags будет содержать то, что было бы допустимо.

`process.arch`

Добавлен в: v0.5.0

<string>

Архитектура процессора операционной системы, для которой был скомпилирован двоичный файл Node.js. Возможные значения: 'arm', 'arm64', 'ia32', 'mips','mipsel', 'ppc', 'ppc64', 's390', 's390x', 'x32', и 'x64'.

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

`process.argv`

Добавлен в: v0.1.27

<string[]>

Свойство process.argv возвращает массив, содержащий аргументы командной строки, переданные при запуске процесса Node.js. Первый элемент будет process.execPath. Смотрите process.argv0 если требуется доступ к исходному значению argv[0]. Второй элемент будет путём к файлу JavaScript, который выполняется. Остальные элементы будут дополнительными аргументами командной строки.

Например, предполагая следующий скрипт для process-args.js:

// print process.argv
process.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 хранит только для чтения копию исходного значения argv[0] переданного при запуске Node.js.

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

`process.channel`

Добавлен в: v7.1.0

<Object>

Если процесс Node.js был запущен с каналом IPC (см. документацию Процесса дочернего процесса), свойство process.channel является ссылкой на канал IPC. Если канал IPC не существует, это свойство undefined.

`process.chdir(directory)`

Добавлен в: v0.1.17

directory <string>

Метод process.chdir() изменяет текущую рабочую директорию процесса Node.js или вызывает исключение, если это не удалось (например, если указанная directory не существует).

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

Эта функция недоступна в потоках Worker.

`process.config`

Добавлен в: v0.7.7

<Object>

Свойство process.config возвращает Object, содержащий JavaScript-представление конфигурационных параметров, используемых для компиляции текущего исполняемого файла Node.js. Это то же самое, что файл config.gypi, который был создан при выполнении скрипта ./configure.

Пример возможного вывода:

{
  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_dtrace: 'false',
     node_use_openssl: 'true',
     node_shared_openssl: 'false',
     strict_aliasing: 'true',
     target_arch: 'x64',
     v8_use_snapshot: 1
   }
}

Свойство process.config не является только для чтения, и существуют модули в экосистеме, которые известны расширяют, изменяют или полностью заменяют значение process.config.

`process.connected`

Добавлен в: v0.7.2

<boolean>

Если процесс Node.js запущен с каналом IPC (см. документацию Процесса дочернего процесса и Кластера), свойство process.connected вернёт true, пока канал IPC подключён и вернёт false после вызова process.disconnect().

После того, как process.connected false, отправлять сообщения по каналу IPC с использованием process.send() больше невозможно.

`process.cpuUsage([previousValue])`

Добавлен в: v6.1.0

previousValue <Object> Предыдущее возвращаемое значение вызова process.cpuUsage()
Возвращает: <Object>
- user <integer>
- system <integer>

Метод process.cpuUsage() возвращает использование процессорного времени пользователя и системы текущим процессом в объекте со свойствами user и system, значения которых представляют собой значения в микросекундах (миллионная доля секунды). Эти значения измеряют время, затраченное в коде пользователя и системы соответственно, и могут оказаться больше фактического времени, если несколько ядер процессора выполняют работу для этого процесса.

Результат предыдущего вызова process.cpuUsage() может быть передан в качестве аргумента функции для получения значения разности.

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

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

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

`process.cwd()`

Добавлен в: v0.1.8

Возвращает: <string>

Метод process.cwd() возвращает текущую рабочую директорию процесса Node.js.

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

`process.debugPort`

Добавлен в: v0.7.2

<number>

Порт, используемый отладчиком Node.js при его включении.

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++ Addons и не должен использоваться напрямую, за исключением особых случаев. Другими словами, require() следует предпочитать process.dlopen(), если нет особых причин.

Аргумент flags — целое число, которое позволяет указать поведение dlopen. Подробнее см. документацию os.constants.dlopen.

Если есть конкретные причины для использования process.dlopen() (например, для указания флагов dlopen), часто бывает полезно использовать require.resolve() для поиска пути к модулю.

Важный недостаток при вызове process.dlopen() заключается в том, что экземпляр module должен быть передан. Функции, экспортируемые C++ Addon, будут доступны через module.exports.

Ниже приведён пример загрузки C++ Addon, названного binding, который экспортирует функцию foo. Все символы будут загружены до возврата вызова, передав константу RTLD_NOW . В этом примере предполагается, что константа доступна.

const os = require('os');
process.dlopen(module, require.resolve('binding'),
               os.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'.

// Emit a warning with a code and additional detail.
process.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

В этом примере объект Error генерируется внутри process.emitWarning() и передаётся обработчику события 'warning'.

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

Добавлен в: v6.0.0

warning <string> | <Error> Предупреждение для вывода.
type <string> Когда warning является String, type — имя, используемое для типа выводимого предупреждения. По умолчанию: 'Warning'.
code <string> Уникальный идентификатор экземпляра предупреждения, который выводится.
ctor <Function> Когда warning является String, ctor — необязательная функция, используемая для ограничения генерируемого трассировки стека. По умолчанию: process.emitWarning.

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

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

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

В каждом из предыдущих примеров объект Error генерируется внутри process.emitWarning() и передаётся обработчику события 'warning'.

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 будут проигнорированы):

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

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

Будет выброшено исключение TypeError, если warning не является строкой или объектом Error.

Хотя предупреждения процесса используют объекты Error, механизм предупреждений процесса не является заменой обычным механизмам обработки ошибок.

Следующая дополнительная обработка реализуется, если предупреждение type является 'DeprecationWarning':

Если используется флаг командной строки --throw-deprecation, предупреждение об устаревании выводится как исключение, а не как событие.
Если используется флаг командной строки --no-deprecation, предупреждение об устаревании подавляется.
Если используется флаг командной строки --trace-deprecation, предупреждение об устаревании выводится в stderr вместе с полным трассировкой стека.

Избегание дублирования предупреждений

В качестве наилучшей практики предупреждения должны выводиться только один раз на процесс. Для этого рекомендуется поместить emitWarning() за простой логический флаг, как показано в примере ниже:

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

`process.env`

История

Версия	Изменения
v11.14.0	Потоки-рабочие будут теперь использовать копию `process.env` родительского потока по умолчанию, настраиваемое через опцию `env` конструктора `Worker`.
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

В то время как следующий сработает:

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

Присваивание свойства process.env неявно преобразует значение в строку. Это поведение устарело. Будущие версии Node.js могут выбросить ошибку, когда значение не является строкой, числом или булевым значением.

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

Используйте delete для удаления свойства из process.env.

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

В операционных системах Windows переменные среды нечувствительны к регистру.

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

Если не указано при создании экземпляра Worker, каждый поток Worker имеет свою собственную копию process.env, основанную на process.env родительского потока или на том, что было указано как опция env конструктора Worker. Изменения в process.env не будут видны в потоках Worker, и только основной поток может вносить изменения, видимые операционной системе или нативным плагинам.

`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']

`process.execPath`

Добавлен в: v0.1.100

<string>

Свойство process.execPath возвращает абсолютный путь к исполняемому файлу, который запустил процесс Node.js. Символические ссылки, если таковые имеются, разрешаются.

'/usr/local/bin/node'

`process.exit([code])`

Добавлен в: v0.1.13

code <integer> Код выхода. По умолчанию: 0.

Метод process.exit() инструктирует Node.js на синхронное завершение процесса со статусом выхода code. Если code опущено, выход использует код «успех» 0 или значение process.exitCode, если оно было установлено. Node.js не завершится, пока не будут вызваны все обработчики события 'exit'.

Для выхода с кодом «ошибка»:

process.exit(1);

Оболочка, которая выполнила Node.js, должна увидеть код выхода как 1.

Вызов process.exit() заставит процесс выйти как можно быстрее, даже если по-прежнему есть ожидающие асинхронные операции, которые не завершены полностью, включая операции ввода-вывода к process.stdout и process.stderr.

В большинстве ситуаций явно вызывать process.exit() не нужно. Процесс Node.js завершится сам по себе, если в цикле событий нет дополнительной работы. Свойство process.exitCode можно задать, чтобы сообщить процессу, какой код выхода использовать при естественном завершении процесса.

Например, следующий пример иллюстрирует неправильное использование метода process.exit(), которое может привести к обрезке и потере данных, напечатанных в stdout:

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

Причина, по которой это проблематично, заключается в том, что записи в process.stdout в Node.js иногда асинхронные и могут происходить за несколько тактов цикла событий Node.js. Вызов process.exit(), однако, заставляет процесс выйти до того, как эти дополнительные записи в stdout смогут быть выполнены.

Вместо прямого вызова process.exit(), код должен установить process.exitCode и позволить процессу выйти естественным путём, избегая планирования дополнительной работы для цикла событий:

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

Добавлена в: v0.11.8

<целое>

Число, которое будет кодом завершения процесса, когда процесс завершается нормально или завершается с помощью process.exit() без указания кода.

Указание кода для process.exit(code) переопределит любое предыдущее значение process.exitCode.

`process.getegid()`

Добавлена в: v2.0.0

Метод process.getegid() возвращает числовое эффективное идентификатор группы процесса Node.js. (См. getegid(2).)

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