Proceso

El objeto process proporciona información y control sobre el proceso actual de Node.js.

ESMCJS

import process from 'node:process'

const process = require('node:process')

Eventos del proceso

El objeto process es una instancia de EventEmitter.

Evento: `'beforeExit'`

Añadido en: v0.11.12

El evento 'beforeExit' se emite cuando Node.js vacía su bucle de eventos y no tiene trabajo adicional que programar. Normalmente, el proceso de Node.js saldrá cuando no haya trabajo programado, pero un receptor registrado en el evento 'beforeExit' puede realizar llamadas asíncronas y, por lo tanto, hacer que el proceso de Node.js continúe.

La función de devolución de llamada del receptor se invoca con el valor de process.exitCode pasado como único argumento.

El evento 'beforeExit' no se emite para condiciones que provocan la terminación explícita, como llamar a process.exit() o excepciones no controladas.

El evento 'beforeExit' no debe utilizarse como alternativa al evento 'exit' a menos que la intención sea programar trabajo adicional.

ESMCJS

import process from 'node:process'

process.on('beforeExit', code => {
  console.log('Evento beforeExit del proceso con código: ', code)
})

process.on('exit', code => {
  console.log('Evento exit del proceso con código: ', code)
})

console.log('Este mensaje se muestra primero.')

// Imprime:
// Este mensaje se muestra primero.
// Evento beforeExit del proceso con código: 0
// Evento exit del proceso con código: 0

const process = require('node:process')

process.on('beforeExit', code => {
  console.log('Evento beforeExit del proceso con código: ', code)
})

process.on('exit', code => {
  console.log('Evento exit del proceso con código: ', code)
})

console.log('Este mensaje se muestra primero.')

// Imprime:
// Este mensaje se muestra primero.
// Evento beforeExit del proceso con código: 0
// Evento exit del proceso con código: 0

Evento: `'disconnect'`

Añadido en: v0.7.7

Si el proceso de Node.js se inicia con un canal IPC (ver la documentación de Proceso Hijo y Cluster), el evento 'disconnect' se emitirá cuando se cierre el canal IPC.

Evento: `'exit'`

Añadido en: v0.1.7

code <entero>

El evento 'exit' se emite cuando el proceso de Node.js está a punto de salir como resultado de:

Que se llame explícitamente al método process.exit();
Que el bucle de eventos de Node.js ya no tenga trabajo adicional que realizar.

No hay forma de evitar la salida del bucle de eventos en este punto, y una vez que todos los listeners de 'exit' han terminado de ejecutarse, el proceso de Node.js terminará.

La función de callback del listener se invoca con el código de salida especificado ya sea por la propiedad process.exitCode, o el argumento exitCode pasado al método process.exit().

ESMCJS

import process from 'node:process'

process.on('exit', code => {
  console.log(`A punto de salir con el código: ${code}`)
})

const process = require('node:process')

process.on('exit', code => {
  console.log(`A punto de salir con el código: ${code}`)
})

Las funciones de listener solo deben realizar operaciones síncronas. El proceso de Node.js saldrá inmediatamente después de llamar a los listeners del evento 'exit', lo que provocará que se abandone cualquier trabajo adicional que aún esté en la cola del bucle de eventos. En el siguiente ejemplo, por ejemplo, el timeout nunca se producirá:

ESMCJS

import process from 'node:process'

process.on('exit', code => {
  setTimeout(() => {
    console.log('Esto no se ejecutará')
  }, 0)
})

const process = require('node:process')

process.on('exit', code => {
  setTimeout(() => {
    console.log('Esto no se ejecutará')
  }, 0)
})

Evento: `'message'`

Agregado en: v0.5.10

message <Object> | <boolean> | <number> | <string> | <null> un objeto JSON analizado o un valor primitivo serializable.
sendHandle <net.Server> | <net.Socket> un objeto net.Server o net.Socket, o undefined.

Si el proceso de Node.js se genera con un canal IPC (ver la documentación de Proceso Hijo y Cluster), el evento 'message' se emite siempre que un mensaje enviado por un proceso padre utilizando childprocess.send() es recibido por el proceso hijo.

El mensaje pasa por serialización y análisis. El mensaje resultante podría no ser el mismo que se envió originalmente.

Si la opción serialization se estableció en advanced al generar el proceso, el argumento message puede contener datos que JSON no puede representar. Consulta Serialización avanzada para child_process para más detalles.

Event: `'multipleResolves'`

Agregado en: v10.12.0

Obsoleto desde: v17.6.0, v16.15.0

[Estable: 0 - Obsoleto]

Estable: 0 Estabilidad: 0 - Obsoleto

type <string> El tipo de resolución. Uno de 'resolve' o 'reject'.
promise <Promise> La promesa que se resolvió o rechazó más de una vez.
value <any> El valor con el que la promesa se resolvió o rechazó después de la resolución original.

El evento 'multipleResolves' se emite cada vez que una Promise ha sido:

Resuelta más de una vez.
Rechazada más de una vez.
Rechazada después de resolverse.
Resuelta después de rechazarse.

Esto es útil para rastrear posibles errores en una aplicación mientras se usa el constructor Promise, ya que las resoluciones múltiples se tragan silenciosamente. Sin embargo, la aparición de este evento no indica necesariamente un error. Por ejemplo, Promise.race() puede desencadenar un evento 'multipleResolves'.

Debido a la poca fiabilidad del evento en casos como el ejemplo Promise.race() anterior, se ha declarado obsoleto.

ESMCJS

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('Primera llamada')
      resolve('Resolución tragada')
      reject(new Error('Rechazo tragado'))
    })
  } catch {
    throw new Error('Falló')
  }
}

main().then(console.log)
// resolve: Promise { 'Primera llamada' } 'Resolución tragada'
// reject: Promise { 'Primera llamada' } Error: Rechazo tragado
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// Primera llamada

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('Primera llamada')
      resolve('Resolución tragada')
      reject(new Error('Rechazo tragado'))
    })
  } catch {
    throw new Error('Falló')
  }
}

main().then(console.log)
// resolve: Promise { 'Primera llamada' } 'Resolución tragada'
// reject: Promise { 'Primera llamada' } Error: Rechazo tragado
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// Primera llamada

Evento: `'rejectionHandled'`

Añadido en: v1.4.1

promise <Promise> La promesa manejada tardíamente.

El evento 'rejectionHandled' se emite cuando una Promise ha sido rechazada y se le ha adjuntado un manejador de errores (usando promise.catch(), por ejemplo) más tarde de un turno del bucle de eventos de Node.js.

El objeto Promise se habría emitido previamente en un evento 'unhandledRejection', pero durante el curso del procesamiento obtuvo un manejador de rechazo.

No existe la noción de un nivel superior para una cadena de Promise en la que siempre se puedan manejar los rechazos. Siendo inherentemente asíncrono en su naturaleza, un rechazo de Promise puede ser manejado en un punto futuro en el tiempo, posiblemente mucho más tarde que el turno del bucle de eventos que se necesita para que se emita el evento 'unhandledRejection'.

Otra forma de expresar esto es que, a diferencia del código síncrono donde hay una lista cada vez mayor de excepciones no manejadas, con las Promesas puede haber una lista creciente y decreciente de rechazos no manejados.

En código síncrono, el evento 'uncaughtException' se emite cuando la lista de excepciones no manejadas crece.

En código asíncrono, el evento 'unhandledRejection' se emite cuando la lista de rechazos no manejados crece, y el evento 'rejectionHandled' se emite cuando la lista de rechazos no manejados disminuye.

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

En este ejemplo, el Map unhandledRejections crecerá y disminuirá con el tiempo, reflejando los rechazos que comienzan sin manejar y luego se manejan. Es posible registrar tales errores en un registro de errores, ya sea periódicamente (lo cual es probablemente mejor para aplicaciones de larga duración) o al salir del proceso (lo cual es probablemente más conveniente para scripts).

Evento: `'workerMessage'`

Agregado en: v22.5.0

value <any> Un valor transmitido usando postMessageToThread().
source <number> El ID del hilo de worker que transmite o 0 para el hilo principal.

El evento 'workerMessage' se emite para cualquier mensaje entrante enviado por la otra parte usando postMessageToThread().

Evento: `'uncaughtException'`

[Historial]

Versión	Cambios
v12.0.0, v10.17.0	Se agregó el argumento `origin`.
v0.1.18	Agregado en: v0.1.18

err <Error> La excepción no detectada.
origin <string> Indica si la excepción se origina de un rechazo no manejado o de un error sincrónico. Puede ser 'uncaughtException' o 'unhandledRejection'. El último se usa cuando ocurre una excepción en un contexto asíncrono basado en Promise (o si un Promise es rechazado) y el flag --unhandled-rejections se establece en strict o throw (que es el valor predeterminado) y el rechazo no se maneja, o cuando ocurre un rechazo durante la fase de carga estática del módulo ES del punto de entrada de la línea de comandos.

El evento 'uncaughtException' se emite cuando una excepción de JavaScript no detectada se propaga de vuelta al bucle de eventos. De forma predeterminada, Node.js maneja tales excepciones imprimiendo el seguimiento de la pila en stderr y saliendo con el código 1, anulando cualquier process.exitCode establecido previamente. Agregar un controlador para el evento 'uncaughtException' anula este comportamiento predeterminado. Alternativamente, cambie el process.exitCode en el controlador 'uncaughtException' lo que resultará en que el proceso salga con el código de salida proporcionado. De lo contrario, en presencia de tal controlador, el proceso saldrá con 0.

ESMCJS

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

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Excepción capturada: ${err}\n` + `Origen de la excepción: ${origin}\n`)
})

setTimeout(() => {
  console.log('Esto todavía se ejecutará.')
}, 500)

// Intencionalmente causa una excepción, pero no la captura.
nonexistentFunc()
console.log('Esto no se ejecutará.')

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

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Excepción capturada: ${err}\n` + `Origen de la excepción: ${origin}\n`)
})

setTimeout(() => {
  console.log('Esto todavía se ejecutará.')
}, 500)

// Intencionalmente causa una excepción, pero no la captura.
nonexistentFunc()
console.log('Esto no se ejecutará.')

Es posible monitorizar los eventos 'uncaughtException' sin anular el comportamiento predeterminado para salir del proceso instalando un listener 'uncaughtExceptionMonitor'.

Advertencia: Uso correcto de `'uncaughtException'`

'uncaughtException' es un mecanismo crudo para el manejo de excepciones destinado a ser utilizado solo como último recurso. El evento no debe ser usado como un equivalente a On Error Resume Next. Las excepciones no manejadas inherentemente significan que una aplicación está en un estado indefinido. Intentar reanudar el código de la aplicación sin recuperarse adecuadamente de la excepción puede causar problemas adicionales imprevistos e impredecibles.

Las excepciones lanzadas desde dentro del controlador de eventos no serán capturadas. En cambio, el proceso saldrá con un código de salida diferente de cero y se imprimirá el rastreo de la pila. Esto es para evitar la recursión infinita.

Intentar reanudar normalmente después de una excepción no detectada puede ser similar a desenchufar el cable de alimentación al actualizar una computadora. Nueve de cada diez veces, no pasa nada. Pero la décima vez, el sistema se corrompe.

El uso correcto de 'uncaughtException' es realizar una limpieza sincrónica de los recursos asignados (por ejemplo, descriptores de archivo, controladores, etc.) antes de cerrar el proceso. No es seguro reanudar la operación normal después de 'uncaughtException'.

Para reiniciar una aplicación bloqueada de una manera más confiable, ya sea que se emita o no 'uncaughtException', se debe emplear un monitor externo en un proceso separado para detectar fallas de la aplicación y recuperarse o reiniciarse según sea necesario.

Evento: `'uncaughtExceptionMonitor'`

Agregado en: v13.7.0, v12.17.0

err <Error> La excepción no capturada.
origin <string> Indica si la excepción se origina de un rechazo no manejado o de errores síncronos. Puede ser 'uncaughtException' o 'unhandledRejection'. El último se usa cuando ocurre una excepción en un contexto asíncrono basado en Promise (o si se rechaza una Promise) y la bandera --unhandled-rejections está establecida en strict o throw (que es el valor predeterminado) y el rechazo no se maneja, o cuando ocurre un rechazo durante la fase de carga estática del módulo ES del punto de entrada de la línea de comandos.

El evento 'uncaughtExceptionMonitor' se emite antes de que se emita un evento 'uncaughtException' o se llame a un hook instalado a través de process.setUncaughtExceptionCaptureCallback().

La instalación de un listener 'uncaughtExceptionMonitor' no cambia el comportamiento una vez que se emite un evento 'uncaughtException'. El proceso seguirá fallando si no se instala ningún listener 'uncaughtException'.

ESMCJS

import process from 'node:process'

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

// Intencionalmente causa una excepción, pero no la captura.
nonexistentFunc()
// Aún falla Node.js

const process = require('node:process')

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

// Intencionalmente causa una excepción, pero no la captura.
nonexistentFunc()
// Aún falla Node.js

Evento: `'unhandledRejection'`

[Historial]

Versión	Cambios
v7.0.0	No manejar los rechazos de `Promise` está obsoleto.
v6.6.0	Los rechazos de `Promise` no manejados ahora emitirán una advertencia del proceso.
v1.4.1	Añadido en: v1.4.1

reason <Error> | <any> El objeto con el que se rechazó la promesa (normalmente un objeto Error).
promise <Promise> La promesa rechazada.

