Process

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

Объект process предоставляет информацию о текущем процессе Node.js и позволяет управлять им.

ESM

import process from 'node:process';

CJS

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

События 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 с кодом: ', code);
});

process.on('exit', (code) => {
  console.log('Событие Process exit с кодом: ', code);
});

console.log('Это сообщение отображается первым.');

// Выводит:
// Это сообщение отображается первым.
// Событие Process beforeExit с кодом: 0
// Событие Process exit с кодом: 0

CJS

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

process.on('beforeExit', (code) => {
  console.log('Событие Process beforeExit с кодом: ', code);
});

process.on('exit', (code) => {
  console.log('Событие Process exit с кодом: ', code);
});

console.log('Это сообщение отображается первым.');

// Выводит:
// Это сообщение отображается первым.
// Событие Process beforeExit с кодом: 0
// Событие Process exit с кодом: 0

Событие: 'disconnect'

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

Если процесс Node.js запущен с IPC каналом (см. документацию Дочерний процесс и Кластер), событие 'disconnect' будет сгенерировано при закрытии IPC канала.

Событие: 'exit'

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

• code <integer>

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

• Явного вызова метода process.exit();
• Цикл событий Node.js больше не имеет дополнительной работы для выполнения.

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

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

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

Event: 'message'

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

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

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

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

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

Event: 'multipleResolves'

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

Устарело с версии: v17.6.0, v16.15.0

[Stable: 0 - Deprecated]

Stable: 0 Stability: 0 - Устарело

• type <string> — тип разрешения. Один из 'resolve' или 'reject'.
• promise <Promise> — промис, который разрешился или был отклонен более одного раза.
• value <any> — значение, с которым промис был либо разрешен, либо отклонен после первоначального разрешения.

Событие '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> Обработанный с задержкой промис.

Событие 'rejectionHandled' возникает, когда Promise был отклонен, и к нему был прикреплен обработчик ошибок (например, с использованием promise.catch()) позже, чем через один проход цикла событий Node.js.

Объект Promise ранее был бы сгенерирован в событии 'unhandledRejection', но в процессе обработки получил обработчик отклонения.

Не существует понятия верхнего уровня для цепочки Promise, на котором всегда можно обработать отклонения. Будучи по своей сути асинхронным по своей природе, отклонение Promise может быть обработано в будущем, возможно, намного позже, чем проход цикла событий, необходимый для создания события 'unhandledRejection'.

Другой способ сформулировать это заключается в том, что, в отличие от синхронного кода, где существует постоянно растущий список необработанных исключений, в Promises может быть растущий и сокращающийся список необработанных отклонений.

В синхронном коде событие '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);
});

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

Событие: 'workerMessage'

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

• value <any> Значение, переданное с использованием postMessageToThread().
• source <number> Идентификатор передающего рабочего потока или 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' переопределяет это поведение по умолчанию. В качестве альтернативы, измените process.exitCode в обработчике 'uncaughtException', что приведет к завершению процесса с указанным кодом выхода. В противном случае, при наличии такого обработчика процесс завершится с кодом 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.');

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

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

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

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

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

Правильное использование '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);
});

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

CJS

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

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

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

Событие: '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 отклоняется и к promise не прикреплен обработчик ошибок в течение одного витка цикла событий. При программировании с использованием Promises исключения инкапсулируются в виде "отклоненных promises". Отклонения можно перехватывать и обрабатывать с помощью promise.catch() и они распространяются по цепочке Promise. Событие 'unhandledRejection' полезно для обнаружения и отслеживания promises, которые были отклонены, но отклонения которых еще не были обработаны.

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();
// нет .catch или .then на resource.loaded как минимум один виток

CJS

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

function SomeResource() {
  // Изначально устанавливаем статус загрузки в отклоненный promise
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'));
}

const resource = new SomeResource();
// нет .catch или .then на resource.loaded как минимум один виток

В этом примере можно отследить отклонение как ошибку разработчика, как это обычно бывает для других событий 'unhandledRejection'. Чтобы устранить такие сбои, к resource.loaded можно прикрепить нерабочий обработчик .catch(() =\> { }), что предотвратит испускание события '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 можно использовать для того, чтобы вывод в консоль по умолчанию для предупреждений включал полную трассировку стека предупреждения.

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

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

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

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

Вывод пользовательских предупреждений

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

Имена предупреждений Node.js

Не существует строгих правил для типов предупреждений (как определено свойством name), выдаваемых Node.js. Новые типы предупреждений могут быть добавлены в любое время. Вот несколько наиболее распространенных типов предупреждений:

• 'DeprecationWarning' - Указывает на использование устаревшего API или функции Node.js. Такие предупреждения должны включать свойство 'code', определяющее код устаревания.
• 'ExperimentalWarning' - Указывает на использование экспериментального API или функции Node.js. Такие функции следует использовать с осторожностью, поскольку они могут измениться в любое время и не подпадают под действие тех же строгих правил семантического версионирования и долгосрочной поддержки, что и поддерживаемые функции.
• 'MaxListenersExceededWarning' - Указывает на то, что на EventEmitter или EventTarget зарегистрировано слишком много слушателей для данного события. Часто это является признаком утечки памяти.
• 'TimeoutOverflowWarning' - Указывает на то, что числовое значение, которое не помещается в 32-разрядное целое число со знаком, было передано функциям setTimeout() или setInterval().
• 'TimeoutNegativeWarning' - Указывает на то, что отрицательное число было передано функциям setTimeout() или setInterval().
• 'TimeoutNaNWarning' - Указывает на то, что значение, не являющееся числом, было передано функциям setTimeout() или setInterval().
• 'UnsupportedWarning' - Указывает на использование неподдерживаемой опции или функции, которая будет проигнорирована, а не обработана как ошибка. Одним из примеров является использование сообщения о состоянии HTTP-ответа при использовании API совместимости HTTP/2.

