Процесс

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

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

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

Событие: 'beforeExit'

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

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

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

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

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

Событие: 'disconnect'

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

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

Событие: 'exit'

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

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

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

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

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

Например:

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

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

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

Событие: 'message'

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

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

Обработчик вызывается со следующими аргументами:

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

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

Событие: 'rejectionHandled'

Добавлен в: v1.4.1

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

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

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

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

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

В синхронном коде событие 'uncaughtException' генерируется, когда список необработанных исключений увеличивается.

В асинхронном коде событие 'unhandledRejection' генерируется, когда список необработанных отклонений увеличивается, а событие 'rejectionHandled' генерируется, когда список необработанных отклонений уменьшается.

Например:

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

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

Событие: 'uncaughtException'

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

Событие 'uncaughtException' генерируется, когда необработанное исключение JavaScript поднимается до цикла событий. По умолчанию Node.js обрабатывает такие исключения, печатая стек вызовов в stderr и завершая работу. Добавление обработчика для события 'uncaughtException' переопределяет это поведение по умолчанию.

Функция-обработчик вызывается с объектом Error в качестве единственного аргумента.

Например:

process.on('uncaughtException', (err) => {
  fs.writeSync(1, `Caught exception: ${err}\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'`

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

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

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

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

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

Событие: 'unhandledRejection'

История

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

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

Функция-обработчик вызывается со следующими аргументами:

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

Например:

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

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

Следующее также вызовет событие 'unhandledRejection':

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

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

В этом примере можно отслеживать отклонение как ошибку разработчика, как обычно происходит с другими событиями 'unhandledRejection'. Для решения таких проблем можно добавить нерабочий обработчик .catch(() => { }) к resource.loaded, что предотвратит генерацию события 'unhandledRejection'. В качестве альтернативы можно использовать событие 'rejectionHandled'.

Событие: 'warning'

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

Событие 'warning' генерируется всякий раз, когда Node.js генерирует предупреждение процесса.

Предупреждение процесса похоже на ошибку тем, что описывает исключительные условия, которые сообщаются пользователю. Однако предупреждения не являются частью обычного потока обработки ошибок Node.js и JavaScript. Node.js может генерировать предупреждения, когда обнаруживает плохие практики программирования, которые могут привести к неэффективному выполнению приложения, ошибкам или уязвимостям безопасности.

Функция-обработчик вызывается с одним аргументом warning, значением которого является объект Error. Есть три ключевых свойства, описывающие предупреждение:

name <string> Название предупреждения (в настоящее время Warning по умолчанию).
message <string> Описание предупреждения, предоставленное системой.
stack <string> Стек вызовов, указывающий на место в коде, где было выдано предупреждение.

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

По умолчанию Node.js будет выводить предупреждения процесса в stderr. Флаг --no-warnings командной строки можно использовать для подавления стандартного вывода в консоль, но событие 'warning' всё равно будет испускаться объектом process.

Следующий пример иллюстрирует предупреждение, которое выводится в stderr при добавлении слишком большого количества слушателей к событию.

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

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

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

Флаг --trace-warnings командной строки позволяет выводить в консоль полную трассировку стека предупреждения.

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

Примечание: Windows не поддерживает отправку сигналов, но Node.js предлагает некоторую эмуляцию с помощью process.kill() и subprocess.kill(). Отправка сигнала 0 может использоваться для проверки существования процесса. Отправка SIGINT, SIGTERM и SIGKILL вызывает немедленное завершение целевого процесса.

process.abort()

Added in: v0.7.0

Метод process.abort() заставляет процесс Node.js немедленно выйти и создать файл core.

process.arch

Added in: v0.5.0

<string>

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

Возможные значения в настоящее время: 'arm', 'arm64', 'ia32', 'mips', 'mipsel', 'ppc', 'ppc64', 's390', 's390x', 'x32', и 'x64'.

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

process.argv

Added in: v0.1.27

<Array>

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

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

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

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

$ node process-args.js one two=three four

Создаст вывод:

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

process.argv0

Added in: 6.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

Added in: v7.1.0

<Object>

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

process.chdir(directory)

Added in: v0.1.17

directory <string>

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

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

process.config

Added in: v0.7.7

<Object>

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

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

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

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

process.connected

Added in: v0.7.2

<boolean>

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

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

process.cpuUsage([previousValue])

Added in: v6.1.0

previousValue <Объект> Предыдущее возвращённое значение вызова process.cpuUsage()
Возвращает: <Объект>
- user <целое>
- system <целое>

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

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

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

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

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

process.cwd()

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

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

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

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

process.debugPort

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

<число>

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

process.debugPort = 5858;

process.disconnect()

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

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

Эффект вызова process.disconnect() такой же, как вызов ChildProcess.disconnect() в родительском процессе.

Если процесс Node.js не был запущен с каналом IPC, process.disconnect() будет undefined.

process.emitWarning(warning[, options])

Добавлен в: 8.0.0

warning <строка> | <Ошибка> Предупреждение для вывода.
options <Объект>
- type <строка> Когда warning является строкой, type — это имя, используемое для типа выводимого предупреждения. По умолчанию: Warning.
- code <строка> Уникальный идентификатор экземпляра предупреждения, который выводится.
- ctor <Функция> Когда warning является строкой, ctor — это необязательная функция, используемая для ограничения создаваемого трассировки стека. По умолчанию: process.emitWarning.
- detail <строка> Дополнительный текст для включения в ошибку.

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

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

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

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

Если warning передаётся как объект Error, аргумент options игнорируется.

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

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

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

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

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

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

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

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

Если warning передается как объект Error, он будет передан обработчику события process.on('warning') без изменений (и необязательные аргументы type, code и ctor будут проигнорированы):

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

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

Будет выброшена ошибка TypeError, если warning — это что-либо кроме строки или объекта Error.

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

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

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

Избежание дублирующих предупреждений

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

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

process.env

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

<Объект>

Свойство process.env возвращает объект, содержащий пользовательскую среду. См. environ(7).

Пример такого объекта:

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

Изменение этого объекта возможно, но такие изменения не будут отражены за пределами процесса Node.js. Иными словами, следующий пример не сработает:

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

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

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

Присвоение свойства в process.env неявно преобразует значение в строку.

Пример:

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

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

Пример:

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

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

Пример:

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

process.execArgv

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

<Массив>

Свойство process.execArgv возвращает набор опций командной строки, специфичных для Node.js, переданных при запуске процесса Node.js. Эти опции не отображаются в массиве, возвращаемом свойством process.argv, и не включают исполняемый файл Node.js, имя скрипта или любые параметры, следующие за именем скрипта. Эти параметры полезны для запуска дочерних процессов с такой же средой выполнения, как и у родительского.

Например:

$ node --harmony script.js --version

Результатом является process.execArgv:

['--harmony']

А также process.argv:

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

process.execPath

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

<строка>

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

Например:

'/usr/local/bin/node'

process.exit([code])

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

code <целое> Код завершения. По умолчанию: 0.

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

Для выхода с кодом 'failure':

process.exit(1);

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

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

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

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

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

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

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

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

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

process.exitCode

Added in: v0.11.8

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

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

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

process.getegid()

Added in: v2.0.0

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

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

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

process.geteuid()

Added in: v2.0.0

Возвращает: <Объект>

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

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

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

process.getgid()

Added in: v0.1.31

Возвращает: <Объект>

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

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

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

process.getgroups()

Added in: v0.9.4

Возвращает: <Массив>

Метод process.getgroups() возвращает массив дополнительных идентификаторов групп. POSIX не определяет, включен ли эффективный идентификатор группы, но Node.js гарантирует, что он всегда включён.

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

process.getuid()

Added in: v0.1.28

Возвращает: <целое число>

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

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

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

process.hrtime([time])

Added in: v0.7.6

time <Массив> Результат предыдущего вызова process.hrtime()
Возвращает: <Массив>

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

time - необязательный параметр, который должен быть результатом предыдущего вызова process.hrtime() для сравнения с текущим временем. Если переданный параметр не является кортежем массива, будет выброшено TypeError. Передача пользовательского массива вместо результата предыдущего вызова process.hrtime() приведёт к неопределённому поведению.

Эти времена относительны к произвольному моменту в прошлом и не связаны с временем суток, поэтому не подвержены дрейфу часов. Основное применение - измерение производительности между интервалами:

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

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

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

process.initgroups(user, extra_group)

Added in: v0.9.4

user <строка> | <число> Имя пользователя или числовой идентификатор.
extra_group <строка> | <число> Имя группы или числовой идентификатор.

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

Обратите внимание, что при понижении привилегий следует соблюдать осторожность. Пример:

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

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

process.kill(pid[, signal])

Added in: v0.0.6

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

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

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

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

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

Например:

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

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

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

Примечание: Когда SIGUSR1 принят процессом Node.js, Node.js запустит отладчик, см. Сигналы Событий.

process.mainModule

Added in: v0.1.17

<Объект>

Свойство process.mainModule предоставляет альтернативный способ получения require.main. Разница в том, что если основной модуль изменяется во время выполнения, require.main может по-прежнему ссылаться на исходный основной модуль в модулях, которые были загружены до изменения. В общем случае можно считать, что оба ссылаются на один и тот же модуль.

Как и с require.main, process.mainModule будет undefined если нет входного скрипта.

process.memoryUsage()

История

Версия	Изменения
v7.2.0	Добавлен `external` в возвращаемый объект.
v0.1.16	Добавлен в: v0.1.16

Возвращает: <Объект>
- rss <целое число>
- heapTotal <целое число>
- heapUsed <целое число>
- external <целое число>

Метод process.memoryUsage() возвращает объект, описывающий использование памяти процесса Node.js в байтах.

Например, код:

console.log(process.memoryUsage());

Сгенерирует:

{
  rss: 4935680,
  heapTotal: 1826816,
  heapUsed: 650472,
  external: 49879
}

heapTotal и heapUsed относятся к использованию памяти V8. external относится к использованию памяти C++-объектов, связанных с JavaScript-объектами, управляемыми V8. rss, Размер резидентного набора, — это объем памяти, занимаемой в оперативной памяти (это подмножество общей выделенной памяти) для процесса, который включает кучу, сегмент кода и стек.

Куча — это место, где хранятся объекты, строки и замыкания. Переменные хранятся в стеке, а сам JavaScript-код находится в сегменте кода.

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

История

Версия	Изменения
v1.8.1	Теперь поддерживаются дополнительные аргументы после `callback`.
v0.1.26	Добавлен в: v0.1.26

callback <Функция>
...args <любой> Дополнительные аргументы для передачи при вызове callback

Метод process.nextTick() добавляет callback в очередь "следующего цикла". После завершения текущего цикла обработки событий все колбэки, находящиеся в очереди следующего цикла, будут вызваны.

Это не простой псевдоним для setTimeout(fn, 0). Он намного эффективнее. Он выполняется перед запуском любых дополнительных событий ввода-вывода (включая таймеры) в последующих циклах обработки событий.

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

Это важно при разработке API, чтобы дать пользователям возможность назначать обработчики событий после создания объекта, но до выполнения любых операций ввода-вывода:

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

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

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

// thing.startDoingStuff() gets called now, not before.

Очень важно, чтобы API были либо 100% синхронными, либо 100% асинхронными. Рассмотрим этот пример:

// WARNING!  DO NOT USE!  BAD UNSAFE HAZARD!
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() будет вызван первым.

Следующий подход намного лучше:

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

  fs.stat('file', cb);
}

Примечание: Очередь следующего цикла полностью очищается на каждой итерации цикла обработки событий перед обработкой дополнительных событий ввода-вывода. В результате рекурсивное задание коллбеков nextTick заблокирует любые операции ввода-вывода, как и while(true); цикл.

process.noDeprecation

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

<булево значение>

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

process.pid

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

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

Свойство process.pid возвращает PID процесса.

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

process.platform

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

<строка>

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

Возможные значения:

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

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

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

process.ppid

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

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

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

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

process.release

История

Версия	Изменения
v4.2.0	Теперь поддерживается свойство `lts`.
v3.0.0	Добавлен в: v3.0.0

<Объект>

Свойство process.release возвращает объект, содержащий метаданные, связанные с текущей версией, включая URL исходного tar-архива и tar-архива только заголовков.

process.release содержит следующие свойства:

name <строка> Значение, которое всегда будет 'node' для Node.js. Для устаревших выпусков io.js это будет 'io.js'.
sourceUrl <строка> абсолютный URL, указывающий на файл .tar.gz, содержащий исходный код текущей версии.
headersUrl<строка> абсолютный URL, указывающий на файл .tar.gz, содержащий только исходные заголовочные файлы для текущей версии. Этот файл значительно меньше, чем полный исходный файл, и может использоваться для компиляции нативных дополнений Node.js.
libUrl <строка> абсолютный URL, указывающий на файл node.lib, соответствующий архитектуре и версии текущей версии. Этот файл используется для компиляции нативных дополнений Node.js. Это свойство присутствует только в сборках Node.js под Windows и будет отсутствовать на всех других платформах.
lts <строка> строка, идентифицирующая метку LTS для этого выпуска. Это свойство существует только для LTS-выпусков и имеет значение undefined для всех других типов выпусков, включая текущие. В настоящее время допустимые значения:
- 'Argon' для 4.x LTS-линии, начинающейся с 4.2.0.
- 'Boron' для 6.x LTS-линии, начинающейся с 6.9.0.
- 'Carbon' для 8.x LTS-линии, начинающейся с 8.9.1.

Например:

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

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

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

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

message <Объект>
sendHandle <Объект-обработчик>
options <Объект>
callback <Функция>
Возвращает: <булево значение>

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

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

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

process.setegid(id)

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

id <строка> | <число> Название или ID группы

Метод process.setegid() устанавливает эффективную идентификацию группы процесса. (См. setegid(2).) id может быть передан как числовой ID или строка имени группы. Если указано имя группы, этот метод блокируется во время разрешения соответствующего числового ID.

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

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

process.seteuid(id)

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

id <строка> | <число> Имя пользователя или идентификатор

Метод process.seteuid() устанавливает эффективную идентичность пользователя процесса. (См. seteuid(2).) id может быть передан как числовой идентификатор или строка имени пользователя. Если указано имя пользователя, метод блокируется до разрешения соответствующего числового идентификатора.

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

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

process.setgid(id)

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

id <строка> | <число> Название или идентификатор группы

Метод process.setgid() устанавливает идентичность группы процесса. (См. setgid(2).) id может быть передан как числовой идентификатор или строка имени группы. Если указано имя группы, этот метод блокируется до разрешения соответствующего числового идентификатора.

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

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

process.setgroups(groups)

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

groups <Массив>

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

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

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

process.setuid(id)

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

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

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

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

process.stderr

<Поток>

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

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

process.stdin

<Поток>

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

Например:

process.stdin.setEncoding('utf8');

process.stdin.on('readable', () => {
  const chunk = process.stdin.read();
  if (chunk !== null) {
    process.stdout.write(`data: ${chunk}`);
  }
});

process.stdin.on('end', () => {
  process.stdout.write('end');
});

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

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

process.stdout

<Поток>

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

Например, чтобы скопировать process.stdin в process.stdout:

process.stdin.pipe(process.stdout);

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

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

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

Они используются внутри console.log() и console.error(), соответственно.
Записи могут быть синхронными в зависимости от того, к чему подключен поток, и от того, Windows или POSIX система:
- Файлы: синхронно в Windows и POSIX
- TTY (терминалы): асинхронно в Windows, синхронно в POSIX
- Каналы (и сокеты): синхронно в Windows, асинхронно в POSIX

Эти особенности частично обусловлены историческими причинами, так как их изменение привело бы к несовместимости со старыми версиями, но они также ожидаются некоторыми пользователями.

Синхронные записи предотвращают проблемы, такие как неожиданное переплетение вывода с 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

<логическое>

Свойство process.throwDeprecation указывает, установлен ли флаг --throw-deprecation в текущем процессе Node.js. См. документацию для события warning события и метода emitWarning метода для получения дополнительной информации о поведении этого флага.

process.title

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

<строка>

Свойство process.title возвращает текущее название процесса (т. е. возвращает текущее значение ps). Присвоение нового значения process.title изменяет текущее значение ps.

Примечание: При присвоении нового значения различные платформы налагают различные ограничения максимальной длины заголовка. Обычно такие ограничения довольно ограничены. Например, в Linux и macOS process.title ограничен размером имени двоичного файла плюс длиной аргументов командной строки, потому что установка process.title перезаписывает память argv процесса. Node.js v0.8 позволял более длинные строки заголовка процесса, перезаписывая также память environ процесса, но это потенциально было небезопасно и вызывало путаницу в некоторых (довольно необычных) случаях.

process.traceDeprecation

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

<логическое>

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

process.umask([mask])

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

mask <число>

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

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

process.uptime()

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

Возвращает: <число>

Метод process.uptime() возвращает количество секунд, в течение которых текущий процесс Node.js работает.

END_OF_DOCUMENT_MARKER

Примечание: Возвращаемое значение включает доли секунды. Используйте Math.floor() для получения целых секунд.

process.version

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

<строка>

Свойство process.version возвращает строку версии Node.js.

console.log(`Version: ${process.version}`);

process.versions

История

Версия	Изменения
v4.2.0	Теперь поддерживается свойство `icu`.
v0.2.0	Добавлен в: v0.2.0

<Объект>

Свойство process.versions возвращает объект, перечисляющий строки версий Node.js и его зависимостей. process.versions.modules указывает текущую версию ABI, которая увеличивается всякий раз, когда изменяется API на C++. Node.js откажется от загрузки модулей, скомпилированных с использованием другой версии модульного ABI.

console.log(process.versions);

Будет сгенерирован объект, аналогичный:

{ http_parser: '2.7.0',
  node: '8.9.0',
  v8: '6.3.292.48-node.6',
  uv: '1.18.0',
  zlib: '1.2.11',
  ares: '1.13.0',
  modules: '60',
  nghttp2: '1.29.0',
  napi: '2',
  openssl: '1.0.2n',
  icu: '60.1',
  unicode: '10.0',
  cldr: '32.0',
  tz: '2016b' }

Коды завершения

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

1 Необработанное фатальное исключение - произошла необработанная ошибка, и она не была обработана областью или обработчиком события 'uncaughtException'.
2 - Не используется (зарезервировано Bash для неправильного использования встроенных функций)
3 Внутренняя ошибка парсинга JavaScript - внутренний в Node.js код JavaScript, используемый в процессе запуска, вызвал ошибку парсинга. Это крайне редко и, как правило, может произойти только во время разработки самого 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 были установлены, но выбранный номер порта был недопустимым или недоступным.
>128 Завершения по сигналам - Если Node.js получает фатальный сигнал, такой как SIGKILL или SIGHUP, тогда его код завершения будет 128 плюс значение кода сигнала. Это стандартная практика POSIX, так как коды завершения определены как 7-битные целые числа, а сигнальные завершения устанавливают старший бит, а затем содержат значение кода сигнала.

© Joyent, Inc. and other Node contributors
Licensed under the MIT License.
Node.js is a trademark of Joyent, Inc. and is used with its permission.
We are not endorsed by or affiliated with Joyent.
https://nodejs.org/dist/latest-v8.x/docs/api/process.html

Процесс

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

Событие: 'beforeExit'

Событие: 'disconnect'

Событие: 'exit'

Событие: 'message'

Событие: 'rejectionHandled'

Событие: 'uncaughtException'

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

Событие: 'unhandledRejection'

Событие: 'warning'

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

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

process.abort()

process.arch

process.argv

process.argv0

process.channel

process.chdir(directory)

process.config

process.connected

process.cpuUsage([previousValue])

process.cwd()

process.debugPort

process.disconnect()

process.emitWarning(warning[, options])

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

Избежание дублирующих предупреждений

process.env

process.execArgv

process.execPath

process.exit([code])

process.exitCode

process.getegid()

process.geteuid()

process.getgid()

process.getgroups()

process.getuid()

process.hrtime([time])

process.initgroups(user, extra_group)

process.kill(pid[, signal])

process.mainModule

process.memoryUsage()

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

process.noDeprecation

process.pid

process.platform

process.ppid

process.release

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

process.setegid(id)

process.seteuid(id)

process.setgid(id)

process.setgroups(groups)

process.setuid(id)

process.stderr

process.stdin

process.stdout

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

process.throwDeprecation

process.title

process.traceDeprecation

process.umask([mask])

process.uptime()

process.version

process.versions

Коды завершения

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