El evento 'unhandledRejection' se emite cada vez que se rechaza una Promise y no se adjunta ningún manejador de errores a la promesa dentro de un turno del bucle de eventos. Al programar con Promesas, las excepciones se encapsulan como "promesas rechazadas". Los rechazos se pueden capturar y manejar usando promise.catch() y se propagan a través de una cadena Promise. El evento 'unhandledRejection' es útil para detectar y realizar un seguimiento de las promesas que fueron rechazadas cuyos rechazos aún no han sido manejados.

ESMCJS

import process from 'node:process'

process.on('unhandledRejection', (reason, promise) => {
  console.log('Rechazo no manejado en:', promise, 'razón:', reason)
  // Registro específico de la aplicación, lanzamiento de un error u otra lógica aquí
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // Note la errata (`pasre`)
}) // Sin `.catch()` o `.then()`

const process = require('node:process')

process.on('unhandledRejection', (reason, promise) => {
  console.log('Rechazo no manejado en:', promise, 'razón:', reason)
  // Registro específico de la aplicación, lanzamiento de un error u otra lógica aquí
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // Note la errata (`pasre`)
}) // Sin `.catch()` o `.then()`

Lo siguiente también activará que se emita el evento 'unhandledRejection':

ESMCJS

import process from 'node:process'

function SomeResource() {
  // Inicialmente establece el estado cargado a una promesa rechazada
  this.loaded = Promise.reject(new Error('¡Recurso aún no cargado!'))
}

const resource = new SomeResource()
// sin .catch o .then en resource.loaded durante al menos un turno

const process = require('node:process')

function SomeResource() {
  // Inicialmente establece el estado cargado a una promesa rechazada
  this.loaded = Promise.reject(new Error('¡Recurso aún no cargado!'))
}

const resource = new SomeResource()
// sin .catch o .then en resource.loaded durante al menos un turno

En este caso de ejemplo, es posible rastrear el rechazo como un error de desarrollador, como sería típicamente el caso de otros eventos 'unhandledRejection'. Para abordar tales fallos, se puede adjuntar un manejador no operativo .catch(() => { }) a resource.loaded, lo que evitaría que se emitiera el evento 'unhandledRejection'.

Evento: `'warning'`

Añadido en: v6.0.0

warning <Error> Las propiedades clave de la advertencia son:
- name <string> El nombre de la advertencia. Predeterminado: 'Warning'.
- message <string> Una descripción proporcionada por el sistema de la advertencia.
- stack <string> Un rastreo de pila a la ubicación en el código donde se emitió la advertencia.

El evento 'warning' se emite cada vez que Node.js emite una advertencia del proceso.

Una advertencia de proceso es similar a un error en el sentido de que describe condiciones excepcionales que se están llamando la atención del usuario. Sin embargo, las advertencias no son parte del flujo normal de manejo de errores de Node.js y JavaScript. Node.js puede emitir advertencias cada vez que detecta malas prácticas de codificación que podrían llevar a un rendimiento subóptimo de la aplicación, errores o vulnerabilidades de seguridad.

ESMCJS

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // Imprimir el nombre de la advertencia
  console.warn(warning.message) // Imprimir el mensaje de la advertencia
  console.warn(warning.stack) // Imprimir el rastreo de pila
})

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // Imprimir el nombre de la advertencia
  console.warn(warning.message) // Imprimir el mensaje de la advertencia
  console.warn(warning.stack) // Imprimir el rastreo de pila
})

Por defecto, Node.js imprimirá las advertencias de proceso en stderr. La opción de línea de comandos --no-warnings se puede usar para suprimir la salida de la consola predeterminada, pero el evento 'warning' seguirá siendo emitido por el objeto process. Actualmente, no es posible suprimir tipos de advertencia específicos que no sean las advertencias de obsolescencia. Para suprimir las advertencias de obsolescencia, consulte el indicador --no-deprecation.

El siguiente ejemplo ilustra la advertencia que se imprime en stderr cuando se han agregado demasiados listeners a un evento:

bash

$ node
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> (node:38638) MaxListenersExceededWarning: Posible fuga de memoria de EventEmitter detectada. Se agregaron 2 listeners foo. Use emitter.setMaxListeners() para aumentar el límite.

En contraste, el siguiente ejemplo desactiva la salida de advertencia predeterminada y agrega un controlador personalizado al evento 'warning':

bash

$ node --no-warnings
> const p = process.on('warning', (warning) => console.warn('¡No hagas eso!'));
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> ¡No hagas eso!

La opción de línea de comandos --trace-warnings se puede usar para que la salida de consola predeterminada para las advertencias incluya el rastreo de pila completo de la advertencia.

Lanzar Node.js usando el indicador de línea de comandos --throw-deprecation hará que las advertencias de obsolescencia personalizadas se arrojen como excepciones.

Usar el indicador de línea de comandos --trace-deprecation hará que la obsolescencia personalizada se imprima en stderr junto con el rastreo de pila.

Usar el indicador de línea de comandos --no-deprecation suprimirá todos los informes de la obsolescencia personalizada.

Los indicadores de línea de comandos *-deprecation solo afectan a las advertencias que usan el nombre 'DeprecationWarning'.

Emisión de advertencias personalizadas

Consulta el método process.emitWarning() para emitir advertencias personalizadas o específicas de la aplicación.

Nombres de advertencias de Node.js

No existen directrices estrictas para los tipos de advertencias (identificados por la propiedad name) emitidas por Node.js. Se pueden agregar nuevos tipos de advertencias en cualquier momento. Algunos de los tipos de advertencias más comunes incluyen:

'DeprecationWarning' - Indica el uso de una API o característica de Node.js obsoleta. Dichas advertencias deben incluir una propiedad 'code' que identifique el código de obsolescencia.
'ExperimentalWarning' - Indica el uso de una API o característica experimental de Node.js. Dichas características deben usarse con precaución, ya que pueden cambiar en cualquier momento y no están sujetas a las mismas políticas estrictas de control semántico de versiones y soporte a largo plazo que las características admitidas.
'MaxListenersExceededWarning' - Indica que se han registrado demasiados oyentes para un evento dado en un EventEmitter o EventTarget. Esto a menudo es un indicio de una fuga de memoria.
'TimeoutOverflowWarning' - Indica que se ha proporcionado un valor numérico que no cabe dentro de un entero con signo de 32 bits a las funciones setTimeout() o setInterval().
'TimeoutNegativeWarning' - Indica que se ha proporcionado un número negativo a las funciones setTimeout() o setInterval().
'TimeoutNaNWarning' - Indica que se ha proporcionado un valor que no es un número a las funciones setTimeout() o setInterval().
'UnsupportedWarning' - Indica el uso de una opción o característica no compatible que se ignorará en lugar de tratarse como un error. Un ejemplo es el uso del mensaje de estado de respuesta HTTP al usar la API de compatibilidad HTTP/2.

Evento: `'worker'`

Agregado en: v16.2.0, v14.18.0

worker <Worker> El <Worker> que fue creado.

El evento 'worker' se emite después de que se ha creado un nuevo hilo <Worker>.

Eventos de señal

Los eventos de señal se emitirán cuando el proceso de Node.js reciba una señal. Consulta signal(7) para obtener una lista de los nombres de señales POSIX estándar como 'SIGINT', 'SIGHUP', etc.

Las señales no están disponibles en los hilos Worker.

El controlador de señales recibirá el nombre de la señal ('SIGINT', 'SIGTERM', etc.) como primer argumento.

El nombre de cada evento será el nombre común en mayúsculas de la señal (por ejemplo, 'SIGINT' para las señales SIGINT).

ESMCJS

import process from 'node:process'

// Empieza a leer desde stdin para que el proceso no finalice.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('Se recibió SIGINT. Pulsa Control-D para salir.')
})

// Utilizar una única función para manejar múltiples señales
function handle(signal) {
  console.log(`Se recibió ${signal}`)
}

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

const process = require('node:process')

// Empieza a leer desde stdin para que el proceso no finalice.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('Se recibió SIGINT. Pulsa Control-D para salir.')
})

// Utilizar una única función para manejar múltiples señales
function handle(signal) {
  console.log(`Se recibió ${signal}`)
}

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

'SIGUSR1' está reservado por Node.js para iniciar el depurador. Es posible instalar un listener, pero hacerlo podría interferir con el depurador.
'SIGTERM' y 'SIGINT' tienen controladores predeterminados en plataformas que no son Windows que restablecen el modo de terminal antes de salir con el código 128 + número de señal. Si una de estas señales tiene un listener instalado, su comportamiento predeterminado se eliminará (Node.js ya no saldrá).
'SIGPIPE' se ignora de forma predeterminada. Se le puede instalar un listener.
'SIGHUP' se genera en Windows cuando se cierra la ventana de la consola, y en otras plataformas bajo varias condiciones similares. Consulta signal(7). Se le puede instalar un listener; sin embargo, Windows terminará incondicionalmente Node.js unos 10 segundos después. En plataformas que no son Windows, el comportamiento predeterminado de SIGHUP es terminar Node.js, pero una vez que se ha instalado un listener, su comportamiento predeterminado se eliminará.
'SIGTERM' no es compatible con Windows, se puede escuchar.
'SIGINT' desde la terminal es compatible con todas las plataformas, y generalmente se puede generar con + (aunque esto puede ser configurable). No se genera cuando el modo raw de la terminal está habilitado y se usa +.
'SIGBREAK' se entrega en Windows cuando se presiona + . En plataformas que no son Windows, se puede escuchar, pero no hay forma de enviarlo o generarlo.
'SIGWINCH' se entrega cuando se ha cambiado el tamaño de la consola. En Windows, esto solo sucederá al escribir en la consola cuando se está moviendo el cursor, o cuando se utiliza un tty legible en modo raw.
No se puede instalar un listener para 'SIGKILL', terminará incondicionalmente Node.js en todas las plataformas.
No se puede instalar un listener para 'SIGSTOP'.
'SIGBUS', 'SIGFPE', 'SIGSEGV' y 'SIGILL', cuando no se generan artificialmente utilizando kill(2), inherentemente dejan el proceso en un estado desde el cual no es seguro llamar a los listeners de JS. Hacerlo podría causar que el proceso deje de responder.
Se puede enviar 0 para probar la existencia de un proceso, no tiene efecto si el proceso existe, pero lanzará un error si el proceso no existe.

Windows no es compatible con las señales, por lo que no tiene un equivalente a la terminación por señal, pero Node.js ofrece cierta emulación con process.kill() y subprocess.kill():

Enviar SIGINT, SIGTERM y SIGKILL causará la terminación incondicional del proceso de destino y, posteriormente, el subproceso informará que el proceso fue terminado por señal.
Enviar la señal 0 se puede usar como una forma independiente de la plataforma para probar la existencia de un proceso.

`process.abort()`

Añadido en: v0.7.0

El método process.abort() hace que el proceso de Node.js salga inmediatamente y genere un archivo core.

Esta función no está disponible en los threads Worker.

`process.allowedNodeEnvironmentFlags`

Añadido en: v10.10.0

<Set>

La propiedad process.allowedNodeEnvironmentFlags es un Set especial de solo lectura de flags permitidos dentro de la variable de entorno NODE_OPTIONS.

process.allowedNodeEnvironmentFlags extiende Set, pero sobrescribe Set.prototype.has para reconocer varias representaciones posibles de flags. process.allowedNodeEnvironmentFlags.has() retornará true en los siguientes casos:

Los flags pueden omitir guiones sencillos (-) o dobles (--) iniciales; por ejemplo, inspect-brk para --inspect-brk, o r para -r.
Los flags pasados a V8 (como se listan en --v8-options) pueden reemplazar uno o más guiones no iniciales por un guion bajo, o viceversa; por ejemplo, --perf_basic_prof, --perf-basic-prof, --perf_basic-prof, etc.
Los flags pueden contener uno o más caracteres de igual (=); todos los caracteres después e incluyendo el primer igual serán ignorados; por ejemplo, --stack-trace-limit=100.
Los flags deben estar permitidos dentro de NODE_OPTIONS.

Cuando se itera sobre process.allowedNodeEnvironmentFlags, los flags aparecerán solo una vez; cada uno comenzará con uno o más guiones. Los flags pasados a V8 contendrán guiones bajos en lugar de guiones no iniciales:

ESMCJS

import { allowedNodeEnvironmentFlags } from 'node:process'

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

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

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

Los métodos add(), clear(), y delete() de process.allowedNodeEnvironmentFlags no hacen nada, y fallarán silenciosamente.

Si Node.js fue compilado sin soporte para NODE_OPTIONS (mostrado en process.config), process.allowedNodeEnvironmentFlags contendrá lo que habría sido permitido.

`process.arch`

Agregado en: v0.5.0

<string>

La arquitectura de la CPU del sistema operativo para la que se compiló el binario de Node.js. Los valores posibles son: 'arm', 'arm64', 'ia32', 'loong64', 'mips', 'mipsel', 'ppc', 'ppc64', 'riscv64', 's390', 's390x' y 'x64'.

ESMCJS

import { arch } from 'node:process'

console.log(`La arquitectura de este procesador es ${arch}`)

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

console.log(`La arquitectura de este procesador es ${arch}`)

`process.argv`

Agregado en: v0.1.27

<string[]>