Событие: 'worker'

Добавлено в: v16.2.0, v14.18.0

• worker <Worker> Созданный <Worker>.

Событие 'worker' генерируется после создания нового потока <Worker>.

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

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

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

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

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

ESM

import process from 'node:process';

// Начинаем чтение из stdin, чтобы процесс не завершался.
process.stdin.resume();

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

// Использование одной функции для обработки нескольких сигналов
function handle(signal) {
  console.log(`Received ${signal}`);
}

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

CJS

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

// Начинаем чтение из stdin, чтобы процесс не завершался.
process.stdin.resume();

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

// Использование одной функции для обработки нескольких сигналов
function handle(signal) {
  console.log(`Received ${signal}`);
}

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

• 'SIGUSR1' зарезервирован Node.js для запуска отладчика. Можно установить слушатель, но это может помешать работе отладчика.
• 'SIGTERM' и 'SIGINT' имеют обработчики по умолчанию на платформах, отличных от Windows, которые сбрасывают режим терминала перед выходом с кодом 128 + номер сигнала. Если на один из этих сигналов установлен слушатель, его поведение по умолчанию будет удалено (Node.js больше не будет завершаться).
• 'SIGPIPE' игнорируется по умолчанию. На него можно установить слушатель.
• 'SIGHUP' генерируется в Windows при закрытии окна консоли, а на других платформах при различных аналогичных условиях. Смотрите signal(7). На него можно установить слушатель, однако Node.js будет безусловно завершен Windows примерно через 10 секунд. На платформах, отличных от Windows, поведение SIGHUP по умолчанию заключается в завершении Node.js, но как только слушатель будет установлен, его поведение по умолчанию будет удалено.
• 'SIGTERM' не поддерживается в Windows, но его можно прослушивать.
• 'SIGINT' из терминала поддерживается на всех платформах и обычно может быть сгенерирован с помощью + (хотя это может быть настроено). Он не генерируется, когда включен режим необработанного терминала и используется +.
• 'SIGBREAK' доставляется в Windows при нажатии +. На платформах, отличных от Windows, его можно прослушивать, но нет возможности отправить или сгенерировать его.
• 'SIGWINCH' доставляется при изменении размера консоли. В Windows это произойдет только при записи в консоль при перемещении курсора или при использовании читаемого 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 является специальным 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, будут содержать подчеркивания вместо неначальных дефисов:

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
  // ...
});

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

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

process.arch

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

• <string>

Архитектура процессора операционной системы, для которой был скомпилирован бинарник Node.js. Возможные значения: '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. См. process.argv0, если требуется доступ к исходному значению argv[0]. Вторым элементом будет путь к выполняемому файлу JavaScript. Остальные элементы будут любыми дополнительными аргументами командной строки.

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

ESM

import { argv } from 'node:process';

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

CJS

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

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

Запуск процесса Node.js как:

node process-args.js one two=three four

Сгенерирует вывод:

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

process.argv0

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

• <string>

Свойство process.argv0 хранит копию только для чтения исходного значения 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

[История]

Версия	Изменения
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

Этот метод заставляет IPC-канал поддерживать работу цикла событий процесса, если до этого был вызван метод .unref().

Обычно это управляется количеством прослушивателей событий 'disconnect' и 'message' на объекте process. Однако этот метод можно использовать для явного запроса определенного поведения.

process.channel.unref()

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

Этот метод делает так, чтобы IPC-канал не поддерживал работу цикла событий процесса и позволял ему завершиться, даже когда канал открыт.

Обычно это управляется количеством прослушивателей событий 'disconnect' и 'message' на объекте process. Однако этот метод можно использовать для явного запроса определенного поведения.

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 возвращает замороженный 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_openssl: 'true',
     node_shared_openssl: 'false',
     target_arch: 'x64',
     v8_use_snapshot: 1
   }
}

process.connected

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

• <boolean>

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

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

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>

Возвращает объем памяти, доступный процессу (в байтах), в зависимости от ограничений, наложенных операционной системой. Если такого ограничения нет или ограничение неизвестно, возвращается 0.

См. uv_get_constrained_memory для получения дополнительной информации.

process.availableMemory()

Добавлено в: v22.0.0, v20.13.0

[Stable: 1 - Experimental]

Stable: 1 Стабильность: 1 - Экспериментально

• <number>

Получает объем свободной памяти, который все еще доступен для процесса (в байтах).

Смотрите uv_get_available_memory для получения дополнительной информации.

process.cpuUsage([previousValue])

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

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

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

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

ESM

import { cpuUsage } from 'node:process';

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

// загружаем процессор на 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 }

// загружаем процессор на 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(`Текущий каталог: ${cwd()}`);

CJS

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