La propiedad process.argv devuelve un array que contiene los argumentos de la línea de comandos pasados cuando se inició el proceso de Node.js. El primer elemento será process.execPath. Consulta process.argv0 si se necesita acceder al valor original de argv[0]. El segundo elemento será la ruta al archivo JavaScript que se está ejecutando. Los elementos restantes serán cualquier argumento adicional de la línea de comandos.

Por ejemplo, asumiendo el siguiente script para process-args.js:

ESMCJS

import { argv } from 'node:process'

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

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

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

Lanzar el proceso de Node.js como:

bash

node process-args.js uno dos=tres cuatro

Generaría la salida:

text

0: /usr/local/bin/node
1: /Users/mjr/work/node/process-args.js
2: uno
3: dos=tres
4: cuatro

`process.argv0`

Agregado en: v6.4.0

<string>

La propiedad process.argv0 almacena una copia de solo lectura del valor original de argv[0] pasado cuando se inicia Node.js.

bash

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

`process.channel`

[Historial]

Versión	Cambios
v14.0.0	El objeto ya no expone accidentalmente los enlaces nativos de C++.
v7.1.0	Agregado en: v7.1.0

<Object>

Si el proceso de Node.js se generó con un canal IPC (ver la documentación de Proceso Hijo), la propiedad process.channel es una referencia al canal IPC. Si no existe un canal IPC, esta propiedad es undefined.

`process.channel.ref()`

Agregado en: v7.1.0

Este método hace que el canal IPC mantenga el bucle de eventos del proceso en ejecución si se ha llamado a .unref() antes.

Normalmente, esto se gestiona a través del número de listeners 'disconnect' y 'message' en el objeto process. Sin embargo, este método se puede utilizar para solicitar explícitamente un comportamiento específico.

`process.channel.unref()`

Agregado en: v7.1.0

Este método hace que el canal IPC no mantenga en ejecución el bucle de eventos del proceso y permite que termine incluso mientras el canal está abierto.

Normalmente, esto se gestiona a través del número de listeners de 'disconnect' y 'message' en el objeto process. Sin embargo, este método se puede usar para solicitar explícitamente un comportamiento específico.

`process.chdir(directorio)`

Agregado en: v0.1.17

directorio <string>

El método process.chdir() cambia el directorio de trabajo actual del proceso de Node.js o arroja una excepción si falla al hacerlo (por ejemplo, si el directorio especificado no existe).

ESMCJS

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

console.log(`Directorio de inicio: ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`Nuevo directorio: ${cwd()}`)
} catch (err) {
  console.error(`chdir: ${err}`)
}

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

console.log(`Directorio de inicio: ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`Nuevo directorio: ${cwd()}`)
} catch (err) {
  console.error(`chdir: ${err}`)
}

Esta característica no está disponible en los hilos Worker.

`process.config`

[Historial]

Versión	Cambios
v19.0.0	El objeto `process.config` ahora está congelado.
v16.0.0	Modificar process.config ha sido desaprobado.
v0.7.7	Añadido en: v0.7.7

<Object>

La propiedad process.config devuelve un Object congelado que contiene la representación en JavaScript de las opciones de configuración utilizadas para compilar el ejecutable actual de Node.js. Esto es lo mismo que el archivo config.gypi que se produjo al ejecutar el script ./configure.

Un ejemplo de la posible salida se ve así:

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

Agregado en: v0.7.2

<boolean>

Si el proceso de Node.js se genera con un canal IPC (consulta la documentación de Proceso Hijo y Cluster), la propiedad process.connected devolverá true siempre que el canal IPC esté conectado y devolverá false después de que se llame a process.disconnect().

Una vez que process.connected es false, ya no es posible enviar mensajes a través del canal IPC usando process.send().

`process.constrainedMemory()`

[Historial]

Versión	Cambios
v22.0.0, v20.13.0	Valor de retorno alineado con `uv_get_constrained_memory`.
v19.6.0, v18.15.0	Agregado en: v19.6.0, v18.15.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1 - Experimental

<number>

Obtiene la cantidad de memoria disponible para el proceso (en bytes) según los límites impuestos por el sistema operativo. Si no existe tal restricción, o se desconoce la restricción, se devuelve 0.

Consulta uv_get_constrained_memory para obtener más información.

`process.availableMemory()`

Agregado en: v22.0.0, v20.13.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1 - Experimental

<number>

Obtiene la cantidad de memoria libre que aún está disponible para el proceso (en bytes).

Consulta uv_get_available_memory para obtener más información.

`process.cpuUsage([previousValue])`

Agregado en: v6.1.0

previousValue <Object> Un valor de retorno anterior al llamar a process.cpuUsage()
Devuelve: <Object>
- user <integer>
- system <integer>

El método process.cpuUsage() devuelve el uso de tiempo de CPU de usuario y del sistema del proceso actual, en un objeto con las propiedades user y system, cuyos valores son valores de microsegundos (millonésima de segundo). Estos valores miden el tiempo empleado en el código de usuario y del sistema, respectivamente, y pueden llegar a ser mayores que el tiempo transcurrido real si varios núcleos de CPU están realizando trabajo para este proceso.

El resultado de una llamada anterior a process.cpuUsage() se puede pasar como argumento a la función, para obtener una lectura de diferencia.

ESMCJS

import { cpuUsage } from 'node:process'

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

// hacer girar la CPU durante 500 milisegundos
const now = Date.now()
while (Date.now() - now < 500);

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

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

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

// hacer girar la CPU durante 500 milisegundos
const now = Date.now()
while (Date.now() - now < 500);

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

`process.cwd()`

Añadido en: v0.1.8

Devuelve: <string>

El método process.cwd() devuelve el directorio de trabajo actual del proceso Node.js.

ESMCJS

import { cwd } from 'node:process'

console.log(`Directorio actual: ${cwd()}`)

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

console.log(`Directorio actual: ${cwd()}`)

`process.debugPort`

Añadido en: v0.7.2

<number>

El puerto utilizado por el depurador de Node.js cuando está habilitado.

ESMCJS

import process from 'node:process'

process.debugPort = 5858

const process = require('node:process')

process.debugPort = 5858

`process.disconnect()`

Añadido en: v0.7.2

Si el proceso de Node.js se genera con un canal IPC (consulta la documentación de Proceso Hijo y Clúster), el método process.disconnect() cerrará el canal IPC al proceso padre, permitiendo que el proceso hijo salga correctamente una vez que no haya otras conexiones que lo mantengan vivo.

El efecto de llamar a process.disconnect() es el mismo que llamar a ChildProcess.disconnect() desde el proceso padre.

Si el proceso de Node.js no se generó con un canal IPC, process.disconnect() será undefined.

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

[Historial]

Versión	Cambios
v9.0.0	Se agregó soporte para el argumento `flags`.
v0.1.16	Añadido en: v0.1.16

module <Objeto>
filename <cadena>
flags <os.constants.dlopen> Predeterminado: os.constants.dlopen.RTLD_LAZY

El método process.dlopen() permite la carga dinámica de objetos compartidos. Lo utiliza principalmente require() para cargar complementos de C++, y no debe utilizarse directamente, excepto en casos especiales. En otras palabras, se debe preferir require() a process.dlopen() a menos que existan razones específicas, como banderas personalizadas de dlopen o la carga desde módulos ES.

El argumento flags es un entero que permite especificar el comportamiento de dlopen. Consulta la documentación os.constants.dlopen para obtener más detalles.

Un requisito importante al llamar a process.dlopen() es que se debe pasar la instancia module. Las funciones exportadas por el complemento de C++ son accesibles a través de module.exports.

El siguiente ejemplo muestra cómo cargar un complemento de C++, llamado local.node, que exporta una función foo. Todos los símbolos se cargan antes de que la llamada retorne, pasando la constante RTLD_NOW. En este ejemplo, se asume que la constante está disponible.

ESMCJS

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

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

const { dlopen } = require('node:process')
const { constants } = require('node:os')
const { join } = require('node:path')

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

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

Añadido en: v8.0.0

warning <string> | <Error> La advertencia que se emitirá.
options <Object>
- type <string> Cuando warning es un String, type es el nombre que se utilizará para el tipo de advertencia que se está emitiendo. Predeterminado: 'Warning'.
- code <string> Un identificador único para la instancia de advertencia que se está emitiendo.
- ctor <Function> Cuando warning es un String, ctor es una función opcional que se utiliza para limitar el seguimiento de la pila generado. Predeterminado: process.emitWarning.
- detail <string> Texto adicional para incluir con el error.

El método process.emitWarning() se puede usar para emitir advertencias de proceso personalizadas o específicas de la aplicación. Estas pueden ser escuchadas añadiendo un controlador al evento 'warning'.

ESMCJS

import { emitWarning } from 'node:process'

// Emitir una advertencia con un código y detalles adicionales.
emitWarning('¡Algo pasó!', {
  code: 'MY_WARNING',
  detail: 'Esta es información adicional',
})
// Emite:
// (node:56338) [MY_WARNING] Advertencia: ¡Algo pasó!
// Esta es información adicional

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

// Emitir una advertencia con un código y detalles adicionales.
emitWarning('¡Algo pasó!', {
  code: 'MY_WARNING',
  detail: 'Esta es información adicional',
})
// Emite:
// (node:56338) [MY_WARNING] Advertencia: ¡Algo pasó!
// Esta es información adicional

En este ejemplo, process.emitWarning() genera internamente un objeto Error y lo pasa al controlador 'warning'.

ESMCJS

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // '¡Algo pasó!'
  console.warn(warning.code) // 'MY_WARNING'
  console.warn(warning.stack) // Seguimiento de la pila
  console.warn(warning.detail) // 'Esta es información adicional'
})

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // '¡Algo pasó!'
  console.warn(warning.code) // 'MY_WARNING'
  console.warn(warning.stack) // Seguimiento de la pila
  console.warn(warning.detail) // 'Esta es información adicional'
})

Si warning se pasa como un objeto Error, el argumento options se ignora.

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

Agregado en: v6.0.0

warning <string> | <Error> La advertencia a emitir.
type <string> Cuando warning es una String, type es el nombre a usar para el tipo de advertencia que se está emitiendo. Predeterminado: 'Warning'.
code <string> Un identificador único para la instancia de advertencia que se está emitiendo.
ctor <Function> Cuando warning es una String, ctor es una función opcional utilizada para limitar el rastreo de pila generado. Predeterminado: process.emitWarning.

El método process.emitWarning() se puede usar para emitir advertencias de proceso personalizadas o específicas de la aplicación. Se puede escuchar estas añadiendo un controlador al evento 'warning'.

ESMCJS

import { emitWarning } from 'node:process'

// Emitir una advertencia usando una cadena.
emitWarning('¡Algo sucedió!')
// Emite: (node: 56338) Warning: ¡Algo sucedió!

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

// Emitir una advertencia usando una cadena.
emitWarning('¡Algo sucedió!')
// Emite: (node: 56338) Warning: ¡Algo sucedió!

ESMCJS

import { emitWarning } from 'node:process'

// Emitir una advertencia usando una cadena y un tipo.
emitWarning('¡Algo sucedió!', 'CustomWarning')
// Emite: (node:56338) CustomWarning: ¡Algo sucedió!

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

// Emitir una advertencia usando una cadena y un tipo.
emitWarning('¡Algo sucedió!', 'CustomWarning')
// Emite: (node:56338) CustomWarning: ¡Algo sucedió!

ESMCJS

import { emitWarning } from 'node:process'

emitWarning('¡Algo sucedió!', 'CustomWarning', 'WARN001')
// Emite: (node:56338) [WARN001] CustomWarning: ¡Algo sucedió!

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

process.emitWarning('¡Algo sucedió!', 'CustomWarning', 'WARN001')
// Emite: (node:56338) [WARN001] CustomWarning: ¡Algo sucedió!

En cada uno de los ejemplos anteriores, process.emitWarning() genera internamente un objeto Error y lo pasa al controlador 'warning'.

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Si warning se pasa como un objeto Error, se pasará al controlador de eventos 'warning' sin modificar (y los argumentos opcionales type, code y ctor se ignorarán):

ESMCJS

import { emitWarning } from 'node:process'

// Emitir una advertencia usando un objeto Error.
const myWarning = new Error('¡Algo sucedió!')
// Usar la propiedad name del Error para especificar el nombre del tipo
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// Emite: (node:56338) [WARN001] CustomWarning: ¡Algo sucedió!

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

// Emitir una advertencia usando un objeto Error.
const myWarning = new Error('¡Algo sucedió!')
// Usar la propiedad name del Error para especificar el nombre del tipo
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// Emite: (node:56338) [WARN001] CustomWarning: ¡Algo sucedió!

Se genera un TypeError si warning es algo que no sea una cadena o un objeto Error.

Si bien las advertencias de proceso usan objetos Error, el mecanismo de advertencia de proceso no es un reemplazo para los mecanismos normales de manejo de errores.

El siguiente manejo adicional se implementa si el type de la advertencia es 'DeprecationWarning':

Si se usa la bandera de la línea de comandos --throw-deprecation, la advertencia de obsolescencia se arroja como una excepción en lugar de emitirse como un evento.
Si se usa la bandera de la línea de comandos --no-deprecation, la advertencia de obsolescencia se suprime.
Si se usa la bandera de la línea de comandos --trace-deprecation, la advertencia de obsolescencia se imprime en stderr junto con el rastreo de pila completo.

Evitar advertencias duplicadas

Como práctica recomendada, las advertencias deben emitirse solo una vez por proceso. Para ello, coloca emitWarning() detrás de un booleano.

ESMCJS

import { emitWarning } from 'node:process'

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('¡Solo advertir una vez!')
  }
}
emitMyWarning()
// Emite: (node: 56339) Warning: ¡Solo advertir una vez!
emitMyWarning()
// No emite nada

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

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('¡Solo advertir una vez!')
  }
}
emitMyWarning()
// Emite: (node: 56339) Warning: ¡Solo advertir una vez!
emitMyWarning()
// No emite nada

`process.env`

[Historial]

Versión	Cambios
v11.14.0	Los subprocesos de Worker ahora usarán una copia de `process.env` del hilo principal de forma predeterminada, configurable a través de la opción `env` del constructor `Worker`.
v10.0.0	La conversión implícita del valor de la variable a cadena está obsoleta.
v0.1.27	Añadido en: v0.1.27

<Object>

La propiedad process.env devuelve un objeto que contiene el entorno del usuario. Consulta environ(7).

Un ejemplo de este objeto se ve así:

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

Es posible modificar este objeto, pero tales modificaciones no se reflejarán fuera del proceso de Node.js, o (a menos que se solicite explícitamente) a otros hilos de Worker. En otras palabras, el siguiente ejemplo no funcionaría:

bash

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

Mientras que el siguiente sí:

ESMCJS

import { env } from 'node:process'

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

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

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

Asignar una propiedad en process.env convertirá implícitamente el valor a una cadena. Este comportamiento está obsoleto. Las versiones futuras de Node.js pueden arrojar un error cuando el valor no sea una cadena, número o booleano.

ESMCJS

import { env } from 'node:process'

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

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

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

Usa delete para eliminar una propiedad de process.env.

ESMCJS

import { env } from 'node:process'

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

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

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

En los sistemas operativos Windows, las variables de entorno no distinguen entre mayúsculas y minúsculas.

ESMCJS

import { env } from 'node:process'

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

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

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

A menos que se especifique explícitamente al crear una instancia de Worker, cada hilo de Worker tiene su propia copia de process.env, basada en el process.env de su hilo principal, o en lo que se especificó como la opción env para el constructor de Worker. Los cambios en process.env no serán visibles en los hilos de Worker, y solo el hilo principal puede realizar cambios que sean visibles para el sistema operativo o para los complementos nativos. En Windows, una copia de process.env en una instancia de Worker opera de manera sensible a mayúsculas y minúsculas, a diferencia del hilo principal.

`process.execArgv`

Agregado en: v0.7.7

<string[]>

La propiedad process.execArgv devuelve el conjunto de opciones de línea de comandos específicas de Node.js pasadas cuando se inició el proceso de Node.js. Estas opciones no aparecen en la matriz devuelta por la propiedad process.argv, y no incluyen el ejecutable de Node.js, el nombre del script o cualquier opción que siga al nombre del script. Estas opciones son útiles para generar procesos secundarios con el mismo entorno de ejecución que el padre.

bash

node --icu-data-dir=./foo --require ./bar.js script.js --version

Resulta en process.execArgv:

json

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

Y process.argv:

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

Consulte el constructor Worker para obtener el comportamiento detallado de los hilos de trabajo con esta propiedad.

`process.execPath`

Añadido en: v0.1.100

<string>

La propiedad process.execPath devuelve la ruta absoluta del ejecutable que inició el proceso de Node.js. Los enlaces simbólicos, si los hay, se resuelven.

'/usr/local/bin/node'

`process.exit([code])`

[Historial]

Versión	Cambios
v20.0.0	Solo acepta un código de tipo número, o de tipo cadena si representa un entero.
v0.1.13	Añadido en: v0.1.13

code <integer> | <string> | <null> | <undefined> El código de salida. Para el tipo de cadena, solo se permiten cadenas de enteros (p. ej., '1'). Predeterminado: 0.

El método process.exit() le indica a Node.js que termine el proceso de forma sincrónica con un estado de salida de code. Si se omite code, exit usa el código de 'éxito' 0 o el valor de process.exitCode si se ha establecido. Node.js no terminará hasta que se llamen todos los listeners del evento 'exit'.

Para salir con un código de 'fallo':

ESMCJS

import { exit } from 'node:process'

exit(1)

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

exit(1)

La shell que ejecutó Node.js debería ver el código de salida como 1.

Llamar a process.exit() forzará la salida del proceso lo más rápido posible, incluso si todavía hay operaciones asíncronas pendientes que aún no se han completado por completo, incluidas las operaciones de E/S a process.stdout y process.stderr.

En la mayoría de las situaciones, en realidad no es necesario llamar a process.exit() explícitamente. El proceso de Node.js saldrá por sí solo si no hay trabajo adicional pendiente en el bucle de eventos. La propiedad process.exitCode se puede establecer para indicar al proceso qué código de salida usar cuando el proceso finalice correctamente.

Por ejemplo, el siguiente ejemplo ilustra un uso incorrecto del método process.exit() que podría provocar que los datos impresos en stdout se trunquen y se pierdan:

ESMCJS

import { exit } from 'node:process'

// Este es un ejemplo de lo que *no* se debe hacer:
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

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

// Este es un ejemplo de lo que *no* se debe hacer:
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

La razón por la que esto es problemático es porque las escrituras en process.stdout en Node.js son a veces asíncronas y pueden ocurrir en varios ciclos del bucle de eventos de Node.js. Sin embargo, llamar a process.exit() fuerza la salida del proceso antes de que se puedan realizar esas escrituras adicionales en stdout.

En lugar de llamar a process.exit() directamente, el código debería establecer process.exitCode y permitir que el proceso finalice de forma natural evitando programar cualquier trabajo adicional para el bucle de eventos:

ESMCJS

import process from 'node:process'

// Cómo establecer correctamente el código de salida y permitir
// que el proceso salga correctamente.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

const process = require('node:process')

// Cómo establecer correctamente el código de salida y permitir
// que el proceso salga correctamente.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

Si es necesario terminar el proceso de Node.js debido a una condición de error, lanzar un error no detectado y permitir que el proceso termine en consecuencia es más seguro que llamar a process.exit().

En los hilos Worker, esta función detiene el hilo actual en lugar del proceso actual.

`process.exitCode`

[Historial]

Versión	Cambios
v20.0.0	Solo acepta un código de tipo número, o de tipo cadena si representa un entero.
v0.11.8	Añadido en: v0.11.8

<integer> | <string> | <null> | <undefined> El código de salida. Para el tipo de cadena, solo se permiten cadenas de enteros (por ejemplo, '1'). Predeterminado: undefined.

Un número que será el código de salida del proceso, cuando el proceso termina correctamente o termina a través de process.exit() sin especificar un código.

Especificar un código para process.exit(code) sobrescribirá cualquier configuración previa de process.exitCode.

`process.features.cached_builtins`

Añadido en: v12.0.0

<boolean>

Un valor booleano que es true si la compilación actual de Node.js está almacenando en caché los módulos incorporados.

`process.features.debug`

Añadido en: v0.5.5

<boolean>

Un valor booleano que es true si la compilación actual de Node.js es una compilación de depuración.

`process.features.inspector`

Añadido en: v11.10.0

<boolean>

Un valor booleano que es true si la compilación actual de Node.js incluye el inspector.

`process.features.ipv6`

Añadido en: v0.5.3

Obsoleto desde: v23.4.0

[Estable: 0 - Obsoleto]

Estable: 0 Estabilidad: 0 - Obsoleto. Esta propiedad siempre es verdadera, y cualquier verificación basada en ella es redundante.

<boolean>

Un valor booleano que es true si la compilación actual de Node.js incluye soporte para IPv6.

Dado que todas las compilaciones de Node.js tienen soporte para IPv6, este valor siempre es true.

`process.features.require_module`

Agregado en: v23.0.0

<boolean>

Un valor booleano que es true si la compilación actual de Node.js admite cargar módulos ECMAScript usando require().

`process.features.tls`

Agregado en: v0.5.3

<boolean>

Un valor booleano que es true si la compilación actual de Node.js incluye soporte para TLS.

`process.features.tls_alpn`

Agregado en: v4.8.0

Obsoleto desde: v23.4.0

[Estable: 0 - Obsoleto]

Estable: 0 Estabilidad: 0 - Obsoleto. Utilice process.features.tls en su lugar.

<boolean>

Un valor booleano que es true si la compilación actual de Node.js incluye soporte para ALPN en TLS.

En Node.js 11.0.0 y versiones posteriores, las dependencias de OpenSSL incluyen soporte incondicional para ALPN. Por lo tanto, este valor es idéntico al de process.features.tls.

`process.features.tls_ocsp`

Añadido en: v0.11.13

Obsoleto desde: v23.4.0

[Estable: 0 - Obsoleto]

Estable: 0 Estabilidad: 0 - Obsoleto. Use process.features.tls en su lugar.

<boolean>

Un valor booleano que es true si la compilación actual de Node.js incluye soporte para OCSP en TLS.

En Node.js 11.0.0 y versiones posteriores, las dependencias de OpenSSL incluyen soporte incondicional para OCSP. Por lo tanto, este valor es idéntico al de process.features.tls.

`process.features.tls_sni`

Añadido en: v0.5.3

Obsoleto desde: v23.4.0

[Estable: 0 - Obsoleto]

Estable: 0 Estabilidad: 0 - Obsoleto. Use process.features.tls en su lugar.

<boolean>

Un valor booleano que es true si la compilación actual de Node.js incluye soporte para SNI en TLS.

En Node.js 11.0.0 y versiones posteriores, las dependencias de OpenSSL incluyen soporte incondicional para SNI. Por lo tanto, este valor es idéntico al de process.features.tls.

`process.features.typescript`

Agregado en: v23.0.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1.1 - Desarrollo activo

<boolean> | <string>

Un valor que es "strip" si Node.js se ejecuta con --experimental-strip-types, "transform" si Node.js se ejecuta con --experimental-transform-types, y false de lo contrario.

`process.features.uv`

Agregado en: v0.5.3

Obsoleto desde: v23.4.0

[Estable: 0 - Obsoleto]

Estable: 0 Estabilidad: 0 - Obsoleto. Esta propiedad siempre es verdadera, y cualquier verificación basada en ella es redundante.

<boolean>

Un valor booleano que es true si la compilación actual de Node.js incluye soporte para libuv.

Dado que no es posible construir Node.js sin libuv, este valor siempre es true.

`process.finalization.register(ref, callback)`

Agregado en: v22.5.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1.1 - Desarrollo Activo

ref <Object> | <Function> La referencia al recurso que se está rastreando.
callback <Function> La función de callback que se llamará cuando se finalice el recurso.
- ref <Object> | <Function> La referencia al recurso que se está rastreando.
- event <string> El evento que activó la finalización. El valor predeterminado es 'exit'.

Esta función registra una callback para ser llamada cuando el proceso emita el evento exit si el objeto ref no fue recolectado por el recolector de basura. Si el objeto ref fue recolectado por el recolector de basura antes de que se emita el evento exit, la callback será eliminada del registro de finalización y no se llamará al salir del proceso.

Dentro de la callback puedes liberar los recursos asignados por el objeto ref. Ten en cuenta que todas las limitaciones aplicadas al evento beforeExit también se aplican a la función callback, esto significa que existe la posibilidad de que la callback no se llame en circunstancias especiales.

La idea de esta función es ayudarte a liberar recursos cuando el proceso comienza a salir, pero también permitir que el objeto sea recolectado por el recolector de basura si ya no se está utilizando.

Por ejemplo: puedes registrar un objeto que contenga un búfer, quieres asegurarte de que el búfer se libere cuando el proceso salga, pero si el objeto es recolectado por el recolector de basura antes de que el proceso salga, ya no necesitamos liberar el búfer, por lo que en este caso simplemente eliminamos la callback del registro de finalización.

CJSESM

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

// Por favor, asegúrate de que la función pasada a finalization.register()
// no cree un cierre alrededor de objetos innecesarios.
function onFinalize(obj, event) {
  // Puedes hacer lo que quieras con el objeto
  obj.dispose()
}