console.log(`Текущий каталог: ${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++, и его не следует использовать напрямую, за исключением особых случаев. Другими словами, require() следует предпочитать process.dlopen(), если нет особых причин, таких как пользовательские флаги dlopen или загрузка из модулей ES.

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

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

В приведенном ниже примере показано, как загрузить дополнение C++, с именем local.node, которое экспортирует функцию foo. Все символы загружаются до возврата вызова, путем передачи константы 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, то type - это имя, которое будет использоваться для типа выдаваемого предупреждения. По умолчанию: 'Warning'.
  • code <string> Уникальный идентификатор для экземпляра выдаваемого предупреждения.
  • ctor <Function> Если warning является String, то ctor - это необязательная функция, используемая для ограничения создаваемой трассировки стека. По умолчанию: process.emitWarning.
  • detail <string> Дополнительный текст для включения в ошибку.

Метод process.emitWarning() можно использовать для генерации пользовательских или специфичных для приложения предупреждений процесса. Их можно прослушивать, добавив обработчик для события 'warning'.

ESM

import { emitWarning } from 'node:process';

// Выдать предупреждение с кодом и дополнительной информацией.
emitWarning('Что-то случилось!', {
  code: 'MY_WARNING',
  detail: 'Это дополнительная информация',
});
// Выводит:
// (node:56338) [MY_WARNING] Warning: Что-то случилось!
// Это дополнительная информация

CJS

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

// Выдать предупреждение с кодом и дополнительной информацией.
emitWarning('Что-то случилось!', {
  code: 'MY_WARNING',
  detail: 'Это дополнительная информация',
});
// Выводит:
// (node:56338) [MY_WARNING] Warning: Что-то случилось!
// Это дополнительная информация

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

ESM

import process from 'node:process';

process.on('warning', (warning) => {
  console.warn(warning.name);    // 'Warning'
  console.warn(warning.message); // 'Что-то случилось!'
  console.warn(warning.code);    // 'MY_WARNING'
  console.warn(warning.stack);   // Трассировка стека
  console.warn(warning.detail);  // 'Это дополнительная информация'
});

CJS

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

process.on('warning', (warning) => {
  console.warn(warning.name);    // 'Warning'
  console.warn(warning.message); // 'Что-то случилось!'
  console.warn(warning.code);    // 'MY_WARNING'
  console.warn(warning.stack);   // Трассировка стека
  console.warn(warning.detail);  // 'Это дополнительная информация'
});

Если 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.

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

ESM

import { emitWarning } from 'node:process';

// Выдача предупреждения с использованием строки.
emitWarning('Что-то случилось!');
// Выводит: (node: 56338) Warning: Что-то случилось!

CJS

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

// Выдача предупреждения с использованием строки.
emitWarning('Что-то случилось!');
// Выводит: (node: 56338) Warning: Что-то случилось!

ESM

import { emitWarning } from 'node:process';

// Выдача предупреждения с использованием строки и типа.
emitWarning('Что-то случилось!', 'CustomWarning');
// Выводит: (node:56338) CustomWarning: Что-то случилось!

CJS

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

// Выдача предупреждения с использованием строки и типа.
emitWarning('Что-то случилось!', 'CustomWarning');
// Выводит: (node:56338) CustomWarning: Что-то случилось!

ESM

import { emitWarning } from 'node:process';

emitWarning('Что-то случилось!', 'CustomWarning', 'WARN001');
// Выводит: (node:56338) [WARN001] CustomWarning: Что-то случилось!

CJS

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

process.emitWarning('Что-то случилось!', 'CustomWarning', 'WARN001');
// Выводит: (node:56338) [WARN001] CustomWarning: Что-то случилось!

В каждом из предыдущих примеров объект Error генерируется внутри process.emitWarning() и передается через обработчик '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('Что-то случилось!');
// Используйте свойство name Error для указания имени типа
myWarning.name = 'CustomWarning';
myWarning.code = 'WARN001';

emitWarning(myWarning);
// Выводит: (node:56338) [WARN001] CustomWarning: Что-то случилось!

CJS

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

// Выдача предупреждения с использованием объекта Error.
const myWarning = new Error('Что-то случилось!');
// Используйте свойство name Error для указания имени типа
myWarning.name = 'CustomWarning';
myWarning.code = 'WARN001';

emitWarning(myWarning);
// Выводит: (node:56338) [WARN001] CustomWarning: Что-то случилось!

TypeError выдается, если warning является чем-либо иным, кроме строки или объекта Error.

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

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

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

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

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

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

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'

Используйте delete, чтобы удалить свойство из process.env.

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

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 constructor.

process.execPath

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

• <string>

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

'/usr/local/bin/node'

process.exit([code])

[История]

Версия	Изменения
v20.0.0	Принимает только код типа number или типа string, если он представляет собой целое число.
v0.1.13	Добавлено в: v0.1.13

• code <integer> | <string> | <null> | <undefined> Код выхода. Для типа string допускаются только целочисленные строки (например, '1'). По умолчанию: 0.

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

Чтобы выйти с кодом 'failure':

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.

В большинстве ситуаций на самом деле нет необходимости явно вызывать 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);
}

Проблема в том, что запись в process.stdout в Node.js иногда асинхронна и может происходить в течение нескольких тактов цикла событий 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	Принимает только код типа number или типа string, если он представляет собой целое число.
v0.11.8	Добавлено в: v0.11.8

• <integer> | <string> | <null> | <undefined> Код выхода. Для строкового типа разрешены только строковые представления целых чисел (например, "1"). По умолчанию: undefined.

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

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

process.features.cached_builtins

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

• <boolean>

Логическое значение, которое равно true, если текущая сборка Node.js кэширует встроенные модули.

process.features.debug

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

• <boolean>

Логическое значение, которое равно true, если текущая сборка Node.js является отладочной сборкой.

process.features.inspector

Добавлено в: v11.10.0

• <boolean>

Логическое значение, которое равно true, если текущая сборка Node.js включает инспектор.

process.features.ipv6

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

Устарело с версии: v23.4.0

[Стабильность: 0 - Устарело]

Стабильность: 0 Стабильность: 0 - Устарело. Это свойство всегда true, и любые проверки, основанные на нем, избыточны.

• <boolean>

Логическое значение, которое равно true, если текущая сборка Node.js включает поддержку IPv6.

Поскольку все сборки Node.js имеют поддержку IPv6, это значение всегда равно true.

process.features.require_module

Добавлено в версии: v23.0.0

• <boolean>

Логическое значение true, если текущая сборка Node.js поддерживает загрузку модулей ECMAScript с использованием require().

process.features.tls

Добавлено в версии: v0.5.3

• <boolean>

Логическое значение true, если текущая сборка Node.js включает поддержку TLS.

process.features.tls_alpn

Добавлено в версии: v4.8.0

Устарело с версии: v23.4.0

[Стабильность: 0 - Устарело]

Стабильность: 0 Стабильность: 0 - Устарело. Вместо этого используйте process.features.tls.

• <boolean>

Логическое значение true, если текущая сборка Node.js включает поддержку ALPN в TLS.

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

Логическое значение true, если текущая сборка Node.js включает поддержку OCSP в TLS.

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

Логическое значение true, если текущая сборка Node.js включает поддержку SNI в TLS.

В Node.js 11.0.0 и более поздних версиях зависимости OpenSSL обеспечивают безусловную поддержку SNI. Поэтому это значение идентично значению process.features.tls.

process.features.typescript

Добавлено в версии: v23.0.0

[Стабильность: 1 - Экспериментальный]

Стабильность: 1 Стабильность: 1.1 - Активная разработка

• <boolean> | <string>

Значение "strip", если Node.js запущен с --experimental-strip-types, "transform", если Node.js запущен с --experimental-transform-types, и false в противном случае.

process.features.uv

Добавлено в версии: v0.5.3

Устарело с версии: v23.4.0

[Стабильность: 0 - Устаревший]

Стабильность: 0 Стабильность: 0 - Устаревший. Это свойство всегда true, и любые проверки, основанные на нем, избыточны.

• <boolean>

Булево значение, равное true, если текущая сборка Node.js включает поддержку libuv.

Поскольку невозможно построить Node.js без libuv, это значение всегда равно true.

process.finalization.register(ref, callback)

Добавлено в версии: v22.5.0

[Стабильность: 1 - Экспериментальный]

Стабильность: 1 Стабильность: 1.1 - Активная разработка

• ref <Object> | <Function> Ссылка на отслеживаемый ресурс.
• callback <Function> Функция обратного вызова, которая будет вызвана при завершении ресурса.
  • ref <Object> | <Function> Ссылка на отслеживаемый ресурс.
  • event <string> Событие, вызвавшее завершение. По умолчанию 'exit'.

Эта функция регистрирует обратный вызов, который будет вызван при возникновении события exit процесса, если объект ref не был собран сборщиком мусора. Если объект ref был собран сборщиком мусора до возникновения события exit, обратный вызов будет удален из реестра финализации и не будет вызван при выходе из процесса.

Внутри обратного вызова вы можете освободить ресурсы, выделенные объектом ref. Имейте в виду, что все ограничения, применяемые к событию beforeExit, также применяются к функции callback, это означает, что существует вероятность того, что обратный вызов не будет вызван при особых обстоятельствах.

Идея этой функции состоит в том, чтобы помочь вам освободить ресурсы, когда процесс начинает завершаться, но также позволить объекту быть собранным сборщиком мусора, если он больше не используется.

Например: вы можете зарегистрировать объект, содержащий буфер, вы хотите убедиться, что буфер освобождается при выходе из процесса, но если объект собран сборщиком мусора до выхода из процесса, нам больше не нужно освобождать буфер, поэтому в этом случае мы просто удаляем обратный вызов из реестра финализации.

CJS

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

// Убедитесь, что функция, переданная в finalization.register(),
// не создает замыкание вокруг ненужных объектов.
function onFinalize(obj, event) {
  // Вы можете делать все, что захотите с объектом
  obj.dispose();
}

function setup() {
  // Этот объект можно безопасно собрать сборщиком мусора,
  // и результирующая функция завершения работы не будет вызвана.
  // Утечек нет.
  const myDisposableObject = {
    dispose() {
      // Освободите свои ресурсы синхронно
    },
  };

  finalization.register(myDisposableObject, onFinalize);
}

setup();

ESM

import { finalization } from 'node:process';

// Убедитесь, что функция, переданная в finalization.register(),
// не создает замыкание вокруг ненужных объектов.
function onFinalize(obj, event) {
  // Вы можете делать все, что захотите с объектом
  obj.dispose();
}

function setup() {
  // Этот объект можно безопасно собрать сборщиком мусора,
  // и результирующая функция завершения работы не будет вызвана.
  // Утечек нет.
  const myDisposableObject = {
    dispose() {
      // Освободите свои ресурсы синхронно
    },
  };

  finalization.register(myDisposableObject, onFinalize);
}

setup();

Приведенный выше код основан на следующих предположениях:

• стрелочные функции избегаются
• обычные функции рекомендуется размещать в глобальном контексте (root)

Обычные функции могут ссылаться на контекст, в котором живет obj, делая obj не подлежащим сборке мусора.

Стрелочные функции будут удерживать предыдущий контекст. Рассмотрим, например:

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

    // Даже что-то вроде этого крайне не рекомендуется
    // finalization.register(this, () => this.dispose());
  }
  dispose() {}
}

Очень маловероятно (но не невозможно), что этот объект будет собран сборщиком мусора, но если это не так, dispose будет вызван при вызове process.exit.

Будьте осторожны и не полагайтесь на эту функцию для утилизации критических ресурсов, так как нет гарантии, что обратный вызов будет вызван при всех обстоятельствах.

process.finalization.registerBeforeExit(ref, callback)

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

[Стабильность: 1 - Экспериментально]

Стабильность: 1 Стабильность: 1.1 - Активная разработка

• ref <Object> | <Function> Ссылка на отслеживаемый ресурс.
• callback <Function> Функция обратного вызова, которая будет вызвана при финализации ресурса.
  • ref <Object> | <Function> Ссылка на отслеживаемый ресурс.
  • event <string> Событие, которое вызвало финализацию. По умолчанию 'beforeExit'.

Эта функция ведет себя точно так же, как register, за исключением того, что обратный вызов будет вызван, когда процесс испустит событие beforeExit, если объект ref не был собран сборщиком мусора.

Имейте в виду, что все ограничения, применяемые к событию beforeExit, также применяются к функции callback, это означает, что существует вероятность того, что обратный вызов не будет вызван при особых обстоятельствах.

process.finalization.unregister(ref)

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

[Стабильность: 1 - Экспериментально]

Стабильность: 1 Стабильность: 1.1 - Активная разработка

• ref <Object> | <Function> Ссылка на ресурс, который был зарегистрирован ранее.

Эта функция удаляет регистрацию объекта из реестра финализации, поэтому обратный вызов больше не будет вызываться.

CJS

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

// Пожалуйста, убедитесь, что функция, переданная в finalization.register(),
// не создает замыкание вокруг ненужных объектов.
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';

// Пожалуйста, убедитесь, что функция, переданная в finalization.register(),
// не создает замыкание вокруг ненужных объектов.
function onFinalize(obj, event) {
  // Вы можете делать все, что хотите с объектом
  obj.dispose();
}

function setup() {
  // Этот объект может быть безопасно собран сборщиком мусора,
  // и результирующая функция завершения работы не будет вызвана.
  // Утечек нет.
  const myDisposableObject = {
    dispose() {
      // Освободите свои ресурсы синхронно
    },
  };

  // Пожалуйста, убедитесь, что функция, переданная в finalization.register(),
  // не создает замыкание вокруг ненужных объектов.
  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 Modules, которые должны поддерживать другие среды, могут использовать его для условной загрузки встроенного модуля Node.js при запуске в Node.js, без необходимости обрабатывать ошибку разрешения, которая может быть выдана import в среде, отличной от Node.js, или использовать динамический import(), который либо превращает модуль в асинхронный модуль, либо превращает синхронный API в асинхронный.

if (globalThis.process?.getBuiltinModule) {
  // Запуск в Node.js, использование модуля fs Node.js.
  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). Некоторые встроенные модули должны быть загружены с префиксом node:, см. встроенные модули с обязательным префиксом node:. Ссылки, возвращаемые process.getBuiltinModule(id), всегда указывают на встроенный модуль, соответствующий id, даже если пользователи изменят require.cache так, что require(id) вернет что-то другое.

process.getegid()

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

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

ESM

import process from 'node:process';

if (process.getegid) {
  console.log(`Текущий gid: ${process.getegid()}`);
}

CJS

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

if (process.getegid) {
  console.log(`Текущий gid: ${process.getegid()}`);
}

Эта функция доступна только на платформах POSIX (т.е. не Windows или Android).

process.geteuid()

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

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

Метод process.geteuid() возвращает числовой эффективный идентификатор пользователя процесса. (См. geteuid(2).)

ESM

import process from 'node:process';

if (process.geteuid) {
  console.log(`Текущий uid: ${process.geteuid()}`);
}

CJS

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

if (process.geteuid) {
  console.log(`Текущий uid: ${process.geteuid()}`);
}

Эта функция доступна только на платформах POSIX (т.е. не Windows или Android).

process.getgid()

Добавлено в версии: v0.1.31

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

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

ESM

import process from 'node:process';

if (process.getgid) {
  console.log(`Текущий gid: ${process.getgid()}`);
}

CJS

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

if (process.getgid) {
  console.log(`Текущий gid: ${process.getgid()}`);
}

Эта функция доступна только на платформах POSIX (т.е. не Windows или Android).

process.getgroups()

Добавлено в версии: v0.9.4

• Возвращает: <integer[]>

Метод process.getgroups() возвращает массив с дополнительными идентификаторами групп. POSIX не определяет, включен ли эффективный идентификатор группы, но 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() возвращает числовой идентификатор пользователя процесса. (См. getuid(2).)

ESM

import process from 'node:process';

if (process.getuid) {
  console.log(`Текущий uid: ${process.getuid()}`);
}

CJS

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

if (process.getuid) {
  console.log(`Текущий uid: ${process.getuid()}`);
}

Эта функция доступна только на платформах POSIX (т.е. не Windows или Android).

process.hasUncaughtExceptionCaptureCallback()

Добавлено в: v9.3.0

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

Указывает, была ли установлена обратная связь с использованием process.setUncaughtExceptionCaptureCallback().

process.hrtime([time])

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

[Стабильно: 3 - Устаревшее]

Стабильно: 3 Стабильность: 3 - Устаревшее. Используйте process.hrtime.bigint() вместо этого.

• time <integer[]> Результат предыдущего вызова process.hrtime()
• Возвращает: <integer[]>

Это устаревшая версия process.hrtime.bigint() до того, как bigint был представлен в JavaScript.

Метод process.hrtime() возвращает текущее реальное время высокого разрешения в виде кортежа [seconds, nanoseconds] Array, где nanoseconds - это оставшаяся часть реального времени, которое нельзя представить с точностью до секунды.

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(`Бенчмарк занял ${diff[0] * NS_PER_SEC + diff[1]} наносекунд`);
  // Бенчмарк занял 1000000552 наносекунд
}, 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(`Бенчмарк занял ${diff[0] * NS_PER_SEC + diff[1]} наносекунд`);
  // Бенчмарк занял 1000000552 наносекунд
}, 1000);

process.hrtime.bigint()

Added in: v10.7.0

• Returns: <bigint>

bigint версия метода process.hrtime(), возвращающая текущее реальное время с высоким разрешением в наносекундах в виде bigint.

В отличие от process.hrtime(), он не поддерживает дополнительный аргумент time, поскольку разницу можно вычислить непосредственно вычитанием двух 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)

Added in: 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);     // switch user
console.log(getgroups());         // [ 27, 30, 46, 1000, 0 ]
setgid(1000);                     // drop root gid
console.log(getgroups());         // [ 27, 30, 46, 1000 ]

CJS

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

console.log(getgroups());         // [ 0 ]
initgroups('nodeuser', 1000);     // switch user
console.log(getgroups());         // [ 27, 30, 46, 1000, 0 ]
setgid(1000);                     // drop root gid
console.log(getgroups());         // [ 27, 30, 46, 1000 ]

Эта функция доступна только на платформах POSIX (т.е. не Windows или Android). Эта функция недоступна в потоках Worker.

process.kill(pid[, signal])

Добавлено в версии: v0.0.6

• pid <number> Идентификатор процесса
• signal <string> | <number> Сигнал для отправки, либо в виде строки, либо числа. По умолчанию: 'SIGTERM'.

Метод process.kill() отправляет signal процессу, идентифицированному по pid.

Имена сигналов - это строки, такие как 'SIGINT' или 'SIGHUP'. Смотрите События сигналов и kill(2) для получения дополнительной информации.

Этот метод выдаст ошибку, если целевой pid не существует. В качестве особого случая, сигнал 0 может быть использован для проверки существования процесса. Платформы Windows выдадут ошибку, если pid используется для завершения группы процессов.

Несмотря на то, что имя этой функции process.kill(), на самом деле это всего лишь отправитель сигналов, как системный вызов kill. Отправленный сигнал может сделать что-то отличное от завершения целевого процесса.

ESM

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

process.on('SIGHUP', () => {
  console.log('Получен сигнал SIGHUP.');
});

setTimeout(() => {
  console.log('Выход.');
  process.exit(0);
}, 100);

kill(process.pid, 'SIGHUP');

CJS

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

process.on('SIGHUP', () => {
  console.log('Получен сигнал SIGHUP.');
});

setTimeout(() => {
  console.log('Выход.');
  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. Использование NODE_OPTIONS в файле .env не повлияет на Node.js.

CJS

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

ESM

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

process.mainModule

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

Устарело с версии: v14.0.0

[Stable: 0 - Deprecated]

Stable: 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());
// Prints:
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }

CJS

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

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

• heapTotal и heapUsed относятся к использованию памяти V8.
• external относится к использованию памяти C++ объектами, привязанными к JavaScript объектам, управляемым V8.
• rss, Resident Set Size (размер резидентного набора), — это объем пространства, занимаемого в основной памяти (то есть подмножество общего объема выделенной памяти) для процесса, включая все C++ и JavaScript объекты и код.
• arrayBuffers относится к памяти, выделенной для ArrayBuffer и SharedArrayBuffer, включая все Node.js Buffer. Это также включено в значение external. Если Node.js используется как встроенная библиотека, это значение может быть 0, поскольку выделения для ArrayBuffer могут не отслеживаться в этом случае.

При использовании Worker потоков, rss будет значением, действительным для всего процесса, в то время как другие поля будут относиться только к текущему потоку.

Метод process.memoryUsage() перебирает каждую страницу, чтобы собрать информацию об использовании памяти, что может быть медленным в зависимости от распределения памяти программой.

process.memoryUsage.rss()

Добавлено в версии: v15.6.0, v14.18.0

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

Метод process.memoryUsage.rss() возвращает целое число, представляющее размер Resident Set Size (RSS) в байтах.

Resident Set Size - это объем пространства, занятого в основной памяти (то есть подмножество общего объема выделенной памяти) для процесса, включая все объекты и код C++ и JavaScript.

Это то же значение, что и свойство rss, предоставляемое process.memoryUsage(), но 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	Изменена стабильность на Legacy.
v18.0.0	Передача недопустимой функции обратного вызова в аргумент callback теперь вызывает ERR_INVALID_ARG_TYPE вместо ERR_INVALID_CALLBACK.
v1.8.1	Теперь поддерживаются дополнительные аргументы после callback.
v0.1.26	Добавлено в версии: v0.1.26

[Stable: 3 - Legacy]

Stable: 3 Стабильность: 3 - Legacy: Вместо этого используйте queueMicrotask().

• callback <Function>
• ...args <any> Дополнительные аргументы для передачи при вызове callback

process.nextTick() добавляет callback в "очередь next tick". Эта очередь полностью опустошается после завершения текущей операции в стеке JavaScript и до того, как event loop сможет продолжиться. Можно создать бесконечный цикл, если рекурсивно вызывать process.nextTick(). См. руководство Event Loop для получения дополнительной информации.

ESM

import { nextTick } from 'node:process';

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

CJS

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

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

Это важно при разработке 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()

API queueMicrotask() является альтернативой process.nextTick(), который также откладывает выполнение функции, используя ту же очередь микрозадач, которая используется для выполнения обработчиков then, catch и finally разрешенных промисов. В Node.js, каждый раз, когда "очередь следующего такта" опустошается, очередь микрозадач опустошается сразу после этого.

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

Для большинства пользовательских случаев API queueMicrotask() предоставляет переносимый и надежный механизм для отложенного выполнения, который работает в различных средах JavaScript платформ и которому следует отдавать предпочтение перед process.nextTick(). В простых сценариях queueMicrotask() может быть прямой заменой для process.nextTick().

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

Одним из заметных различий между двумя API является то, что 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

Существуют незначительные различия в способах обработки ошибок, возникающих в очереди следующего такта и в очереди микрозадач. Ошибки, возникающие в обратном вызове поставленной в очередь микрозадачи, должны быть обработаны внутри обратного вызова, если это возможно. Если это не так, обработчик событий process.on('uncaughtException') можно использовать для перехвата и обработки ошибок.

В случае сомнений, если не требуются конкретные возможности process.nextTick(), используйте queueMicrotask().

process.noDeprecation

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

• <boolean>

Свойство process.noDeprecation указывает, установлен ли флаг --no-deprecation для текущего процесса Node.js. Дополнительную информацию о поведении этого флага см. в документации для 'warning' event и emitWarning() method.

process.permission

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

• <Object>

Этот API доступен через флаг --permission.

process.permission - это объект, методы которого используются для управления разрешениями для текущего процесса. Дополнительная документация доступна в Permission Model.

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.md
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(`Этот процесс имеет pid ${pid}`);

CJS

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

console.log(`Этот процесс имеет pid ${pid}`);

process.platform

Добавлено в версии: v0.1.16

• <string>

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

В настоящее время возможные значения:

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

ESM

import { platform } from 'node:process';

console.log(`Эта платформа ${platform}`);

CJS

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

console.log(`Эта платформа ${platform}`);

Значение 'android' также может быть возвращено, если Node.js построен на операционной системе Android. Однако поддержка Android в Node.js является экспериментальной.

process.ppid

Добавлено в версии: v9.2.0, v8.10.0, v6.13.0

• <integer>

Свойство process.ppid возвращает PID родительского процесса текущего процесса.

ESM

import { ppid } from 'node:process';

console.log(`Родительский процесс имеет pid ${ppid}`);

CJS

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

console.log(`Родительский процесс имеет 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> абсолютный URL, указывающий на файл .tar.gz, содержащий исходный код текущего релиза.
• headersUrl<string> абсолютный URL, указывающий на файл .tar.gz, содержащий только исходные файлы заголовков для текущего релиза. Этот файл значительно меньше, чем полный исходный файл, и может использоваться для компиляции собственных дополнений Node.js.
• libUrl <string> | <undefined> абсолютный URL, указывающий на файл node.lib, соответствующий архитектуре и версии текущего релиза. Этот файл используется для компиляции собственных дополнений Node.js. Это свойство присутствует только в Windows-сборках Node.js и отсутствует на всех других платформах.
• lts <string> | <undefined> строковая метка, идентифицирующая метку LTS для этого релиза. Это свойство существует только для LTS-релизов и является undefined для всех других типов релизов, включая Current-релизы. Допустимые значения включают кодовые имена LTS Release (включая те, которые больше не поддерживаются).
  • 'Fermium' для линейки 14.x LTS, начиная с 14.15.0.
  • 'Gallium' для линейки 16.x LTS, начиная с 16.13.0.
  • 'Hydrogen' для линейки 18.x LTS, начиная с 18.12.0. Другие кодовые имена LTS Release см. в Архиве журнала изменений Node.js

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

Записывает отчеты в компактном формате, в виде однострочного 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 Object представление диагностического отчета для запущенного процесса. Трассировка стека 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.reportOnFatalError}`);

CJS

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

console.log(`Отчет о фатальной ошибке: ${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.reportOnSignal}`);

CJS

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

console.log(`Отчет по сигналу: ${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.reportOnUncaughtException}`);

CJS

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

console.log(`Отчет по исключению: ${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}`);

CJS

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

console.log(`Сигнал отчета: ${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_getrusage, который возвращает uv_rusage_t struct.
  • 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> соответствует ru_nvcsw, которое является количеством переключений контекста ЦП, произошедших из-за того, что процесс добровольно отказался от процессора до завершения своего временного среза (обычно для ожидания доступности ресурса). Это поле не поддерживается в Windows.
  • involuntaryContextSwitches <integer> соответствует ru_nivcsw, которое является количеством переключений контекста ЦП, произошедших из-за того, что процесс с более высоким приоритетом стал исполняемым, или из-за того, что текущий процесс превысил свой временной срез. Это поле не поддерживается в Windows.

ESM

import { resourceUsage } from 'node:process';

console.log(resourceUsage());
/*
  Will output:
  {
    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());
/*
  Will output:
  {
    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])

Added in: 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() может быть использован для отправки сообщений родительскому процессу. Сообщения будут получены как событие 'message' в объекте ChildProcess родительского процесса.

Если Node.js не был запущен с использованием IPC-канала, process.send будет undefined.

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

process.setegid(id)

Added in: v2.0.0

• id <string> | <number> Имя группы или ID

Метод process.setegid() устанавливает эффективный групповой идентификатор процесса. (См. 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)

Added in: v2.0.0

• id <string> | <number> Имя пользователя или ID

Метод process.seteuid() устанавливает эффективный идентификатор пользователя процесса. (См. 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)

Added in: v0.1.31

• id <string> | <number> Имя группы или ID

Метод process.setgid() устанавливает идентификатор группы процесса. (См. 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)

Added in: v0.9.4

• groups <integer[]>

Метод process.setgroups() устанавливает дополнительные идентификаторы групп для процесса Node.js. Это привилегированная операция, требующая наличия у процесса Node.js прав root или возможности CAP_SETGID.

Массив groups может содержать числовые идентификаторы групп, имена групп или и то, и другое.

ESM

import process from 'node:process';

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501]);
    console.log(process.getgroups()); // new groups
  } 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()); // new groups
  } catch (err) {
    console.error(`Failed to set groups: ${err}`);
  }
}

Эта функция доступна только на POSIX-платформах (т.е. не в Windows или Android). Эта функция недоступна в потоках Worker.

process.setuid(id)

Added in: v0.1.28

• id <integer> | <string>

Метод process.setuid(id) устанавливает идентификатор пользователя процесса. (См. setuid(2).) 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

[Stable: 1 - Experimental]

Stable: 1 Stability: 1 - Экспериментально

• val <boolean>

Эта функция включает или отключает поддержку Source Map v3 для трассировок стека.

Она предоставляет те же возможности, что и запуск процесса Node.js с параметрами командной строки --enable-source-maps.

Только source map в файлах JavaScript, которые загружаются после включения source map, будут проанализированы и загружены.

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

[Stable: 1 - Experimental]

Stable: 1 Stability: 1 - Экспериментально

• <boolean>

Свойство process.sourceMapsEnabled возвращает, включена ли поддержка Source Map v3 для трассировок стека.

process.stderr

• <Stream>

Свойство process.stderr возвращает поток, подключенный к stderr (fd 2). Это net.Socket (который является потоком Duplex), если fd 2 не ссылается на файл, в этом случае это поток Writable.

process.stderr отличается от других потоков Node.js важными особенностями. Подробнее см. в примечании о вводе-выводе процесса.

process.stderr.fd

• <number>

Это свойство относится к значению базового файлового дескриптора process.stderr. Значение фиксировано на 2. В потоках Worker это поле не существует.

process.stdin

• <Stream>

Свойство process.stdin возвращает поток, подключенный к stdin (fd 0). Это net.Socket (который является потоком Duplex), если fd 0 не ссылается на файл, в этом случае это поток Readable.

Подробную информацию о чтении из stdin см. в readable.read().

Как поток Duplex, process.stdin также можно использовать в «старом» режиме, совместимом со скриптами, написанными для Node.js до версии v0.10. Дополнительные сведения см. в разделе Совместимость потоков.

В «старом» режиме потоков поток stdin по умолчанию приостановлен, поэтому для чтения из него необходимо вызвать process.stdin.resume(). Обратите также внимание, что вызов process.stdin.resume() сам по себе переключит поток в «старый» режим.

process.stdin.fd

• <number>

Это свойство относится к значению базового файлового дескриптора process.stdin. Значение фиксировано на 0. В потоках Worker это поле не существует.

process.stdout

• <Stream>

Свойство process.stdout возвращает поток, подключенный к stdout (дескриптор файла 1). Это net.Socket (который является дуплексным потоком), если дескриптор файла 1 не ссылается на файл, в этом случае это поток для записи.

Например, чтобы скопировать 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 важными особенностями. Дополнительную информацию см. в примечании о вводе-выводе процесса.

process.stdout.fd

• <number>

Это свойство относится к значению базового файлового дескриптора process.stdout. Значение фиксировано на 1. В потоках Worker это поле не существует.

Примечание о вводе-выводе процесса

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 указывает, установлен ли флаг --throw-deprecation в текущем процессе Node.js. process.throwDeprecation является изменяемым, поэтому, будут ли предупреждения об устаревании приводить к ошибкам, можно изменить во время выполнения. Смотрите документацию для 'warning' event и emitWarning() method для получения дополнительной информации.

$ 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 может не привести к точному отображению метки в приложениях диспетчера процессов, таких как Activity Monitor в macOS или Диспетчер служб Windows.

process.traceDeprecation

Добавлено в версии: v0.8.0

• <boolean>

Свойство process.traceDeprecation указывает, установлен ли флаг --trace-deprecation в текущем процессе Node.js. Подробнее о поведении этого флага см. документацию для 'warning' event и emitWarning() method.

process.umask()

[История]

Версия	Изменения
v14.0.0, v12.19.0	Вызов process.umask() без аргументов устарел.
v0.1.19	Добавлено в версии: v0.1.19

[Стабильность: 0 - Устаревший]

Стабильность: 0 Стабильность: 0 - Устаревший. Вызов process.umask() без аргументов приводит к двукратной записи общепроцессной маски umask. Это создает состояние гонки между потоками и является потенциальной уязвимостью безопасности. Безопасной кроссплатформенной альтернативы 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: Исходный код JavaScript, внутренний для процесса начальной загрузки Node.js, вызвал ошибку разбора. Это крайне редко и обычно может произойти только во время разработки самого Node.js.
• 4 Внутренняя ошибка вычисления JavaScript: Исходный код JavaScript, внутренний для процесса начальной загрузки Node.js, не смог вернуть функциональное значение при вычислении. Это крайне редко и обычно может произойти только во время разработки самого Node.js.
• 5 Критическая ошибка: В V8 произошла критическая невосстановимая ошибка. Как правило, в stderr выводится сообщение с префиксом FATAL ERROR.
• 6 Нефункциональный внутренний обработчик исключений: Произошло необработанное исключение, но внутренняя функция обработчика критических исключений каким-то образом была установлена в нефункциональное значение и не могла быть вызвана.
• 7 Сбой времени выполнения внутреннего обработчика исключений: Произошло необработанное исключение, и сама внутренняя функция обработчика критических исключений выдала ошибку при попытке его обработки. Это может произойти, например, если обработчик 'uncaughtException' или domain.on('error') выдает ошибку.
• 8: Не используется. В предыдущих версиях Node.js код выхода 8 иногда указывал на необработанное исключение.
• 9 Неверный аргумент: Либо указана неизвестная опция, либо опция, требующая значения, предоставлена без значения.
• 10 Внутренняя ошибка времени выполнения JavaScript: Исходный код JavaScript, внутренний для процесса начальной загрузки Node.js, выдал ошибку при вызове функции начальной загрузки. Это крайне редко и обычно может произойти только во время разработки самого Node.js.
• 12 Неверный аргумент отладки: Были установлены опции --inspect и/или --inspect-brk, но выбранный номер порта был недействительным или недоступным.
• 13 Неразрешенный Top-Level Await: await использовался вне функции в коде верхнего уровня, но переданный Promise так и не был разрешен.
• 14 Ошибка моментального снимка: Node.js был запущен для создания моментального снимка запуска V8 и завершился неудачно, поскольку определенные требования к состоянию приложения не были выполнены.
• \>128 Завершение по сигналу: Если Node.js получает фатальный сигнал, такой как SIGKILL или SIGHUP, то его код завершения будет 128 плюс значение кода сигнала. Это стандартная практика POSIX, поскольку коды завершения определены как 7-битные целые числа, а завершения по сигналу устанавливают старший бит, а затем содержат значение кода сигнала. Например, сигнал SIGABRT имеет значение 6, поэтому ожидаемый код завершения будет 128 + 6 или 134.