function setup() {
  // Este objeto puede ser recolectado por el recolector de basura de forma segura,
  // y la función de apagado resultante no será llamada.
  // No hay fugas.
  const myDisposableObject = {
    dispose() {
      // Libera tus recursos de forma síncrona
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

import { finalization } from 'node:process'

// Por favor, asegúrate de que la función pasada a finalization.register()
// no cree un cierre alrededor de objetos innecesarios.
function onFinalize(obj, event) {
  // Puedes hacer lo que quieras con el objeto
  obj.dispose()
}

function setup() {
  // Este objeto puede ser recolectado por el recolector de basura de forma segura,
  // y la función de apagado resultante no será llamada.
  // No hay fugas.
  const myDisposableObject = {
    dispose() {
      // Libera tus recursos de forma síncrona
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

El código anterior se basa en las siguientes suposiciones:

se evitan las funciones de flecha
se recomienda que las funciones regulares estén dentro del contexto global (raíz)

Las funciones regulares podrían hacer referencia al contexto donde vive obj, haciendo que obj no sea recolectable por el recolector de basura.

Las funciones de flecha conservarán el contexto anterior. Considera, por ejemplo:

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

    // Incluso algo como esto está altamente desaconsejado
    // finalization.register(this, () => this.dispose());
  }
  dispose() {}
}

Es muy poco probable (no imposible) que este objeto sea recolectado por el recolector de basura, pero si no lo es, se llamará a dispose cuando se llame a process.exit.

Ten cuidado y evita depender de esta función para la eliminación de recursos críticos, ya que no está garantizado que se llame a la callback en todas las circunstancias.

`process.finalization.registerBeforeExit(ref, callback)`

Agregado en: v22.5.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1.1 - Desarrollo Activo

ref <Objeto> | <Función> La referencia al recurso que se está rastreando.
callback <Función> La función de callback que se llamará cuando el recurso se finalice.
- ref <Objeto> | <Función> La referencia al recurso que se está rastreando.
- event <string> El evento que desencadenó la finalización. El valor predeterminado es 'beforeExit'.

Esta función se comporta exactamente igual que register, excepto que la función de callback se llamará cuando el proceso emita el evento beforeExit si el objeto ref no fue recolectado por el recolector de basura.

Tenga en cuenta que todas las limitaciones aplicadas al evento beforeExit también se aplican a la función callback, esto significa que existe la posibilidad de que la función de callback no se llame bajo circunstancias especiales.

`process.finalization.unregister(ref)`

Agregado en: v22.5.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1.1 - Desarrollo Activo

ref <Objeto> | <Función> La referencia al recurso que se registró previamente.

Esta función elimina el registro del objeto del registro de finalización, por lo que la función de devolución de llamada ya no se invocará.

CJSESM

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

// Asegúrese de que la función pasada a finalization.register()
// no cree un cierre alrededor de objetos innecesarios.
function onFinalize(obj, event) {
  // Puede hacer lo que quiera con el objeto
  obj.dispose()
}

function setup() {
  // Este objeto puede recolectarse basura de forma segura,
  // y la función de cierre resultante no se llamará.
  // No hay fugas.
  const myDisposableObject = {
    dispose() {
      // Libere sus recursos de forma síncrona
    },
  }

  finalization.register(myDisposableObject, onFinalize)

  // Hacer algo

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

setup()

import { finalization } from 'node:process'

// Asegúrese de que la función pasada a finalization.register()
// no cree un cierre alrededor de objetos innecesarios.
function onFinalize(obj, event) {
  // Puede hacer lo que quiera con el objeto
  obj.dispose()
}

function setup() {
  // Este objeto puede recolectarse basura de forma segura,
  // y la función de cierre resultante no se llamará.
  // No hay fugas.
  const myDisposableObject = {
    dispose() {
      // Libere sus recursos de forma síncrona
    },
  }

  // Asegúrese de que la función pasada a finalization.register()
  // no cree un cierre alrededor de objetos innecesarios.
  function onFinalize(obj, event) {
    // Puede hacer lo que quiera con el objeto
    obj.dispose()
  }

  finalization.register(myDisposableObject, onFinalize)

  // Hacer algo

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

setup()

`process.getActiveResourcesInfo()`

Agregado en: v17.3.0, v16.14.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1 - Experimental

Devuelve: <string[]>

El método process.getActiveResourcesInfo() devuelve un array de cadenas que contienen los tipos de los recursos activos que actualmente mantienen vivo el bucle de eventos.

ESMCJS

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

console.log('Antes:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('Después:', getActiveResourcesInfo())
// Imprime:
//   Antes: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   Después: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

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

console.log('Antes:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('Después:', getActiveResourcesInfo())
// Imprime:
//   Antes: [ 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   Después: [ 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

`process.getBuiltinModule(id)`

Añadido en: v22.3.0, v20.16.0

id <string> ID del módulo incorporado que se solicita.
Devuelve: <Object> | <undefined>

process.getBuiltinModule(id) proporciona una forma de cargar módulos incorporados en una función disponible globalmente. Los módulos ES que necesitan admitir otros entornos pueden usarlo para cargar condicionalmente un módulo incorporado de Node.js cuando se ejecuta en Node.js, sin tener que lidiar con el error de resolución que puede generar import en un entorno que no sea Node.js o tener que usar import() dinámico que convierte el módulo en un módulo asíncrono, o convierte una API síncrona en una asíncrona.

if (globalThis.process?.getBuiltinModule) {
  // Ejecutar en Node.js, usar el módulo fs de Node.js.
  const fs = globalThis.process.getBuiltinModule('fs')
  // Si se necesita `require()` para cargar módulos de usuario, usar createRequire()
  const module = globalThis.process.getBuiltinModule('module')
  const require = module.createRequire(import.meta.url)
  const foo = require('foo')
}

Si id especifica un módulo incorporado disponible en el proceso actual de Node.js, el método process.getBuiltinModule(id) devuelve el módulo incorporado correspondiente. Si id no corresponde a ningún módulo incorporado, se devuelve undefined.

process.getBuiltinModule(id) acepta IDs de módulos incorporados que son reconocidos por module.isBuiltin(id). Algunos módulos incorporados deben cargarse con el prefijo node:, ver módulos incorporados con el prefijo node: obligatorio. Las referencias devueltas por process.getBuiltinModule(id) siempre apuntan al módulo incorporado correspondiente a id, incluso si los usuarios modifican require.cache de modo que require(id) devuelve otra cosa.

`process.getegid()`

Agregado en: v2.0.0

El método process.getegid() devuelve la identidad numérica efectiva del grupo del proceso Node.js. (Ver getegid(2).)

ESMCJS

import process from 'node:process'

if (process.getegid) {
  console.log(`GID actual: ${process.getegid()}`)
}

const process = require('node:process')

if (process.getegid) {
  console.log(`GID actual: ${process.getegid()}`)
}

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android).

`process.geteuid()`

Agregado en: v2.0.0

Devuelve: <Object>

El método process.geteuid() devuelve la identidad numérica efectiva del usuario del proceso. (Ver geteuid(2).)

ESMCJS

import process from 'node:process'

if (process.geteuid) {
  console.log(`UID actual: ${process.geteuid()}`)
}

const process = require('node:process')

if (process.geteuid) {
  console.log(`UID actual: ${process.geteuid()}`)
}

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android).

`process.getgid()`

Agregado en: v0.1.31

Devuelve: <Objeto>

El método process.getgid() devuelve la identidad numérica del grupo del proceso. (Ver getgid(2).)

ESMCJS

import process from 'node:process'

if (process.getgid) {
  console.log(`GID actual: ${process.getgid()}`)
}

const process = require('node:process')

if (process.getgid) {
  console.log(`GID actual: ${process.getgid()}`)
}

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android).

`process.getgroups()`

Agregado en: v0.9.4

Devuelve: <integer[]>

El método process.getgroups() devuelve un array con los IDs de grupo suplementarios. POSIX deja sin especificar si el ID de grupo efectivo está incluido, pero Node.js asegura que siempre lo esté.

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android).

`process.getuid()`

Agregado en: v0.1.28

Devuelve: <entero>

El método process.getuid() devuelve la identidad numérica del usuario del proceso. (Ver getuid(2).)

ESMCJS

import process from 'node:process'

if (process.getuid) {
  console.log(`UID actual: ${process.getuid()}`)
}

const process = require('node:process')

if (process.getuid) {
  console.log(`UID actual: ${process.getuid()}`)
}

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android).

`process.hasUncaughtExceptionCaptureCallback()`

Agregado en: v9.3.0

Devuelve: <booleano>

Indica si se ha establecido una devolución de llamada utilizando process.setUncaughtExceptionCaptureCallback().

`process.hrtime([time])`

Añadido en: v0.7.6

[Estable: 3 - Legado]

Estable: 3 Estabilidad: 3 - Legado. Utilice process.hrtime.bigint() en su lugar.

time <integer[]> El resultado de una llamada anterior a process.hrtime()
Devuelve: <integer[]>

Esta es la versión heredada de process.hrtime.bigint() antes de que se introdujera bigint en JavaScript.

El método process.hrtime() devuelve la hora real de alta resolución actual en una Array de tuplas [segundos, nanosegundos], donde nanosegundos es la parte restante de la hora real que no se puede representar en precisión de segundos.

time es un parámetro opcional que debe ser el resultado de una llamada anterior a process.hrtime() para diferenciar con la hora actual. Si el parámetro pasado no es una Array de tuplas, se lanzará un TypeError. Pasar un array definido por el usuario en lugar del resultado de una llamada anterior a process.hrtime() conducirá a un comportamiento indefinido.

Estos tiempos son relativos a un tiempo arbitrario en el pasado, y no están relacionados con la hora del día y, por lo tanto, no están sujetos a la deriva del reloj. El uso principal es para medir el rendimiento entre intervalos:

ESMCJS

import { hrtime } from 'node:process'

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

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

  console.log(`El benchmark tardó ${diff[0] * NS_POR_SEC + diff[1]} nanosegundos`)
  // El benchmark tardó 1000000552 nanosegundos
}, 1000)

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

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

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

  console.log(`El benchmark tardó ${diff[0] * NS_POR_SEC + diff[1]} nanosegundos`)
  // El benchmark tardó 1000000552 nanosegundos
}, 1000)

`process.hrtime.bigint()`

Añadido en: v10.7.0

Devuelve: <bigint>

La versión bigint del método process.hrtime() que devuelve el tiempo real de alta resolución actual en nanosegundos como un bigint.

A diferencia de process.hrtime(), no admite un argumento time adicional, ya que la diferencia se puede calcular directamente restando los dos bigint.

ESMCJS

import { hrtime } from 'node:process'

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

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

  console.log(`El benchmark tardó ${end - start} nanosegundos`)
  // El benchmark tardó 1154389282 nanosegundos
}, 1000)

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

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

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

  console.log(`El benchmark tardó ${end - start} nanosegundos`)
  // El benchmark tardó 1154389282 nanosegundos
}, 1000)

`process.initgroups(user, extraGroup)`

Añadido en: v0.9.4

user <string> | <number> El nombre de usuario o identificador numérico.
extraGroup <string> | <number> Un nombre de grupo o identificador numérico.

El método process.initgroups() lee el archivo /etc/group e inicializa la lista de acceso al grupo, utilizando todos los grupos de los que el usuario es miembro. Esta es una operación privilegiada que requiere que el proceso de Node.js tenga acceso root o la capacidad CAP_SETGID.

Tenga cuidado al eliminar privilegios:

ESMCJS

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

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // cambiar usuario
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // eliminar gid raíz
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

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

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // cambiar usuario
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // eliminar gid raíz
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android). Esta función no está disponible en los hilos Worker.

`process.kill(pid[, señal])`

Añadido en: v0.0.6

pid <número> Un ID de proceso
señal <cadena> | <número> La señal a enviar, ya sea como una cadena o número. Predeterminado: 'SIGTERM'.

El método process.kill() envía la señal al proceso identificado por pid.

Los nombres de las señales son cadenas como 'SIGINT' o 'SIGHUP'. Consulta Eventos de Señal y kill(2) para obtener más información.

Este método arrojará un error si el pid objetivo no existe. Como caso especial, se puede usar una señal de 0 para probar la existencia de un proceso. Las plataformas de Windows arrojarán un error si el pid se usa para eliminar un grupo de procesos.

Aunque el nombre de esta función es process.kill(), en realidad es solo un remitente de señales, como la llamada al sistema kill. La señal enviada puede hacer algo diferente a eliminar el proceso objetivo.

ESMCJS

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

process.on('SIGHUP', () => {
  console.log('Recibida señal SIGHUP.')
})

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

kill(process.pid, 'SIGHUP')

const process = require('node:process')

process.on('SIGHUP', () => {
  console.log('Recibida señal SIGHUP.')
})

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

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

Cuando un proceso de Node.js recibe SIGUSR1, Node.js iniciará el depurador. Consulta Eventos de Señal.

`process.loadEnvFile(path)`

Añadido en: v21.7.0, v20.12.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1.1 - Desarrollo activo

path <string> | <URL> | <Buffer> | <undefined>. Predeterminado: './.env'

Carga el archivo .env en process.env. El uso de NODE_OPTIONS en el archivo .env no tendrá ningún efecto en Node.js.

CJSESM

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

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

`process.mainModule`

Añadido en: v0.1.17

Obsoleto desde: v14.0.0

[Estable: 0 - Obsoleto]

Estable: 0 Estabilidad: 0 - Obsoleto: Use require.main en su lugar.

<Objeto>

La propiedad process.mainModule proporciona una forma alternativa de recuperar require.main. La diferencia es que si el módulo principal cambia en tiempo de ejecución, require.main aún puede referirse al módulo principal original en los módulos que se requirieron antes de que se produjera el cambio. Generalmente, es seguro asumir que los dos se refieren al mismo módulo.

Al igual que con require.main, process.mainModule será undefined si no hay un script de entrada.

`process.memoryUsage()`

[Historial]

Versión	Cambios
v13.9.0, v12.17.0	Se agregó `arrayBuffers` al objeto devuelto.
v7.2.0	Se agregó `external` al objeto devuelto.
v0.1.16	Agregado en: v0.1.16

Devuelve: <Object>
- rss <integer>
- heapTotal <integer>
- heapUsed <integer>
- external <integer>
- arrayBuffers <integer>

Devuelve un objeto que describe el uso de memoria del proceso de Node.js medido en bytes.

ESMCJS

import { memoryUsage } from 'node:process'

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

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

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

heapTotal y heapUsed se refieren al uso de memoria de V8.
external se refiere al uso de memoria de los objetos C++ vinculados a los objetos JavaScript administrados por V8.
rss, Resident Set Size, es la cantidad de espacio ocupado en la memoria principal (que es un subconjunto de la memoria total asignada) para el proceso, incluidos todos los objetos y el código C++ y JavaScript.
arrayBuffers se refiere a la memoria asignada para ArrayBuffers y SharedArrayBuffers, incluidos todos los Buffers de Node.js. Esto también está incluido en el valor external. Cuando Node.js se utiliza como biblioteca integrada, este valor puede ser 0 porque en ese caso es posible que las asignaciones para ArrayBuffers no se rastreen.

Al usar hilos Worker, rss será un valor que sea válido para todo el proceso, mientras que los otros campos solo se referirán al hilo actual.

El método process.memoryUsage() itera sobre cada página para recopilar información sobre el uso de la memoria, lo que podría ser lento según las asignaciones de memoria del programa.

`process.memoryUsage.rss()`

Agregado en: v15.6.0, v14.18.0

Retorna: <integer>

El método process.memoryUsage.rss() retorna un entero que representa el Resident Set Size (RSS) en bytes.

El Resident Set Size, es la cantidad de espacio ocupado en la memoria principal (que es un subconjunto de la memoria total asignada) para el proceso, incluyendo todos los objetos y el código C++ y JavaScript.

Este es el mismo valor que la propiedad rss proporcionada por process.memoryUsage() pero process.memoryUsage.rss() es más rápido.

ESMCJS

import { memoryUsage } from 'node:process'

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

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

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

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

[Historial]

Versión	Cambios
v22.7.0, v20.18.0	Se cambió la estabilidad a Legacy.
v18.0.0	Pasar una devolución de llamada inválida al argumento `callback` ahora arroja `ERR_INVALID_ARG_TYPE` en lugar de `ERR_INVALID_CALLBACK`.
v1.8.1	Ahora se admiten argumentos adicionales después de `callback`.
v0.1.26	Agregado en: v0.1.26

[Estable: 3 - Legacy]

Estable: 3 Estabilidad: 3 - Legacy: Use queueMicrotask() en su lugar.

callback <Function>
...args <any> Argumentos adicionales para pasar al invocar callback

process.nextTick() añade callback a la "cola del siguiente ciclo". Esta cola se vacía completamente después de que la operación actual en la pila de JavaScript se ejecuta hasta completarse y antes de que se permita que el bucle de eventos continúe. Es posible crear un bucle infinito si se llama recursivamente a process.nextTick(). Consulta la guía Bucle de Eventos para obtener más información.

ESMCJS

import { nextTick } from 'node:process'

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

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

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

Esto es importante al desarrollar APIs para dar a los usuarios la oportunidad de asignar manejadores de eventos después de que un objeto ha sido construido pero antes de que ocurra cualquier E/S:

ESMCJS

import { nextTick } from 'node:process'

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

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

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

// thing.startDoingStuff() se llama ahora, no antes.

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

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

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

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

// thing.startDoingStuff() se llama ahora, no antes.

Es muy importante que las APIs sean 100% síncronas o 100% asíncronas. Considera este ejemplo:

// ¡ADVERTENCIA! ¡NO USAR! ¡PELIGRO INSEGURO MALO!
function maybeSync(arg, cb) {
  if (arg) {
    cb()
    return
  }

  fs.stat('file', cb)
}

Esta API es peligrosa porque en el siguiente caso:

const maybeTrue = Math.random() > 0.5

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

bar()

No está claro si se llamará primero a foo() o a bar().

El siguiente enfoque es mucho mejor:

ESMCJS

import { nextTick } from 'node:process'

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

  fs.stat('file', cb)
}

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

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

  fs.stat('file', cb)
}

Cuándo usar `queueMicrotask()` vs. `process.nextTick()`

La API queueMicrotask() es una alternativa a process.nextTick() que también aplaza la ejecución de una función utilizando la misma cola de microtareas utilizada para ejecutar los controladores then, catch y finally de promesas resueltas. Dentro de Node.js, cada vez que se agota la "cola del siguiente tick", la cola de microtareas se agota inmediatamente después.

ESMCJS

import { nextTick } from 'node:process'

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

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

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

Para la mayoría de los casos de uso en el espacio del usuario, la API queueMicrotask() proporciona un mecanismo portátil y confiable para diferir la ejecución que funciona en múltiples entornos de plataforma de JavaScript y debería preferirse a process.nextTick(). En escenarios simples, queueMicrotask() puede ser un reemplazo directo para process.nextTick().

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

Una diferencia notable entre las dos API es que process.nextTick() permite especificar valores adicionales que se pasarán como argumentos a la función diferida cuando se llame. Lograr el mismo resultado con queueMicrotask() requiere usar un cierre o una función vinculada:

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

Existen diferencias menores en la forma en que se manejan los errores generados desde dentro de la cola del siguiente tick y la cola de microtareas. Los errores lanzados dentro de una devolución de llamada de microtareas en cola deben manejarse dentro de la devolución de llamada en cola cuando sea posible. Si no lo son, el controlador de eventos process.on('uncaughtException') se puede usar para capturar y manejar los errores.

En caso de duda, a menos que se necesiten las capacidades específicas de process.nextTick(), use queueMicrotask().

`process.noDeprecation`

Añadido en: v0.8.0

<boolean>

La propiedad process.noDeprecation indica si el flag --no-deprecation está establecido en el proceso actual de Node.js. Consulta la documentación del evento 'warning' y el método emitWarning() para obtener más información sobre el comportamiento de este flag.

`process.permission`

Añadido en: v20.0.0

<Objeto>

Esta API está disponible a través del flag --permission.

process.permission es un objeto cuyos métodos se utilizan para gestionar los permisos del proceso actual. Se dispone de documentación adicional en el Modelo de Permisos.

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

Añadido en: v20.0.0

scope <string>
reference <string>
Devuelve: <boolean>

Verifica que el proceso pueda acceder al ámbito y la referencia dados. Si no se proporciona ninguna referencia, se asume un ámbito global, por ejemplo, process.permission.has('fs.read') comprobará si el proceso tiene TODOS los permisos de lectura del sistema de archivos.

La referencia tiene un significado basado en el ámbito proporcionado. Por ejemplo, la referencia cuando el ámbito es Sistema de Archivos significa archivos y carpetas.

Los ámbitos disponibles son:

fs - Todo el Sistema de Archivos
fs.read - Operaciones de lectura del Sistema de Archivos
fs.write - Operaciones de escritura del Sistema de Archivos
child - Operaciones de generación de procesos hijo
worker - Operación de generación de hilos de trabajador

// Comprueba si el proceso tiene permiso para leer el archivo README
process.permission.has('fs.read', './README.md')
// Comprueba si el proceso tiene operaciones de permiso de lectura
process.permission.has('fs.read')

`process.pid`

Agregado en: v0.1.15

<integer>

La propiedad process.pid devuelve el PID del proceso.

ESMCJS

import { pid } from 'node:process'

console.log(`Este proceso es pid ${pid}`)

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

console.log(`Este proceso es pid ${pid}`)

`process.platform`

Agregado en: v0.1.16

<string>

La propiedad process.platform devuelve una cadena que identifica la plataforma del sistema operativo para la que se compiló el binario de Node.js.

Los valores posibles actualmente son:

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

ESMCJS

import { platform } from 'node:process'

console.log(`Esta plataforma es ${platform}`)

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

console.log(`Esta plataforma es ${platform}`)

También se puede devolver el valor 'android' si Node.js está construido en el sistema operativo Android. Sin embargo, el soporte de Android en Node.js es experimental.

`process.ppid`

Agregado en: v9.2.0, v8.10.0, v6.13.0

<integer>

La propiedad process.ppid devuelve el PID del proceso padre del proceso actual.

ESMCJS

import { ppid } from 'node:process'

console.log(`El proceso padre es pid ${ppid}`)

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

console.log(`El proceso padre es pid ${ppid}`)

`process.release`

[Historial]

Versión	Cambios
v4.2.0	Ahora se soporta la propiedad `lts`.
v3.0.0	Agregado en: v3.0.0

<Object>

La propiedad process.release devuelve un Objeto que contiene metadatos relacionados con la versión actual, incluidas las URL del tarball de origen y el tarball solo de encabezados.

process.release contiene las siguientes propiedades:

name <string> Un valor que siempre será 'node'.
sourceUrl <string> una URL absoluta que apunta a un archivo .tar.gz que contiene el código fuente de la versión actual.
headersUrl<string> una URL absoluta que apunta a un archivo .tar.gz que contiene solo los archivos de encabezado de origen para la versión actual. Este archivo es significativamente más pequeño que el archivo de origen completo y se puede utilizar para compilar complementos nativos de Node.js.
libUrl <string> | <undefined> una URL absoluta que apunta a un archivo node.lib que coincide con la arquitectura y la versión de la versión actual. Este archivo se utiliza para compilar complementos nativos de Node.js. Esta propiedad solo está presente en las compilaciones de Windows de Node.js y faltará en todas las demás plataformas.
lts <string> | <undefined> una etiqueta de cadena que identifica la etiqueta LTS para esta versión. Esta propiedad solo existe para las versiones LTS y es undefined para todos los demás tipos de versiones, incluidas las versiones Actual. Los valores válidos incluyen los nombres de código de las versiones LTS (incluidos los que ya no son compatibles).
- 'Fermium' para la línea LTS 14.x que comienza con 14.15.0.
- 'Gallium' para la línea LTS 16.x que comienza con 16.13.0.
- 'Hydrogen' para la línea LTS 18.x que comienza con 18.12.0. Para otros nombres de código de las versiones LTS, consulte Archivo de registro de cambios de 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'
}

En compilaciones personalizadas de versiones no publicadas del árbol de origen, solo la propiedad name puede estar presente. No se debe confiar en la existencia de las propiedades adicionales.

`process.report`

[Historial]

Versión	Cambios
v13.12.0, v12.17.0	Esta API ya no es experimental.
v11.8.0	Añadido en: v11.8.0

<Object>

process.report es un objeto cuyos métodos se utilizan para generar informes de diagnóstico para el proceso actual. Documentación adicional está disponible en la documentación del informe.

`process.report.compact`

Añadido en: v13.12.0, v12.17.0

<boolean>

Escribe informes en un formato compacto, JSON de una sola línea, más fácilmente consumible por los sistemas de procesamiento de registros que el formato predeterminado de varias líneas diseñado para el consumo humano.

ESMCJS

import { report } from 'node:process'

console.log(`¿Los informes son compactos? ${report.compact}`)

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

console.log(`¿Los informes son compactos? ${report.compact}`)

`process.report.directory`

[Historial]

Versión	Cambios
v13.12.0, v12.17.0	Esta API ya no es experimental.
v11.12.0	Añadido en: v11.12.0

<string>

Directorio donde se escribe el informe. El valor predeterminado es la cadena vacía, lo que indica que los informes se escriben en el directorio de trabajo actual del proceso de Node.js.

ESMCJS

import { report } from 'node:process'

console.log(`El directorio del informe es ${report.directory}`)

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

console.log(`El directorio del informe es ${report.directory}`)

`process.report.filename`

[Historial]

Versión	Cambios
v13.12.0, v12.17.0	Esta API ya no es experimental.
v11.12.0	Añadido en: v11.12.0

<string>

Nombre de archivo donde se escribe el informe. Si se establece en la cadena vacía, el nombre de archivo de salida estará compuesto por una marca de tiempo, PID y número de secuencia. El valor predeterminado es la cadena vacía.

Si el valor de process.report.filename se establece en 'stdout' o 'stderr', el informe se escribe en el stdout o stderr del proceso respectivamente.

ESMCJS

import { report } from 'node:process'

console.log(`El nombre de archivo del informe es ${report.filename}`)

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

console.log(`El nombre de archivo del informe es ${report.filename}`)

`process.report.getReport([err])`

[Historial]

Versión	Cambios
v13.12.0, v12.17.0	Esta API ya no es experimental.
v11.8.0	Añadido en: v11.8.0

err <Error> Un error personalizado utilizado para informar de la pila de JavaScript.
Devuelve: <Object>

Devuelve una representación de Objeto de JavaScript de un informe de diagnóstico para el proceso en ejecución. El rastreo de pila de JavaScript del informe se toma de err, si está presente.

ESMCJS

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

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

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

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

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

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

Hay documentación adicional disponible en la documentación del informe.

`process.report.reportOnFatalError`

[Historial]

Versión	Cambios
v15.0.0, v14.17.0	Esta API ya no es experimental.
v11.12.0	Añadido en: v11.12.0

<boolean>

Si es true, se genera un informe de diagnóstico en errores fatales, como errores de falta de memoria o aserciones de C++ fallidas.

ESMCJS

import { report } from 'node:process'

console.log(`Informe en error fatal: ${report.reportOnFatalError}`)

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

console.log(`Informe en error fatal: ${report.reportOnFatalError}`)

`process.report.reportOnSignal`

[Historial]

Versión	Cambios
v13.12.0, v12.17.0	Esta API ya no es experimental.
v11.12.0	Añadido en: v11.12.0

<boolean>

Si es true, se genera un informe de diagnóstico cuando el proceso recibe la señal especificada por process.report.signal.

ESMCJS

import { report } from 'node:process'

console.log(`Informe en señal: ${report.reportOnSignal}`)

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

console.log(`Informe en señal: ${report.reportOnSignal}`)

`process.report.reportOnUncaughtException`

[Historial]

Versión	Cambios
v13.12.0, v12.17.0	Esta API ya no es experimental.
v11.12.0	Añadido en: v11.12.0

<boolean>

Si es true, se genera un informe de diagnóstico en caso de excepción no capturada.

ESMCJS

import { report } from 'node:process'

console.log(`Informe en caso de excepción: ${report.reportOnUncaughtException}`)

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

console.log(`Informe en caso de excepción: ${report.reportOnUncaughtException}`)

`process.report.excludeEnv`

Añadido en: v23.3.0

<boolean>

Si es true, se genera un informe de diagnóstico sin las variables de entorno.

`process.report.signal`

[Historial]

Versión	Cambios
v13.12.0, v12.17.0	Esta API ya no es experimental.
v11.12.0	Añadido en: v11.12.0

<string>

La señal utilizada para activar la creación de un informe de diagnóstico. El valor predeterminado es 'SIGUSR2'.

ESMCJS

import { report } from 'node:process'

console.log(`Señal del informe: ${report.signal}`)

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

console.log(`Señal del informe: ${report.signal}`)

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

[Historial]

Versión	Cambios
v13.12.0, v12.17.0	Esta API ya no es experimental.
v11.8.0	Añadido en: v11.8.0

filename <string> Nombre del archivo donde se escribe el informe. Esto debería ser una ruta relativa, que se anexará al directorio especificado en process.report.directory, o el directorio de trabajo actual del proceso de Node.js, si no se especifica.
err <Error> Un error personalizado utilizado para informar de la pila de JavaScript.
Retorna: <string> Retorna el nombre del archivo del informe generado.

Escribe un informe de diagnóstico en un archivo. Si no se proporciona filename, el nombre de archivo predeterminado incluye la fecha, la hora, el PID y un número de secuencia. El rastreo de pila de JavaScript del informe se toma de err, si está presente.

Si el valor de filename se establece en 'stdout' o 'stderr', el informe se escribe en stdout o stderr del proceso respectivamente.

ESMCJS

import { report } from 'node:process'

report.writeReport()

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

report.writeReport()

Documentación adicional disponible en la documentación del informe.

`process.resourceUsage()`

Añadido en: v12.6.0

Devuelve: <Objeto> el uso de recursos para el proceso actual. Todos estos valores provienen de la llamada uv_getrusage que devuelve una uv_rusage_t struct.
- userCPUTime <entero> se asigna a ru_utime calculado en microsegundos. Es el mismo valor que process.cpuUsage().user.
- systemCPUTime <entero> se asigna a ru_stime calculado en microsegundos. Es el mismo valor que process.cpuUsage().system.
- maxRSS <entero> se asigna a ru_maxrss que es el tamaño máximo del conjunto residente utilizado en kilobytes.
- sharedMemorySize <entero> se asigna a ru_ixrss pero no es compatible con ninguna plataforma.
- unsharedDataSize <entero> se asigna a ru_idrss pero no es compatible con ninguna plataforma.
- unsharedStackSize <entero> se asigna a ru_isrss pero no es compatible con ninguna plataforma.
- minorPageFault <entero> se asigna a ru_minflt que es el número de fallos de página menores para el proceso, consulta este artículo para más detalles.
- majorPageFault <entero> se asigna a ru_majflt que es el número de fallos de página mayores para el proceso, consulta este artículo para más detalles. Este campo no es compatible con Windows.
- swappedOut <entero> se asigna a ru_nswap pero no es compatible con ninguna plataforma.
- fsRead <entero> se asigna a ru_inblock que es el número de veces que el sistema de archivos tuvo que realizar una entrada.
- fsWrite <entero> se asigna a ru_oublock que es el número de veces que el sistema de archivos tuvo que realizar una salida.
- ipcSent <entero> se asigna a ru_msgsnd pero no es compatible con ninguna plataforma.
- ipcReceived <entero> se asigna a ru_msgrcv pero no es compatible con ninguna plataforma.
- signalsCount <entero> se asigna a ru_nsignals pero no es compatible con ninguna plataforma.
- voluntaryContextSwitches <entero> se asigna a ru_nvcsw que es el número de veces que un cambio de contexto de la CPU se produjo debido a que un proceso cedió voluntariamente el procesador antes de que se completara su intervalo de tiempo (generalmente para esperar la disponibilidad de un recurso). Este campo no es compatible con Windows.
- involuntaryContextSwitches <entero> se asigna a ru_nivcsw que es el número de veces que un cambio de contexto de la CPU se produjo debido a que un proceso de mayor prioridad se volvió ejecutable o porque el proceso actual excedió su intervalo de tiempo. Este campo no es compatible con Windows.

ESMCJS

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

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(mensaje[, sendHandle[, opciones]][, callback])`

Agregado en: v0.5.9

mensaje <Object>
sendHandle <net.Server> | <net.Socket>
opciones <Object> utilizado para parametrizar el envío de ciertos tipos de handles. opciones admite las siguientes propiedades:
- keepOpen <boolean> Un valor que se puede utilizar al pasar instancias de net.Socket. Cuando es true, el socket se mantiene abierto en el proceso de envío. Por defecto: false.
callback <Function>
Devuelve: <boolean>

Si Node.js se genera con un canal IPC, el método process.send() se puede utilizar para enviar mensajes al proceso padre. Los mensajes se recibirán como un evento 'message' en el objeto ChildProcess del padre.

Si Node.js no se generó con un canal IPC, process.send será undefined.

El mensaje pasa por la serialización y el análisis. El mensaje resultante podría no ser el mismo que el que se envía originalmente.

`process.setegid(id)`

Agregado en: v2.0.0

id <string> | <number> Un nombre o ID de grupo

El método process.setegid() establece la identidad de grupo efectiva del proceso. (Ver setegid(2).) El id se puede pasar como un ID numérico o como una cadena con el nombre del grupo. Si se especifica un nombre de grupo, este método se bloquea mientras resuelve el ID numérico asociado.

ESMCJS

import process from 'node:process'

if (process.getegid && process.setegid) {
  console.log(`GID actual: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`Nuevo GID: ${process.getegid()}`)
  } catch (err) {
    console.error(`Error al establecer el GID: ${err}`)
  }
}

const process = require('node:process')

if (process.getegid && process.setegid) {
  console.log(`GID actual: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`Nuevo GID: ${process.getegid()}`)
  } catch (err) {
    console.error(`Error al establecer el GID: ${err}`)
  }
}

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android). Esta característica no está disponible en los hilos Worker.

`process.seteuid(id)`

Añadido en: v2.0.0

id <string> | <number> Un nombre de usuario o ID

El método process.seteuid() establece la identidad de usuario efectiva del proceso. (Ver seteuid(2).) El id se puede pasar como un ID numérico o una cadena de nombre de usuario. Si se especifica un nombre de usuario, el método se bloquea mientras se resuelve el ID numérico asociado.

ESMCJS

import process from 'node:process'

if (process.geteuid && process.seteuid) {
  console.log(`ID de usuario actual: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`Nuevo ID de usuario: ${process.geteuid()}`)
  } catch (err) {
    console.error(`Error al establecer el ID de usuario: ${err}`)
  }
}

const process = require('node:process')

if (process.geteuid && process.seteuid) {
  console.log(`ID de usuario actual: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`Nuevo ID de usuario: ${process.geteuid()}`)
  } catch (err) {
    console.error(`Error al establecer el ID de usuario: ${err}`)
  }
}

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows ni Android). Esta característica no está disponible en hilos Worker.

`process.setgid(id)`

Agregado en: v0.1.31

id <string> | <number> El nombre o ID del grupo

El método process.setgid() establece la identidad de grupo del proceso. (Ver setgid(2).) El id se puede pasar como un ID numérico o como una cadena con el nombre del grupo. Si se especifica un nombre de grupo, este método se bloquea mientras resuelve el ID numérico asociado.

ESMCJS

import process from 'node:process'

if (process.getgid && process.setgid) {
  console.log(`Gid actual: ${process.getgid()}`)
  try {
    process.setgid(501)
    console.log(`Nuevo gid: ${process.getgid()}`)
  } catch (err) {
    console.error(`Error al establecer gid: ${err}`)
  }
}

const process = require('node:process')

if (process.getgid && process.setgid) {
  console.log(`Gid actual: ${process.getgid()}`)
  try {
    process.setgid(501)
    console.log(`Nuevo gid: ${process.getgid()}`)
  } catch (err) {
    console.error(`Error al establecer gid: ${err}`)
  }
}

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android). Esta característica no está disponible en los hilos Worker.

`process.setgroups(groups)`

Añadido en: v0.9.4

groups <integer[]>

El método process.setgroups() establece los ID de grupo suplementarios para el proceso de Node.js. Esta es una operación privilegiada que requiere que el proceso de Node.js tenga root o la capacidad CAP_SETGID.

El array groups puede contener ID de grupo numéricos, nombres de grupo o ambos.

ESMCJS

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

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

Esta función solo está disponible en plataformas POSIX (es decir, no Windows o Android). Esta característica no está disponible en hilos Worker.

`process.setuid(id)`

Agregado en: v0.1.28

id <integer> | <string>

El método process.setuid(id) establece la identidad de usuario del proceso. (Ver setuid(2).) El id se puede pasar como un ID numérico o como una cadena de nombre de usuario. Si se especifica un nombre de usuario, el método se bloquea mientras se resuelve el ID numérico asociado.

ESMCJS

import process from 'node:process'

if (process.getuid && process.setuid) {
  console.log(`UID actual: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`Nuevo UID: ${process.getuid()}`)
  } catch (err) {
    console.error(`Error al establecer el UID: ${err}`)
  }
}

const process = require('node:process')

if (process.getuid && process.setuid) {
  console.log(`UID actual: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`Nuevo UID: ${process.getuid()}`)
  } catch (err) {
    console.error(`Error al establecer el UID: ${err}`)
  }
}

Esta función solo está disponible en plataformas POSIX (es decir, no en Windows o Android). Esta función no está disponible en threads Worker.

`process.setSourceMapsEnabled(val)`

Añadido en: v16.6.0, v14.18.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1 - Experimental

val <boolean>

Esta función activa o desactiva el soporte de Source Map v3 para los rastreos de pila.

Proporciona las mismas características que iniciar el proceso de Node.js con la opción de línea de comandos --enable-source-maps.

Solo se analizarán y cargarán los mapas de origen en archivos JavaScript que se carguen después de que se hayan habilitado los mapas de origen.

`process.setUncaughtExceptionCaptureCallback(fn)`

Añadido en: v9.3.0

fn <Function> | <null>

La función process.setUncaughtExceptionCaptureCallback() establece una función que se invocará cuando ocurra una excepción no capturada, que recibirá el valor de la excepción como su primer argumento.

Si se establece dicha función, no se emitirá el evento 'uncaughtException'. Si se pasó --abort-on-uncaught-exception desde la línea de comandos o se estableció a través de v8.setFlagsFromString(), el proceso no se abortará. Las acciones configuradas para que se lleven a cabo en las excepciones, como la generación de informes, también se verán afectadas.

Para anular la función de captura, se puede usar process.setUncaughtExceptionCaptureCallback(null). Llamar a este método con un argumento que no sea null mientras se establece otra función de captura generará un error.

El uso de esta función es mutuamente excluyente con el uso del módulo integrado obsoleto domain.

`process.sourceMapsEnabled`

Añadido en: v20.7.0, v18.19.0

[Estable: 1 - Experimental]

Estable: 1 Estabilidad: 1 - Experimental

<boolean>

La propiedad process.sourceMapsEnabled devuelve si el soporte de Source Map v3 para rastreos de pila está habilitado.

`process.stderr`

<Stream>

La propiedad process.stderr devuelve un stream conectado a stderr (fd 2). Es un net.Socket (que es un stream Duplex) a menos que fd 2 se refiera a un archivo, en cuyo caso es un stream Writable.

process.stderr difiere de otros streams de Node.js de maneras importantes. Consulta nota sobre E/S de proceso para más información.

`process.stderr.fd`

<number>

Esta propiedad se refiere al valor del descriptor de archivo subyacente de process.stderr. El valor está fijo en 2. En los hilos Worker, este campo no existe.

`process.stdin`

<Stream>

La propiedad process.stdin devuelve un stream conectado a stdin (fd 0). Es un net.Socket (que es un stream Duplex) a menos que fd 0 se refiera a un archivo, en cuyo caso es un stream Readable.

Para obtener detalles sobre cómo leer desde stdin, consulta readable.read().

Como un stream Duplex, process.stdin también se puede usar en el modo "antiguo" que es compatible con los scripts escritos para Node.js anteriores a la versión v0.10. Para obtener más información, consulta Compatibilidad de streams.

En el modo de streams "antiguo", el stream stdin se pausa de forma predeterminada, por lo que se debe llamar a process.stdin.resume() para leer desde él. Ten en cuenta también que llamar a process.stdin.resume() en sí mismo cambiaría el stream al modo "antiguo".

`process.stdin.fd`

<number>

Esta propiedad se refiere al valor del descriptor de archivo subyacente de process.stdin. El valor se fija en 0. En los hilos Worker, este campo no existe.

`process.stdout`

<Stream>

La propiedad process.stdout devuelve un flujo conectado a stdout (fd 1). Es un net.Socket (que es un flujo Duplex) a menos que fd 1 se refiera a un archivo, en cuyo caso es un flujo Writable.

Por ejemplo, para copiar process.stdin a process.stdout:

ESMCJS

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

stdin.pipe(stdout)

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

stdin.pipe(stdout)

process.stdout se diferencia de otros flujos de Node.js de maneras importantes. Consulta la nota sobre la E/S del proceso para obtener más información.

`process.stdout.fd`

<number>

Esta propiedad se refiere al valor del descriptor de archivo subyacente de process.stdout. El valor está fijo en 1. En los hilos Worker, este campo no existe.

Una nota sobre E/S de procesos

process.stdout y process.stderr difieren de otros streams de Node.js de maneras importantes:

Estos comportamientos son en parte por razones históricas, ya que cambiarlos crearía incompatibilidad hacia atrás, pero también son esperados por algunos usuarios.

Las escrituras síncronas evitan problemas como que la salida escrita con console.log() o console.error() se intercale inesperadamente o no se escriba en absoluto si se llama a process.exit() antes de que se complete una escritura asíncrona. Consulte process.exit() para obtener más información.

Advertencia: Las escrituras síncronas bloquean el bucle de eventos hasta que la escritura se ha completado. Esto puede ser casi instantáneo en el caso de la salida a un archivo, pero bajo una alta carga del sistema, tuberías que no se leen en el extremo receptor o con terminales o sistemas de archivos lentos, es posible que el bucle de eventos se bloquee con la suficiente frecuencia y durante el tiempo suficiente para tener graves impactos negativos en el rendimiento. Esto puede no ser un problema al escribir en una sesión de terminal interactiva, pero tenga esto en cuenta con especial cuidado al realizar el registro de producción en los streams de salida del proceso.

Para comprobar si un stream está conectado a un contexto TTY, compruebe la propiedad isTTY.

Por ejemplo:

bash

$ 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

Consulte la documentación de TTY para obtener más información.

`process.throwDeprecation`

Agregado en: v0.9.12

<boolean>

El valor inicial de process.throwDeprecation indica si el flag --throw-deprecation está establecido en el proceso Node.js actual. process.throwDeprecation es mutable, por lo que si las advertencias de obsolescencia resultan en errores puede ser alterado en tiempo de ejecución. Consulta la documentación para el evento 'warning' y el método emitWarning() para más información.

bash

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

Añadido en: v0.1.104

<string>

La propiedad process.title devuelve el título del proceso actual (es decir, devuelve el valor actual de ps). Asignar un nuevo valor a process.title modifica el valor actual de ps.

Cuando se asigna un nuevo valor, diferentes plataformas impondrán diferentes restricciones de longitud máxima al título. Generalmente, tales restricciones son bastante limitadas. Por ejemplo, en Linux y macOS, process.title está limitado al tamaño del nombre binario más la longitud de los argumentos de línea de comandos, porque establecer el process.title sobrescribe la memoria argv del proceso. Node.js v0.8 permitía cadenas de título de proceso más largas al sobrescribir también la memoria environ, pero eso era potencialmente inseguro y confuso en algunos casos (más bien oscuros).

Asignar un valor a process.title podría no resultar en una etiqueta precisa dentro de las aplicaciones de administrador de procesos como el Monitor de Actividad de macOS o el Administrador de Servicios de Windows.

`process.traceDeprecation`

Añadido en: v0.8.0

<boolean>

La propiedad process.traceDeprecation indica si la bandera --trace-deprecation está establecida en el proceso actual de Node.js. Consulte la documentación del evento 'warning' y el método emitWarning() para obtener más información sobre el comportamiento de esta bandera.

`process.umask()`

[Historial]

Versión	Cambios
v14.0.0, v12.19.0	Llamar a `process.umask()` sin argumentos está obsoleto.
v0.1.19	Añadido en: v0.1.19

[Estable: 0 - Obsoleto]

Estable: 0 Estabilidad: 0 - Obsoleto. Llamar a process.umask() sin argumentos hace que la máscara umask de todo el proceso se escriba dos veces. Esto introduce una condición de carrera entre los hilos y es una posible vulnerabilidad de seguridad. No hay una API alternativa segura y multiplataforma.

process.umask() devuelve la máscara de creación de modo de archivo del proceso de Node.js. Los procesos secundarios heredan la máscara del proceso principal.

`process.umask(mask)`

Agregado en: v0.1.19

mask <string> | <integer>

process.umask(mask) establece la máscara de creación de modo de archivo del proceso de Node.js. Los procesos secundarios heredan la máscara del proceso principal. Devuelve la máscara anterior.

ESMCJS

import { umask } from 'node:process'

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

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

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

En los hilos Worker, process.umask(mask) lanzará una excepción.

`process.uptime()`

Agregado en: v0.5.0

Devuelve: <number>

El método process.uptime() devuelve el número de segundos que el proceso actual de Node.js ha estado en ejecución.

El valor de retorno incluye fracciones de segundo. Use Math.floor() para obtener segundos completos.

`process.version`

Añadido en: v0.1.3

<string>

La propiedad process.version contiene la cadena de versión de Node.js.

ESMCJS

import { version } from 'node:process'

console.log(`Versión: ${version}`)
// Versión: v14.8.0

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

console.log(`Versión: ${version}`)
// Versión: v14.8.0

Para obtener la cadena de versión sin la v inicial, utilice process.versions.node.

`process.versions`

[Historial]

Versión	Cambios
v9.0.0	La propiedad `v8` ahora incluye un sufijo específico de Node.js.
v4.2.0	La propiedad `icu` ahora es compatible.
v0.2.0	Añadido en: v0.2.0

<Object>

La propiedad process.versions devuelve un objeto que enumera las cadenas de versión de Node.js y sus dependencias. process.versions.modules indica la versión ABI actual, que aumenta cada vez que cambia una API de C++. Node.js se negará a cargar módulos que se compilaron con una versión ABI de módulo diferente.

ESMCJS

import { versions } from 'node:process'

console.log(versions)

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

console.log(versions)

Generará un objeto similar a:

bash

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

Códigos de salida

Node.js normalmente saldrá con un código de estado 0 cuando no haya más operaciones asíncronas pendientes. Los siguientes códigos de estado se utilizan en otros casos:

1 Excepción fatal no detectada: Hubo una excepción no detectada, y no fue gestionada por un dominio o un controlador de eventos 'uncaughtException'.
2: Sin usar (reservado por Bash para uso indebido integrado)
3 Error interno de análisis de JavaScript: El código fuente JavaScript interno en el proceso de arranque de Node.js causó un error de análisis. Esto es extremadamente raro y generalmente solo puede suceder durante el desarrollo del propio Node.js.
4 Fallo interno de evaluación de JavaScript: El código fuente JavaScript interno en el proceso de arranque de Node.js no devolvió un valor de función cuando se evaluó. Esto es extremadamente raro y generalmente solo puede suceder durante el desarrollo del propio Node.js.
5 Error fatal: Hubo un error fatal irrecuperable en V8. Por lo general, se imprimirá un mensaje en stderr con el prefijo FATAL ERROR.
6 Manejador interno de excepciones no funcional: Hubo una excepción no detectada, pero la función interna del manejador de excepciones fatales se estableció de alguna manera como no funcional y no se pudo llamar.
7 Fallo en tiempo de ejecución del manejador interno de excepciones: Hubo una excepción no detectada, y la propia función interna del manejador de excepciones fatales arrojó un error al intentar gestionarla. Esto puede suceder, por ejemplo, si un controlador 'uncaughtException' o domain.on('error') lanza un error.
8: Sin usar. En versiones anteriores de Node.js, el código de salida 8 a veces indicaba una excepción no detectada.
9 Argumento inválido: Se especificó una opción desconocida o se proporcionó una opción que requería un valor sin un valor.
10 Fallo interno en tiempo de ejecución de JavaScript: El código fuente JavaScript interno en el proceso de arranque de Node.js arrojó un error cuando se llamó a la función de arranque. Esto es extremadamente raro y generalmente solo puede suceder durante el desarrollo del propio Node.js.
12 Argumento de depuración inválido: Se establecieron las opciones --inspect y/o --inspect-brk, pero el número de puerto elegido no era válido o no estaba disponible.
13 Await de nivel superior no resuelto: Se utilizó await fuera de una función en el código de nivel superior, pero la Promise pasada nunca se resolvió.
14 Fallo de instantánea: Node.js se inició para construir una instantánea de inicio de V8 y falló porque no se cumplieron ciertos requisitos del estado de la aplicación.
>128 Salidas de señal: Si Node.js recibe una señal fatal como SIGKILL o SIGHUP, su código de salida será 128 más el valor del código de señal. Esta es una práctica estándar de POSIX, ya que los códigos de salida se definen como números enteros de 7 bits, y las salidas de señal establecen el bit de orden superior y luego contienen el valor del código de señal. Por ejemplo, la señal SIGABRT tiene el valor 6, por lo que el código de salida esperado será 128 + 6 o 134.

Proceso ​

Eventos del proceso ​

Evento: 'beforeExit' ​

Evento: 'disconnect' ​

Evento: 'exit' ​

Evento: 'message' ​

Event: 'multipleResolves' ​

Evento: 'rejectionHandled' ​

Evento: 'workerMessage' ​

Evento: 'uncaughtException' ​

Advertencia: Uso correcto de 'uncaughtException' ​

Evento: 'uncaughtExceptionMonitor' ​

Evento: 'unhandledRejection' ​

Evento: 'warning' ​

Emisión de advertencias personalizadas ​

Nombres de advertencias de Node.js ​

Evento: 'worker' ​

Eventos de señal ​

process.abort() ​

process.allowedNodeEnvironmentFlags ​

process.arch ​

process.argv ​

process.argv0 ​

process.channel ​

process.channel.ref() ​

process.channel.unref() ​

process.chdir(directorio) ​

process.config ​

process.connected ​

process.constrainedMemory() ​

process.availableMemory() ​

process.cpuUsage([previousValue]) ​

process.cwd() ​

process.debugPort ​

process.disconnect() ​

process.dlopen(module, filename[, flags]) ​

process.emitWarning(warning[, options]) ​

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

Evitar advertencias duplicadas ​

process.env ​

process.execArgv ​

process.execPath ​

process.exit([code]) ​

process.exitCode ​

process.features.cached_builtins ​

process.features.debug ​

process.features.inspector ​

process.features.ipv6 ​

process.features.require_module ​

process.features.tls ​

process.features.tls_alpn ​

process.features.tls_ocsp ​

process.features.tls_sni ​

process.features.typescript ​

process.features.uv ​

process.finalization.register(ref, callback) ​

process.finalization.registerBeforeExit(ref, callback) ​

process.finalization.unregister(ref) ​

process.getActiveResourcesInfo() ​

process.getBuiltinModule(id) ​

process.getegid() ​

process.geteuid() ​

process.getgid() ​

process.getgroups() ​

process.getuid() ​

process.hasUncaughtExceptionCaptureCallback() ​

process.hrtime([time]) ​

process.hrtime.bigint() ​

process.initgroups(user, extraGroup) ​

process.kill(pid[, señal]) ​

process.loadEnvFile(path) ​

process.mainModule ​

process.memoryUsage() ​

process.memoryUsage.rss() ​

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

Cuándo usar queueMicrotask() vs. process.nextTick() ​

process.noDeprecation ​

process.permission ​

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

process.pid ​

Proceso

Eventos del proceso

Evento: `'beforeExit'`

Evento: `'disconnect'`

Evento: `'exit'`

Evento: `'message'`

Event: `'multipleResolves'`

Evento: `'rejectionHandled'`

Evento: `'workerMessage'`

Evento: `'uncaughtException'`

Advertencia: Uso correcto de `'uncaughtException'`

Evento: `'uncaughtExceptionMonitor'`

Evento: `'unhandledRejection'`

Evento: `'warning'`

Emisión de advertencias personalizadas

Nombres de advertencias de Node.js

Evento: `'worker'`

Eventos de señal

`process.abort()`

`process.allowedNodeEnvironmentFlags`

`process.arch`

`process.argv`

`process.argv0`

`process.channel`

`process.channel.ref()`

`process.channel.unref()`

`process.chdir(directorio)`

`process.config`

`process.connected`

`process.constrainedMemory()`

`process.availableMemory()`

`process.cpuUsage([previousValue])`

`process.cwd()`

`process.debugPort`

`process.disconnect()`

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

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

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

Evitar advertencias duplicadas

`process.env`

`process.execArgv`

`process.execPath`

`process.exit([code])`

`process.exitCode`

`process.features.cached_builtins`

`process.features.debug`

`process.features.inspector`

`process.features.ipv6`

`process.features.require_module`

`process.features.tls`

`process.features.tls_alpn`

`process.features.tls_ocsp`

`process.features.tls_sni`

`process.features.typescript`

`process.features.uv`

`process.finalization.register(ref, callback)`

`process.finalization.registerBeforeExit(ref, callback)`

`process.finalization.unregister(ref)`

`process.getActiveResourcesInfo()`

`process.getBuiltinModule(id)`

`process.getegid()`

`process.geteuid()`

`process.getgid()`

`process.getgroups()`

`process.getuid()`

`process.hasUncaughtExceptionCaptureCallback()`

`process.hrtime([time])`

`process.hrtime.bigint()`

`process.initgroups(user, extraGroup)`

`process.kill(pid[, señal])`

`process.loadEnvFile(path)`

`process.mainModule`

`process.memoryUsage()`

`process.memoryUsage.rss()`

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

Cuándo usar `queueMicrotask()` vs. `process.nextTick()`

`process.noDeprecation`

`process.permission`

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

`process.pid`