Processo

Codice Sorgente: lib/process.js

L'oggetto process fornisce informazioni e controllo sul processo Node.js corrente.

ESM

import process from 'node:process'

CJS

const process = require('node:process')

Eventi del processo

L'oggetto process è un'istanza di EventEmitter.

Evento: 'beforeExit'

Aggiunto in: v0.11.12

L'evento 'beforeExit' viene emesso quando Node.js svuota il suo event loop e non ha altro lavoro da pianificare. Normalmente, il processo Node.js si chiude quando non c'è lavoro in programma, ma un listener registrato sull'evento 'beforeExit' può effettuare chiamate asincrone e quindi far continuare il processo Node.js.

La funzione di callback del listener viene invocata con il valore di process.exitCode passato come unico argomento.

L'evento 'beforeExit' non viene emesso per le condizioni che causano la terminazione esplicita, come la chiamata a process.exit() o le eccezioni non gestite.

'beforeExit' non dovrebbe essere usato come alternativa all'evento 'exit' a meno che l'intenzione non sia quella di pianificare ulteriore lavoro.

ESM

import process from 'node:process'

process.on('beforeExit', code => {
  console.log('Evento beforeExit del processo con codice: ', code)
})

process.on('exit', code => {
  console.log('Evento exit del processo con codice: ', code)
})

console.log('Questo messaggio viene visualizzato per primo.')

// Stampa:
// Questo messaggio viene visualizzato per primo.
// Evento beforeExit del processo con codice: 0
// Evento exit del processo con codice: 0

CJS

const process = require('node:process')

process.on('beforeExit', code => {
  console.log('Evento beforeExit del processo con codice: ', code)
})

process.on('exit', code => {
  console.log('Evento exit del processo con codice: ', code)
})

console.log('Questo messaggio viene visualizzato per primo.')

// Stampa:
// Questo messaggio viene visualizzato per primo.
// Evento beforeExit del processo con codice: 0
// Evento exit del processo con codice: 0

Evento: 'disconnect'

Aggiunto in: v0.7.7

Se il processo Node.js viene generato con un canale IPC (vedere la documentazione di Child Process e Cluster), l'evento 'disconnect' verrà emesso quando il canale IPC viene chiuso.

Evento: 'exit'

Aggiunto in: v0.1.7

• code <integer>

L'evento 'exit' viene emesso quando il processo Node.js sta per uscire a causa di:

• La chiamata esplicita del metodo process.exit();
• Il loop degli eventi Node.js non ha più lavoro da eseguire.

A questo punto non è possibile impedire l'uscita dal loop degli eventi e, una volta che tutti gli ascoltatori di 'exit' hanno terminato l'esecuzione, il processo Node.js terminerà.

La funzione di callback dell'ascoltatore viene invocata con il codice di uscita specificato dalla proprietà process.exitCode o dall'argomento exitCode passato al metodo process.exit().

ESM

import process from 'node:process'

process.on('exit', code => {
  console.log(`Sta per uscire con codice: ${code}`)
})

CJS

const process = require('node:process')

process.on('exit', code => {
  console.log(`Sta per uscire con codice: ${code}`)
})

Le funzioni listener devono eseguire solo operazioni sincronizzate. Il processo Node.js uscirà immediatamente dopo aver chiamato gli ascoltatori dell'evento 'exit', causando l'abbandono di qualsiasi ulteriore lavoro ancora in coda nel loop degli eventi. Nell'esempio seguente, ad esempio, il timeout non si verificherà mai:

ESM

import process from 'node:process'

process.on('exit', code => {
  setTimeout(() => {
    console.log('Questo non verrà eseguito')
  }, 0)
})

CJS

const process = require('node:process')

process.on('exit', code => {
  setTimeout(() => {
    console.log('Questo non verrà eseguito')
  }, 0)
})

Evento: 'message'

Aggiunto in: v0.5.10

• message <Object> | <boolean> | <number> | <string> | <null> un oggetto JSON analizzato o un valore primitivo serializzabile.
• sendHandle <net.Server> | <net.Socket> un oggetto net.Server o net.Socket, o undefined.

Se il processo Node.js viene generato con un canale IPC (vedere la documentazione di Child Process e Cluster), l'evento 'message' viene emesso ogni volta che un messaggio inviato da un processo padre usando childprocess.send() viene ricevuto dal processo figlio.

Il messaggio passa attraverso la serializzazione e l'analisi. Il messaggio risultante potrebbe non essere lo stesso di quello originariamente inviato.

Se l'opzione serialization è stata impostata su advanced utilizzata durante la generazione del processo, l'argomento message può contenere dati che JSON non è in grado di rappresentare. Vedere Serializzazione avanzata per child_process per maggiori dettagli.

Evento: 'multipleResolves'

Aggiunto in: v10.12.0

Deprecato da: v17.6.0, v16.15.0

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato

• type <string> Il tipo di risoluzione. Uno tra 'resolve' o 'reject'.
• promise <Promise> La promise che si è risolta o rifiutata più di una volta.
• value <any> Il valore con cui la promise è stata risolta o rifiutata dopo la risoluzione originale.

L'evento 'multipleResolves' viene emesso ogni volta che una Promise è stata:

• Risolta più di una volta.
• Rifiutata più di una volta.
• Rifiutata dopo la risoluzione.
• Risolta dopo il rifiuto.

Questo è utile per tracciare potenziali errori in un'applicazione durante l'utilizzo del costruttore Promise, poiché le risoluzioni multiple vengono silenziosamente eliminate. Tuttavia, il verificarsi di questo evento non indica necessariamente un errore. Ad esempio, Promise.race() può attivare un evento 'multipleResolves'.

A causa dell'affidabilità dell'evento in casi come l'esempio di Promise.race() di cui sopra, è stato deprecato.

ESM

import process from 'node:process'

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason)
  setImmediate(() => process.exit(1))
})

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('Prima chiamata')
      resolve('Risoluzione eliminata')
      reject(new Error('Rifiuto eliminato'))
    })
  } catch {
    throw new Error('Fallito')
  }
}

main().then(console.log)
// resolve: Promise { 'Prima chiamata' } 'Risoluzione eliminata'
// reject: Promise { 'Prima chiamata' } Error: Rifiuto eliminato
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// Prima chiamata

CJS

const process = require('node:process')

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason)
  setImmediate(() => process.exit(1))
})

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('Prima chiamata')
      resolve('Risoluzione eliminata')
      reject(new Error('Rifiuto eliminato'))
    })
  } catch {
    throw new Error('Fallito')
  }
}

main().then(console.log)
// resolve: Promise { 'Prima chiamata' } 'Risoluzione eliminata'
// reject: Promise { 'Prima chiamata' } Error: Rifiuto eliminato
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// Prima chiamata

Evento: 'rejectionHandled'

Aggiunto in: v1.4.1

• promise <Promise> La promise gestita in ritardo.

L'evento 'rejectionHandled' viene emesso ogni volta che una Promise è stata rifiutata e un gestore di errori è stato ad essa associato (utilizzando ad esempio promise.catch()) dopo un giro del ciclo eventi di Node.js.

L'oggetto Promise sarebbe stato precedentemente emesso in un evento 'unhandledRejection', ma nel corso dell'elaborazione ha acquisito un gestore di rifiuto.

Non esiste una nozione di livello superiore per una catena Promise in cui i rifiuti possano essere sempre gestiti. Essendo intrinsecamente asincrona, una reiezione Promise può essere gestita in un momento futuro, possibilmente molto più tardi del giro del ciclo eventi in cui viene emesso l'evento 'unhandledRejection'.

Un altro modo di affermarlo è che, a differenza del codice sincrono dove esiste un elenco sempre crescente di eccezioni non gestite, con le Promise può esserci un elenco crescente e decrescente di reiezioni non gestite.

Nel codice sincrono, l'evento 'uncaughtException' viene emesso quando l'elenco delle eccezioni non gestite cresce.

Nel codice asincrono, l'evento 'unhandledRejection' viene emesso quando l'elenco delle reiezioni non gestite cresce, e l'evento 'rejectionHandled' viene emesso quando l'elenco delle reiezioni non gestite si riduce.

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

In questo esempio, la Map unhandledRejections crescerà e si ridurrà nel tempo, riflettendo le reiezioni che iniziano non gestite e poi diventano gestite. È possibile registrare tali errori in un log di errori, periodicamente (che è probabilmente meglio per le applicazioni a lungo termine) o all'uscita del processo (che è probabilmente più conveniente per gli script).

Evento: 'workerMessage'

Aggiunto in: v22.5.0

• value <any> Un valore trasmesso usando postMessageToThread().
• source <number> L'ID del thread worker che trasmette o 0 per il thread principale.

L'evento 'workerMessage' viene emesso per qualsiasi messaggio in arrivo inviato dall'altra parte usando postMessageToThread().

Evento: 'uncaughtException'

[Cronologia]

Versione	Modifiche
v12.0.0, v10.17.0	Aggiunto l'argomento origin.
v0.1.18	Aggiunto in: v0.1.18

• err <Error> L'eccezione non gestita.
• origin <string> Indica se l'eccezione proviene da un rejection non gestito o da un errore sincrono. Può essere 'uncaughtException' o 'unhandledRejection'. Quest'ultimo viene utilizzato quando si verifica un'eccezione in un contesto asincrono basato su Promise (o se una Promise viene rifiutata) e il flag --unhandled-rejections è impostato su strict o throw (che è l'impostazione predefinita) e il rejection non viene gestito, oppure quando si verifica un rejection durante la fase di caricamento statico del modulo ES del punto di ingresso della riga di comando.

L'evento 'uncaughtException' viene emesso quando un'eccezione JavaScript non gestita risale fino all'event loop. Per impostazione predefinita, Node.js gestisce tali eccezioni stampando la traccia dello stack su stderr ed uscendo con il codice 1, sovrascrivendo qualsiasi process.exitCode precedentemente impostato. L'aggiunta di un gestore per l'evento 'uncaughtException' sovrascrive questo comportamento predefinito. In alternativa, modificare process.exitCode nel gestore 'uncaughtException' che si tradurrà nell'uscita del processo con il codice di uscita fornito. Altrimenti, in presenza di tale gestore il processo uscirà con 0.

ESM

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

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Eccezione intercettata: ${err}\n` + `Origine dell'eccezione: ${origin}\n`)
})

setTimeout(() => {
  console.log('Questo verrà comunque eseguito.')
}, 500)

// Causa intenzionalmente un'eccezione, ma non la intercetta.
nonexistentFunc()
console.log('Questo non verrà eseguito.')

CJS

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

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Eccezione intercettata: ${err}\n` + `Origine dell'eccezione: ${origin}\n`)
})

setTimeout(() => {
  console.log('Questo verrà comunque eseguito.')
}, 500)

// Causa intenzionalmente un'eccezione, ma non la intercetta.
nonexistentFunc()
console.log('Questo non verrà eseguito.')

È possibile monitorare gli eventi 'uncaughtException' senza sovrascrivere il comportamento predefinito di terminazione del processo installando un listener 'uncaughtExceptionMonitor'.

Avviso: Utilizzo corretto di 'uncaughtException'

'uncaughtException' è un meccanismo rudimentale per la gestione delle eccezioni, destinato all'uso solo come ultima risorsa. L'evento non dovrebbe essere usato come equivalente di On Error Resume Next. Le eccezioni non gestite implicano intrinsecamente che un'applicazione si trova in uno stato indefinito. Tentare di riprendere il codice dell'applicazione senza riprendersi correttamente dall'eccezione può causare ulteriori problemi imprevisti e imprevedibili.

Le eccezioni lanciate dall'interno del gestore eventi non verranno intercettate. Invece, il processo si chiuderà con un codice di uscita diverso da zero e verrà stampata la traccia dello stack. Questo per evitare la ricorsione infinita.

Tentare di riprendere normalmente dopo un'eccezione non gestita può essere simile a staccare il cavo di alimentazione durante l'aggiornamento di un computer. Nove volte su dieci, non succede niente. Ma la decima volta, il sistema si corrompe.

L'utilizzo corretto di 'uncaughtException' è quello di eseguire la pulizia sincrona delle risorse allocate (ad esempio, descrittori di file, handle, ecc.) prima di chiudere il processo. Non è sicuro riprendere il funzionamento normale dopo 'uncaughtException'.

Per riavviare un'applicazione crashata in modo più affidabile, indipendentemente dall'emissione di 'uncaughtException', dovrebbe essere impiegato un monitor esterno in un processo separato per rilevare i guasti dell'applicazione e ripristinare o riavviare secondo necessità.

Evento: 'uncaughtExceptionMonitor'

Aggiunto in: v13.7.0, v12.17.0

• err <Error> L'eccezione non gestita.
• origin <string> Indica se l'eccezione proviene da un rifiuto non gestito o da errori sincroni. Può essere 'uncaughtException' o 'unhandledRejection'. Quest'ultimo viene utilizzato quando si verifica un'eccezione in un contesto asincrono basato su Promise (o se una Promise viene rifiutata) e il flag --unhandled-rejections impostato su strict o throw (che è il valore predefinito) e il rifiuto non viene gestito, o quando si verifica un rifiuto durante la fase di caricamento statico del modulo ES del punto di ingresso della riga di comando.

L'evento 'uncaughtExceptionMonitor' viene emesso prima che venga emesso un evento 'uncaughtException' o venga chiamato un hook installato tramite process.setUncaughtExceptionCaptureCallback().

L'installazione di un listener 'uncaughtExceptionMonitor' non modifica il comportamento una volta emesso un evento 'uncaughtException'. Il processo si arresterà comunque se non è installato alcun listener 'uncaughtException'.

ESM

import process from 'node:process'

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

// Causa intenzionalmente un'eccezione, ma non la intercetta.
nonexistentFunc()
// Node.js si arresta comunque

CJS

const process = require('node:process')

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

// Causa intenzionalmente un'eccezione, ma non la intercetta.
nonexistentFunc()
// Node.js si arresta comunque

Evento: 'unhandledRejection'

[Cronologia]

Versione	Modifiche
v7.0.0	La mancata gestione dei rifiuti di Promise è deprecata.
v6.6.0	I rifiuti di Promise non gestiti ora emetteranno un avviso di processo.
v1.4.1	Aggiunto in: v1.4.1

• reason <Error> | <any> L'oggetto con cui la promise è stata rifiutata (tipicamente un oggetto Error).
• promise <Promise> La promise rifiutata.

L'evento 'unhandledRejection' viene emesso ogni volta che una Promise viene rifiutata e nessun gestore di errori è collegato alla promise all'interno di un giro del ciclo eventi. Quando si programma con le Promise, le eccezioni sono incapsulate come "promise rifiutate". I rifiuti possono essere intercettati e gestiti usando promise.catch() e vengono propagati attraverso una catena di Promise. L'evento 'unhandledRejection' è utile per rilevare e tenere traccia delle promise rifiutate i cui rifiuti non sono ancora stati gestiti.

ESM

import process from 'node:process'

process.on('unhandledRejection', (reason, promise) => {
  console.log('Rifiuto non gestito in:', promise, 'motivo:', reason)
  // Registrazione specifica dell'applicazione, generazione di un errore o altra logica qui
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // Nota l'errore di battitura (`pasre`)
}) // Nessun `.catch()` o `.then()`

CJS

const process = require('node:process')

process.on('unhandledRejection', (reason, promise) => {
  console.log('Rifiuto non gestito in:', promise, 'motivo:', reason)
  // Registrazione specifica dell'applicazione, generazione di un errore o altra logica qui
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // Nota l'errore di battitura (`pasre`)
}) // Nessun `.catch()` o `.then()`

Anche quanto segue attiverà l'emissione dell'evento 'unhandledRejection':

ESM

import process from 'node:process'

function SomeResource() {
  // Imposta inizialmente lo stato caricato su una promise rifiutata
  this.loaded = Promise.reject(new Error('Risorsa non ancora caricata!'))
}

const resource = new SomeResource()
// nessun .catch o .then su resource.loaded per almeno un giro

CJS

const process = require('node:process')

function SomeResource() {
  // Imposta inizialmente lo stato caricato su una promise rifiutata
  this.loaded = Promise.reject(new Error('Risorsa non ancora caricata!'))
}

const resource = new SomeResource()
// nessun .catch o .then su resource.loaded per almeno un giro

In questo caso d'esempio, è possibile tracciare il rifiuto come errore dello sviluppatore, come in genere avviene per altri eventi 'unhandledRejection'. Per affrontare tali errori, è possibile collegare un gestore .catch(() =\> { }) non operativo a resource.loaded, che impedirebbe l'emissione dell'evento 'unhandledRejection'.

Evento: 'warning'

Aggiunto in: v6.0.0

• warning <Error> Le proprietà chiave dell'avviso sono:
  • name <string> Il nome dell'avviso. Predefinito: 'Warning'.
  • message <string> Una descrizione dell'avviso fornita dal sistema.
  • stack <string> Una traccia dello stack fino alla posizione nel codice in cui è stato emesso l'avviso.

L'evento 'warning' viene emesso ogni volta che Node.js emette un avviso di processo.

Un avviso di processo è simile a un errore in quanto descrive condizioni eccezionali che vengono portate all'attenzione dell'utente. Tuttavia, gli avvisi non fanno parte del flusso normale di gestione degli errori di Node.js e JavaScript. Node.js può emettere avvisi ogni volta che rileva pratiche di codifica errate che potrebbero portare a prestazioni dell'applicazione subottimali, bug o vulnerabilità di sicurezza.

ESM

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // Stampa il nome dell'avviso
  console.warn(warning.message) // Stampa il messaggio di avviso
  console.warn(warning.stack) // Stampa la traccia dello stack
})

CJS

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // Stampa il nome dell'avviso
  console.warn(warning.message) // Stampa il messaggio di avviso
  console.warn(warning.stack) // Stampa la traccia dello stack
})

Per impostazione predefinita, Node.js stamperà gli avvisi di processo su stderr. L'opzione della riga di comando --no-warnings può essere utilizzata per sopprimere l'output della console predefinito, ma l'evento 'warning' verrà comunque emesso dall'oggetto process. Attualmente, non è possibile sopprimere tipi di avviso specifici diversi dagli avvisi di deprecazione. Per sopprimere gli avvisi di deprecazione, consultare il flag --no-deprecation.

Il seguente esempio illustra l'avviso stampato su stderr quando sono stati aggiunti troppi listener a un evento:

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

Al contrario, l'esempio seguente disattiva l'output di avviso predefinito e aggiunge un gestore personalizzato all'evento 'warning':

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

L'opzione della riga di comando --trace-warnings può essere utilizzata per includere la traccia dello stack completa dell'avviso nell'output della console predefinito per gli avvisi.

L'avvio di Node.js utilizzando il flag della riga di comando --throw-deprecation farà sì che gli avvisi di deprecazione personalizzati vengano generati come eccezioni.

L'utilizzo del flag della riga di comando --trace-deprecation farà sì che la deprecazione personalizzata venga stampata su stderr insieme alla traccia dello stack.

L'utilizzo del flag della riga di comando --no-deprecation sopprimerà tutta la segnalazione della deprecazione personalizzata.

I flag della riga di comando *-deprecation interessano solo gli avvisi che utilizzano il nome 'DeprecationWarning'.

Generazione di avvisi personalizzati

Vedere il metodo process.emitWarning() per emettere avvisi personalizzati o specifici dell'applicazione.

Nomi degli avvisi di Node.js

Non esistono linee guida rigorose per i tipi di avviso (come identificato dalla proprietà name) emessi da Node.js. Nuovi tipi di avvisi possono essere aggiunti in qualsiasi momento. Alcuni dei tipi di avviso più comuni includono:

• 'DeprecationWarning' - Indica l'utilizzo di un'API o di una funzionalità di Node.js deprecata. Tali avvisi devono includere una proprietà 'code' che identifica il codice di deprecazione.
• 'ExperimentalWarning' - Indica l'utilizzo di un'API o di una funzionalità di Node.js sperimentale. Tali funzionalità devono essere utilizzate con cautela in quanto potrebbero cambiare in qualsiasi momento e non sono soggette alle stesse rigorose politiche di semantic versioning e supporto a lungo termine delle funzionalità supportate.
• 'MaxListenersExceededWarning' - Indica che sono stati registrati troppi listener per un determinato evento su un EventEmitter o EventTarget. Questo è spesso un'indicazione di una perdita di memoria.
• 'TimeoutOverflowWarning' - Indica che è stato fornito un valore numerico che non può rientrare in un intero con segno a 32 bit alle funzioni setTimeout() o setInterval().
• 'TimeoutNegativeWarning' - Indica che è stato fornito un numero negativo alle funzioni setTimeout() o setInterval().
• 'TimeoutNaNWarning' - Indica che è stato fornito un valore che non è un numero alle funzioni setTimeout() o setInterval().
• 'UnsupportedWarning' - Indica l'utilizzo di un'opzione o di una funzionalità non supportata che verrà ignorata anziché trattata come un errore. Un esempio è l'utilizzo del messaggio di stato della risposta HTTP quando si utilizza l'API di compatibilità HTTP/2.

Evento: 'worker'

Aggiunto in: v16.2.0, v14.18.0

• worker <Worker> Il thread <Worker> che è stato creato.

L'evento 'worker' viene emesso dopo che è stato creato un nuovo thread <Worker>.

Eventi di segnale

Gli eventi di segnale vengono emessi quando il processo Node.js riceve un segnale. Fare riferimento a signal(7) per un elenco dei nomi di segnale POSIX standard come 'SIGINT', 'SIGHUP', ecc.

I segnali non sono disponibili nei thread Worker.

Il gestore di segnali riceverà il nome del segnale ('SIGINT', 'SIGTERM', ecc.) come primo argomento.

Il nome di ogni evento sarà il nome comune in maiuscolo per il segnale (es. 'SIGINT' per i segnali SIGINT).

ESM

import process from 'node:process'

// Inizia la lettura da stdin in modo che il processo non termini.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('Ricevuto SIGINT. Premere Control-D per uscire.')
})

// Utilizzo di una singola funzione per gestire più segnali
function handle(signal) {
  console.log(`Ricevuto ${signal}`)
}

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

CJS

const process = require('node:process')

// Inizia la lettura da stdin in modo che il processo non termini.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('Ricevuto SIGINT. Premere Control-D per uscire.')
})

// Utilizzo di una singola funzione per gestire più segnali
function handle(signal) {
  console.log(`Ricevuto ${signal}`)
}

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

• 'SIGUSR1' è riservato da Node.js per avviare il debugger. È possibile installare un listener, ma ciò potrebbe interferire con il debugger.
• 'SIGTERM' e 'SIGINT' hanno gestori predefiniti su piattaforme non Windows che reimpostano la modalità terminale prima di uscire con codice 128 + numero di segnale. Se uno di questi segnali ha un listener installato, il suo comportamento predefinito verrà rimosso (Node.js non si chiuderà più).
• 'SIGPIPE' viene ignorato per impostazione predefinita. Può avere un listener installato.
• 'SIGHUP' viene generato su Windows quando la finestra della console viene chiusa e su altre piattaforme in varie condizioni simili. Vedere signal(7). Può avere un listener installato, tuttavia Node.js verrà terminato incondizionatamente da Windows circa 10 secondi dopo. Su piattaforme non Windows, il comportamento predefinito di SIGHUP è quello di terminare Node.js, ma una volta che un listener è stato installato il suo comportamento predefinito verrà rimosso.
• 'SIGTERM' non è supportato su Windows, può essere ascoltato.
• 'SIGINT' dal terminale è supportato su tutte le piattaforme e di solito può essere generato con Ctrl+C (anche se ciò potrebbe essere configurabile). Non viene generato quando la modalità raw del terminale è abilitata e viene utilizzato Ctrl+C.
• 'SIGBREAK' viene inviato su Windows quando viene premuto Ctrl+Break. Su piattaforme non Windows, può essere ascoltato, ma non esiste un modo per inviarlo o generarlo.
• 'SIGWINCH' viene inviato quando la console è stata ridimensionata. Su Windows, ciò accadrà solo in scrittura sulla console quando il cursore viene spostato o quando viene utilizzata una tty leggibile in modalità raw.
• 'SIGKILL' non può avere un listener installato, terminerà incondizionatamente Node.js su tutte le piattaforme.
• 'SIGSTOP' non può avere un listener installato.
• 'SIGBUS', 'SIGFPE', 'SIGSEGV' e 'SIGILL', quando non sollevati artificialmente usando kill(2), lasciano intrinsecamente il processo in uno stato da cui non è sicuro chiamare i listener JS. Ciò potrebbe causare l'arresto del processo.
• 0 può essere inviato per testare l'esistenza di un processo, non ha effetto se il processo esiste, ma genererà un errore se il processo non esiste.

Windows non supporta i segnali, quindi non ha un equivalente alla terminazione tramite segnale, ma Node.js offre una certa emulazione con process.kill() e subprocess.kill():

• L'invio di SIGINT, SIGTERM e SIGKILL causerà la terminazione incondizionata del processo di destinazione e, successivamente, il sottoprocesso segnalerà che il processo è stato terminato dal segnale.
• L'invio del segnale 0 può essere utilizzato come metodo indipendente dalla piattaforma per testare l'esistenza di un processo.

process.abort()

Aggiunto in: v0.7.0

Il metodo process.abort() causa l'uscita immediata del processo Node.js e genera un file core.

Questa funzionalità non è disponibile nei thread Worker.

process.allowedNodeEnvironmentFlags

Aggiunto in: v10.10.0

• <Set>

La proprietà process.allowedNodeEnvironmentFlags è un Set speciale, di sola lettura, di flag consentiti all'interno della variabile di ambiente NODE_OPTIONS.

process.allowedNodeEnvironmentFlags estende Set, ma sovrascrive Set.prototype.has per riconoscere diverse possibili rappresentazioni di flag. process.allowedNodeEnvironmentFlags.has() restituirà true nei seguenti casi:

• I flag possono omettere i trattini singoli (-) o doppi (--) iniziali; ad esempio, inspect-brk per --inspect-brk, o r per -r.
• I flag passati a V8 (come elencato in --v8-options) possono sostituire uno o più trattini non iniziali con un trattino basso, o viceversa; ad esempio, --perf_basic_prof, --perf-basic-prof, --perf_basic-prof, ecc.
• I flag possono contenere uno o più caratteri uguali (=); tutti i caratteri dopo e incluso il primo uguale saranno ignorati; ad esempio, --stack-trace-limit=100.
• I flag devono essere consentiti all'interno di NODE_OPTIONS.

Durante l'iterazione su process.allowedNodeEnvironmentFlags, i flag appariranno solo una volta; ognuno inizierà con uno o più trattini. I flag passati a V8 conterranno trattini bassi invece di trattini non iniziali:

ESM

import { allowedNodeEnvironmentFlags } from 'node:process'

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

CJS

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

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

I metodi add(), clear() e delete() di process.allowedNodeEnvironmentFlags non fanno nulla e falliranno silenziosamente.

Se Node.js è stato compilato senza il supporto NODE_OPTIONS (mostrato in process.config), process.allowedNodeEnvironmentFlags conterrà ciò che sarebbe stato consentito.

process.arch

Aggiunto in: v0.5.0

• <string>

L'architettura della CPU del sistema operativo per cui è stato compilato il binario Node.js. I possibili valori sono: 'arm', 'arm64', 'ia32', 'loong64', 'mips', 'mipsel', 'ppc', 'ppc64', 'riscv64', 's390', 's390x' e 'x64'.

ESM

import { arch } from 'node:process'

console.log(`L'architettura di questo processore è ${arch}`)

CJS

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

console.log(`L'architettura di questo processore è ${arch}`)

process.argv

Aggiunto in: v0.1.27

• <string[]>

La proprietà process.argv restituisce un array contenente gli argomenti della riga di comando passati all'avvio del processo Node.js. Il primo elemento sarà process.execPath. Vedi process.argv0 se è necessario accedere al valore originale di argv[0]. Il secondo elemento sarà il percorso al file JavaScript in esecuzione. Gli elementi rimanenti saranno eventuali argomenti aggiuntivi della riga di comando.

Ad esempio, supponendo lo script seguente per process-args.js:

ESM

import { argv } from 'node:process'

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

CJS

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

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

Avviando il processo Node.js come:

node process-args.js one two=three four

Si genererebbe l'output:

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

process.argv0

Aggiunto in: v6.4.0

• <string>

La proprietà process.argv0 memorizza una copia di sola lettura del valore originale di argv[0] passato all'avvio di Node.js.

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

process.channel

[Cronologia]

Versione	Modifiche
v14.0.0	L'oggetto non espone più accidentalmente i binding nativi C++.
v7.1.0	Aggiunto in: v7.1.0

• <Oggetto>

Se il processo Node.js è stato generato con un canale IPC (vedere la documentazione Processo figlio), la proprietà process.channel è un riferimento al canale IPC. Se non esiste alcun canale IPC, questa proprietà è undefined.

process.channel.ref()

Aggiunto in: v7.1.0

Questo metodo fa sì che il canale IPC mantenga attivo il loop degli eventi del processo se .unref() è stato chiamato prima.

In genere, questo è gestito attraverso il numero di listener 'disconnect' e 'message' sull'oggetto process. Tuttavia, questo metodo può essere utilizzato per richiedere esplicitamente un comportamento specifico.

process.channel.unref()

Aggiunto in: v7.1.0

Questo metodo fa sì che il canale IPC non mantenga attivo il loop degli eventi del processo e gli permette di terminare anche se il canale è aperto.

In genere, questo è gestito attraverso il numero di listener 'disconnect' e 'message' sull'oggetto process. Tuttavia, questo metodo può essere utilizzato per richiedere esplicitamente un comportamento specifico.

process.chdir(directory)

Aggiunto in: v0.1.17

• directory <stringa>

Il metodo process.chdir() cambia la directory di lavoro corrente del processo Node.js o genera un'eccezione se ciò non riesce (ad esempio, se la directory specificata non esiste).

ESM

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

console.log(`Directory di partenza: ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`Nuova directory: ${cwd()}`)
} catch (err) {
  console.error(`chdir: ${err}`)
}

CJS

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

console.log(`Directory di partenza: ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`Nuova directory: ${cwd()}`)
} catch (err) {
  console.error(`chdir: ${err}`)
}

Questa funzionalità non è disponibile nei thread Worker.

process.config

[Cronologia]

Versione	Modifiche
v19.0.0	L'oggetto process.config è ora bloccato.
v16.0.0	La modifica di process.config è stata deprecata.
v0.7.7	Aggiunto in: v0.7.7

• <Oggetto>

La proprietà process.config restituisce un oggetto bloccato contenente la rappresentazione JavaScript delle opzioni di configurazione utilizzate per compilare l'eseguibile Node.js corrente. Questo è lo stesso del file config.gypi prodotto durante l'esecuzione dello script ./configure.

Un esempio dell'output possibile è simile a:

{
  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

Aggiunto in: v0.7.2

• <booleano>

Se il processo Node.js viene generato con un canale IPC (vedere la documentazione di Child Process e Cluster), la proprietà process.connected restituirà true fintanto che il canale IPC è connesso e restituirà false dopo la chiamata di process.disconnect().

Una volta che process.connected è false, non è più possibile inviare messaggi sul canale IPC usando process.send().

process.constrainedMemory()

[Cronologia]

Versione	Modifiche
v22.0.0, v20.13.0	Valore di ritorno allineato con uv_get_constrained_memory.
v19.6.0, v18.15.0	Aggiunto in: v19.6.0, v18.15.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

• <numero>

Ottiene la quantità di memoria disponibile per il processo (in byte) in base ai limiti imposti dal sistema operativo. Se non esiste tale vincolo, o il vincolo è sconosciuto, viene restituito 0.

Vedere uv_get_constrained_memory per maggiori informazioni.

process.availableMemory()

Aggiunto in: v22.0.0, v20.13.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

• <number>

Ottiene la quantità di memoria libera ancora disponibile per il processo (in byte).

Vedi uv_get_available_memory per maggiori informazioni.

process.cpuUsage([previousValue])

Aggiunto in: v6.1.0

• previousValue <Object> Un valore di ritorno precedente dalla chiamata a process.cpuUsage()
• Restituisce: <Object>
  • user <integer>
  • system <integer>

Il metodo process.cpuUsage() restituisce l'utilizzo della CPU del processo corrente, in un oggetto con le proprietà user e system, i cui valori sono valori in microsecondi (milionesimi di secondo). Questi valori misurano il tempo trascorso rispettivamente nel codice utente e di sistema e potrebbero essere superiori al tempo trascorso effettivamente se più core della CPU stanno eseguendo il lavoro per questo processo.

Il risultato di una chiamata precedente a process.cpuUsage() può essere passato come argomento alla funzione, per ottenere una lettura differenziale.

ESM

import { cpuUsage } from 'node:process'

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

// far girare la CPU per 500 millisecondi
const now = Date.now()
while (Date.now() - now < 500);

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

CJS

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

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

// far girare la CPU per 500 millisecondi
const now = Date.now()
while (Date.now() - now < 500);

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

process.cwd()

Aggiunto in: v0.1.8

• Restituisce: <string>

Il metodo process.cwd() restituisce la directory di lavoro corrente del processo Node.js.

ESM

import { cwd } from 'node:process'

console.log(`Directory corrente: ${cwd()}`)

CJS

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

console.log(`Directory corrente: ${cwd()}`)

process.debugPort

Aggiunto in: v0.7.2

• <number>

La porta utilizzata dal debugger Node.js quando abilitato.

ESM

import process from 'node:process'

process.debugPort = 5858

CJS

const process = require('node:process')

process.debugPort = 5858

process.disconnect()

Aggiunto in: v0.7.2

Se il processo Node.js viene generato con un canale IPC (vedere la documentazione su Child Process e Cluster), il metodo process.disconnect() chiuderà il canale IPC al processo padre, consentendo al processo figlio di uscire correttamente una volta che non ci sono altre connessioni che lo mantengono attivo.

L'effetto della chiamata a process.disconnect() è lo stesso della chiamata a ChildProcess.disconnect() dal processo padre.

Se il processo Node.js non è stato generato con un canale IPC, process.disconnect() sarà undefined.

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

[Cronologia]

Versione	Modifiche
v9.0.0	Aggiunto supporto per l'argomento flags.
v0.1.16	Aggiunto in: v0.1.16

• module <Object>
• filename <string>
• flags <os.constants.dlopen> Default: os.constants.dlopen.RTLD_LAZY

Il metodo process.dlopen() consente il caricamento dinamico di oggetti condivisi. È principalmente utilizzato da require() per caricare gli Add-on C++, e non dovrebbe essere utilizzato direttamente, tranne che in casi speciali. In altre parole, require() dovrebbe essere preferito a process.dlopen() a meno che non vi siano motivi specifici come flag dlopen personalizzati o caricamento da moduli ES.

L'argomento flags è un intero che consente di specificare il comportamento di dlopen. Vedere la documentazione di os.constants.dlopen per i dettagli.

Un requisito importante quando si chiama process.dlopen() è che l'istanza module deve essere passata. Le funzioni esportate dall'Add-on C++ sono quindi accessibili tramite module.exports.

L'esempio seguente mostra come caricare un Add-on C++, denominato local.node, che esporta una funzione foo. Tutti i simboli vengono caricati prima che la chiamata restituisca, passando la costante RTLD_NOW. In questo esempio si presume che la costante sia disponibile.

ESM

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

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

CJS

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

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

process.emitWarning(warning[, options])

Aggiunto in: v8.0.0

• warning <string> | <Error> L'avviso da emettere.
• options <Object>
  • type <string> Quando warning è una String, type è il nome da utilizzare per il tipo di avviso emesso. Default: 'Warning'.
  • code <string> Un identificatore univoco per l'istanza di avviso emessa.
  • ctor <Function> Quando warning è una String, ctor è una funzione opzionale utilizzata per limitare la traccia dello stack generata. Default: process.emitWarning.
  • detail <string> Testo aggiuntivo da includere nell'errore.

Il metodo process.emitWarning() può essere utilizzato per emettere avvisi di processo personalizzati o specifici dell'applicazione. Questi possono essere ascoltati aggiungendo un handler all'evento 'warning'.

ESM

import { emitWarning } from 'node:process'

// Emetti un avviso con un codice e dettagli aggiuntivi.
emitWarning('Qualcosa è successo!', {
  code: 'MY_WARNING',
  detail: 'Questa è qualche informazione aggiuntiva',
})
// Emette:
// (node:56338) [MY_WARNING] Warning: Qualcosa è successo!
// Questa è qualche informazione aggiuntiva

CJS

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

// Emetti un avviso con un codice e dettagli aggiuntivi.
emitWarning('Qualcosa è successo!', {
  code: 'MY_WARNING',
  detail: 'Questa è qualche informazione aggiuntiva',
})
// Emette:
// (node:56338) [MY_WARNING] Warning: Qualcosa è successo!
// Questa è qualche informazione aggiuntiva

In questo esempio, un oggetto Error viene generato internamente da process.emitWarning() e passato all'handler 'warning'.

ESM

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // 'Qualcosa è successo!'
  console.warn(warning.code) // 'MY_WARNING'
  console.warn(warning.stack) // Traccia dello stack
  console.warn(warning.detail) // 'Questa è qualche informazione aggiuntiva'
})

CJS

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // 'Qualcosa è successo!'
  console.warn(warning.code) // 'MY_WARNING'
  console.warn(warning.stack) // Traccia dello stack
  console.warn(warning.detail) // 'Questa è qualche informazione aggiuntiva'
})

Se warning viene passato come oggetto Error, l'argomento options viene ignorato.

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

Aggiunto in: v6.0.0

• warning <string> | <Error> L'avviso da emettere.
• type <string> Quando warning è una String, type è il nome da utilizzare per il tipo di avviso emesso. Default: 'Warning'.
• code <string> Un identificatore univoco per l'istanza di avviso emessa.
• ctor <Function> Quando warning è una String, ctor è una funzione opzionale utilizzata per limitare la traccia dello stack generata. Default: process.emitWarning.

Il metodo process.emitWarning() può essere utilizzato per emettere avvisi di processo personalizzati o specifici dell'applicazione. Questi possono essere ascoltati aggiungendo un gestore all'evento 'warning'.

ESM

import { emitWarning } from 'node:process'

// Emette un avviso usando una stringa.
emitWarning('Qualcosa è successo!')
// Emette: (node: 56338) Warning: Qualcosa è successo!

CJS

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

// Emette un avviso usando una stringa.
emitWarning('Qualcosa è successo!')
// Emette: (node: 56338) Warning: Qualcosa è successo!

ESM

import { emitWarning } from 'node:process'

// Emette un avviso usando una stringa e un tipo.
emitWarning('Qualcosa è successo!', 'CustomWarning')
// Emette: (node:56338) CustomWarning: Qualcosa è successo!

CJS

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

// Emette un avviso usando una stringa e un tipo.
emitWarning('Qualcosa è successo!', 'CustomWarning')
// Emette: (node:56338) CustomWarning: Qualcosa è successo!

ESM

import { emitWarning } from 'node:process'

emitWarning('Qualcosa è successo!', 'CustomWarning', 'WARN001')
// Emette: (node:56338) [WARN001] CustomWarning: Qualcosa è successo!

CJS

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

process.emitWarning('Qualcosa è successo!', 'CustomWarning', 'WARN001')
// Emette: (node:56338) [WARN001] CustomWarning: Qualcosa è successo!

In ognuno degli esempi precedenti, un oggetto Error viene generato internamente da process.emitWarning() e passato al gestore dell'evento 'warning'.

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Se warning viene passato come oggetto Error, verrà passato al gestore dell'evento 'warning' senza modifiche (e gli argomenti opzionali type, code e ctor verranno ignorati):

ESM

import { emitWarning } from 'node:process'

// Emette un avviso usando un oggetto Error.
const myWarning = new Error('Qualcosa è successo!')
// Usa la proprietà name di Error per specificare il nome del tipo
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// Emette: (node:56338) [WARN001] CustomWarning: Qualcosa è successo!

CJS

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

// Emette un avviso usando un oggetto Error.
const myWarning = new Error('Qualcosa è successo!')
// Usa la proprietà name di Error per specificare il nome del tipo
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// Emette: (node:56338) [WARN001] CustomWarning: Qualcosa è successo!

Viene lanciato un TypeError se warning è qualcosa di diverso da una stringa o un oggetto Error.

Sebbene gli avvisi di processo utilizzino oggetti Error, il meccanismo di avviso di processo non è una sostituzione dei normali meccanismi di gestione degli errori.

La seguente gestione aggiuntiva viene implementata se il tipo di avviso è 'DeprecationWarning':

• Se viene utilizzato il flag della riga di comando --throw-deprecation, l'avviso di deprecazione viene lanciato come eccezione anziché essere emesso come evento.
• Se viene utilizzato il flag della riga di comando --no-deprecation, l'avviso di deprecazione viene soppresso.
• Se viene utilizzato il flag della riga di comando --trace-deprecation, l'avviso di deprecazione viene stampato su stderr insieme all'intera traccia dello stack.

Evitare avvisi duplicati

Come best practice, gli avvisi dovrebbero essere emessi una sola volta per processo. Per fare ciò, posizionare emitWarning() dietro un booleano.

ESM

import { emitWarning } from 'node:process'

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('Solo un avviso!')
  }
}
emitMyWarning()
// Emette: (node: 56339) Warning: Solo un avviso!
emitMyWarning()
// Non emette nulla

CJS

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

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('Solo un avviso!')
  }
}
emitMyWarning()
// Emette: (node: 56339) Warning: Solo un avviso!
emitMyWarning()
// Non emette nulla

process.env

[Cronologia]

Versione	Modifiche
v11.14.0	I thread worker ora utilizzeranno una copia del process.env del thread principale per impostazione predefinita, configurabile tramite l'opzione env del costruttore Worker.
v10.0.0	La conversione implicita del valore della variabile in stringa è deprecata.
v0.1.27	Aggiunto in: v0.1.27

• <Oggetto>

La proprietà process.env restituisce un oggetto contenente l'ambiente utente. Vedere environ(7).

Un esempio di questo oggetto è simile a:

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

È possibile modificare questo oggetto, ma tali modifiche non saranno riflesse al di fuori del processo Node.js, o (se non esplicitamente richiesto) ad altri thread Worker. In altre parole, il seguente esempio non funzionerebbe:

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

Mentre il seguente funzionerà:

ESM

import { env } from 'node:process'

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

CJS

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

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

L'assegnazione di una proprietà a process.env convertirà implicitamente il valore in una stringa. Questo comportamento è deprecato. Le versioni future di Node.js potrebbero generare un errore quando il valore non è una stringa, un numero o un booleano.

ESM

import { env } from 'node:process'

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

CJS

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

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

Utilizzare delete per eliminare una proprietà da process.env.

ESM

import { env } from 'node:process'

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

CJS

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

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

Sui sistemi operativi Windows, le variabili di ambiente non fanno distinzione tra maiuscole e minuscole.

ESM

import { env } from 'node:process'

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

CJS

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

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

Se non specificato esplicitamente durante la creazione di un'istanza Worker, ogni thread Worker ha una propria copia di process.env, basata sul process.env del suo thread principale, o su quanto specificato come opzione env per il costruttore Worker. Le modifiche a process.env non saranno visibili tra i thread Worker, e solo il thread principale può apportare modifiche visibili al sistema operativo o agli add-on nativi. Su Windows, una copia di process.env su un'istanza Worker opera in modo sensibile alle maiuscole e minuscole, a differenza del thread principale.

process.execArgv

Aggiunto in: v0.7.7

• <string[]>

La proprietà process.execArgv restituisce il set di opzioni della riga di comando specifiche di Node.js passate quando è stato avviato il processo Node.js. Queste opzioni non appaiono nell'array restituito dalla proprietà process.argv, e non includono l'eseguibile Node.js, il nome dello script o qualsiasi opzione che segue il nome dello script. Queste opzioni sono utili per generare processi figlio con lo stesso ambiente di esecuzione del padre.

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

Risulta in process.execArgv:

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

E process.argv:

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

Fare riferimento al Worker costruttore per il comportamento dettagliato dei thread worker con questa proprietà.

process.execPath

Aggiunto in: v0.1.100

• <string>

La proprietà process.execPath restituisce il pathname assoluto dell'eseguibile che ha avviato il processo Node.js. I collegamenti simbolici, se presenti, vengono risolti.

'/usr/local/bin/node'

process.exit([code])

[Cronologia]

Versione	Modifiche
v20.0.0	Accetta solo un codice di tipo numerico, o di tipo stringa se rappresenta un intero.
v0.1.13	Aggiunto in: v0.1.13

• code <integer> | <string> | <null> | <undefined> Il codice di uscita. Per il tipo stringa, sono consentite solo stringhe intere (es. '1'). Default: 0.

Il metodo process.exit() istruisce Node.js a terminare il processo in modo sincrono con uno stato di uscita di code. Se code è omesso, l'uscita utilizza il codice 'successo' 0 o il valore di process.exitCode se è stato impostato. Node.js non terminerà finché tutti gli ascoltatori di eventi 'exit' non saranno chiamati.

Per uscire con un codice di 'errore':

ESM

import { exit } from 'node:process'

exit(1)

CJS

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

exit(1)

Lo shell che ha eseguito Node.js dovrebbe vedere il codice di uscita come 1.

Chiamare process.exit() forzerà il processo ad uscire il più rapidamente possibile anche se ci sono ancora operazioni asincrone in sospeso che non sono ancora state completate completamente, incluse le operazioni I/O su process.stdout e process.stderr.

Nella maggior parte delle situazioni, non è effettivamente necessario chiamare process.exit() esplicitamente. Il processo Node.js si chiuderà da solo se non c'è ulteriore lavoro in sospeso nel loop degli eventi. La proprietà process.exitCode può essere impostata per indicare al processo quale codice di uscita utilizzare quando il processo si chiude correttamente.

Ad esempio, l'esempio seguente illustra un uso improprio del metodo process.exit() che potrebbe portare alla troncatura e alla perdita dei dati stampati su stdout:

ESM

import { exit } from 'node:process'

// Questo è un esempio di cosa *non* fare:
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

CJS

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

// Questo è un esempio di cosa *non* fare:
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

La ragione per cui questo è problematico è perché le scritture su process.stdout in Node.js sono a volte asincrone e possono avvenire su più tick del loop degli eventi di Node.js. Chiamare process.exit(), tuttavia, forza il processo ad uscire prima che queste scritture aggiuntive su stdout possano essere eseguite.

Invece di chiamare direttamente process.exit(), il codice dovrebbe impostare process.exitCode e permettere al processo di uscire naturalmente evitando di programmare ulteriore lavoro per il loop degli eventi:

ESM

import process from 'node:process'

// Come impostare correttamente il codice di uscita lasciando
// che il processo esca correttamente.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

CJS

const process = require('node:process')

// Come impostare correttamente il codice di uscita lasciando
// che il processo esca correttamente.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

Se è necessario terminare il processo Node.js a causa di una condizione di errore, generare un errore non catturato e consentire al processo di terminare di conseguenza è più sicuro che chiamare process.exit().

Nei thread Worker, questa funzione interrompe il thread corrente anziché il processo corrente.

process.exitCode

[Cronologia]

Versione	Modifiche
v20.0.0	Accetta solo un codice di tipo numerico, o di tipo stringa se rappresenta un intero.
v0.11.8	Aggiunto in: v0.11.8

• <intero> | <stringa> | <null> | <undefined> Il codice di uscita. Per il tipo stringa, sono consentite solo stringhe intere (es. '1'). Predefinito: undefined.

Un numero che sarà il codice di uscita del processo, quando il processo termina correttamente o viene terminato tramite process.exit() senza specificare un codice.

Specificare un codice a process.exit(code) sovrascriverà qualsiasi impostazione precedente di process.exitCode.

process.features.cached_builtins

Aggiunto in: v12.0.0

• <booleano>

Un valore booleano che è true se la build Node.js corrente sta mettendo in cache i moduli built-in.

process.features.debug

Aggiunto in: v0.5.5

• <booleano>

Un valore booleano che è true se la build Node.js corrente è una build di debug.

process.features.inspector

Aggiunto in: v11.10.0

• <booleano>

Un valore booleano che è true se la build Node.js corrente include l'inspector.

process.features.ipv6

Aggiunto in: v0.5.3

Deprecato da: v23.4.0

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato. Questa proprietà è sempre vera e qualsiasi controllo basato su di essa è ridondante.

• <booleano>

Un valore booleano che è true se la build Node.js corrente include il supporto per IPv6.

Poiché tutte le build di Node.js hanno il supporto per IPv6, questo valore è sempre true.

process.features.require_module

Aggiunto in: v23.0.0

• <boolean>

Un valore booleano che è true se la build corrente di Node.js supporta il caricamento di moduli ECMAScript usando require().

process.features.tls

Aggiunto in: v0.5.3

• <boolean>

Un valore booleano che è true se la build corrente di Node.js include il supporto per TLS.

process.features.tls_alpn

Aggiunto in: v4.8.0

Deprecato da: v23.4.0

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato. Usare process.features.tls invece.

• <boolean>

Un valore booleano che è true se la build corrente di Node.js include il supporto per ALPN in TLS.

Nelle versioni 11.0.0 e successive di Node.js, le dipendenze OpenSSL presentano un supporto ALPN incondizionato. Questo valore è quindi identico a quello di process.features.tls.

process.features.tls_ocsp

Aggiunto in: v0.11.13

Deprecato da: v23.4.0

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato. Usare process.features.tls invece.

• <boolean>

Un valore booleano che è true se la build corrente di Node.js include il supporto per OCSP in TLS.

Nelle versioni 11.0.0 e successive di Node.js, le dipendenze OpenSSL presentano un supporto OCSP incondizionato. Questo valore è quindi identico a quello di process.features.tls.

process.features.tls_sni

Aggiunto in: v0.5.3

Deprecato da: v23.4.0

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato. Usare process.features.tls invece.

• <boolean>

Un valore booleano che è true se la build corrente di Node.js include il supporto per SNI in TLS.

Nelle versioni 11.0.0 e successive di Node.js, le dipendenze OpenSSL presentano un supporto SNI incondizionato. Questo valore è quindi identico a quello di process.features.tls.

process.features.typescript

Aggiunto in: v23.0.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

• <boolean> | <string>

Un valore che è "strip" se Node.js viene eseguito con --experimental-strip-types, "transform" se Node.js viene eseguito con --experimental-transform-types, e false altrimenti.

process.features.uv

Aggiunto in: v0.5.3

Deprecato da: v23.4.0

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato. Questa proprietà è sempre vera, e qualsiasi controllo basato su di essa è ridondante.

• <boolean>

Un valore booleano che è true se la build corrente di Node.js include il supporto per libuv.

Dato che non è possibile compilare Node.js senza libuv, questo valore è sempre true.

process.finalization.register(ref, callback)

Aggiunto in: v22.5.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

• ref <Object> | <Function> Il riferimento alla risorsa che viene tracciata.
• callback <Function> La funzione di callback da chiamare quando la risorsa viene finalizzata.
  • ref <Object> | <Function> Il riferimento alla risorsa che viene tracciata.
  • event <string> L'evento che ha attivato la finalizzazione. Di default 'exit'.

Questa funzione registra una callback da chiamare quando il processo emette l'evento exit se l'oggetto ref non è stato garbage collected. Se l'oggetto ref è stato garbage collected prima che l'evento exit venga emesso, la callback verrà rimossa dal registro di finalizzazione e non verrà chiamata all'uscita del processo.

All'interno della callback è possibile rilasciare le risorse allocate dall'oggetto ref. Si tenga presente che tutte le limitazioni applicate all'evento beforeExit sono applicate anche alla funzione callback, questo significa che c'è la possibilità che la callback non venga chiamata in circostanze speciali.

L'idea di questa funzione è quella di aiutare a liberare le risorse quando il processo inizia l'uscita, ma anche di lasciare che l'oggetto venga garbage collected se non viene più utilizzato.

Es: è possibile registrare un oggetto che contiene un buffer, si vuole assicurare che il buffer venga rilasciato quando il processo esce, ma se l'oggetto viene garbage collected prima dell'uscita del processo, non è più necessario rilasciare il buffer, quindi in questo caso basta rimuovere la callback dal registro di finalizzazione.

CJS

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

// Assicurarsi che la funzione passata a finalization.register()
// non crei una closure attorno a oggetti non necessari.
function onFinalize(obj, event) {
  // È possibile fare qualsiasi cosa si desideri con l'oggetto
  obj.dispose()
}

function setup() {
  // Questo oggetto può essere tranquillamente garbage collected,
  // e la funzione di shutdown risultante non verrà chiamata.
  // Non ci sono perdite di memoria.
  const myDisposableObject = {
    dispose() {
      // Liberare le risorse in modo sincrono
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

ESM

import { finalization } from 'node:process'

// Assicurarsi che la funzione passata a finalization.register()
// non crei una closure attorno a oggetti non necessari.
function onFinalize(obj, event) {
  // È possibile fare qualsiasi cosa si desideri con l'oggetto
  obj.dispose()
}

function setup() {
  // Questo oggetto può essere tranquillamente garbage collected,
  // e la funzione di shutdown risultante non verrà chiamata.
  // Non ci sono perdite di memoria.
  const myDisposableObject = {
    dispose() {
      // Liberare le risorse in modo sincrono
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

Il codice sopra si basa sulle seguenti ipotesi:

• le arrow function vengono evitate
• le funzioni regolari si consiglia siano nel contesto globale (root)

Le funzioni regolari potrebbero fare riferimento al contesto in cui vive obj, rendendo obj non garbage collectible.

Le arrow function manterranno il contesto precedente. Si consideri, ad esempio:

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

    // Anche qualcosa come questo è fortemente sconsigliato
    // finalization.register(this, () => this.dispose());
  }
  dispose() {}
}

È molto improbabile (non impossibile) che questo oggetto venga garbage collected, ma se non lo è, dispose verrà chiamato quando viene chiamato process.exit.

Fare attenzione ed evitare di fare affidamento su questa funzionalità per lo smaltimento di risorse critiche, poiché non è garantito che la callback venga chiamata in tutte le circostanze.

process.finalization.registerBeforeExit(ref, callback)

Aggiunto in: v22.5.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

• ref <Oggetto> | <Funzione> Il riferimento alla risorsa che viene tracciata.
• callback <Funzione> La funzione di callback da chiamare quando la risorsa viene finalizzata.
  • ref <Oggetto> | <Funzione> Il riferimento alla risorsa che viene tracciata.
  • event <stringa> L'evento che ha attivato la finalizzazione. Di default 'beforeExit'.

Questa funzione si comporta esattamente come register, tranne per il fatto che la callback verrà chiamata quando il processo emette l'evento beforeExit se l'oggetto ref non è stato raccolto come garbage.

Si tenga presente che tutte le limitazioni applicate all'evento beforeExit sono applicate anche alla funzione callback, questo significa che esiste la possibilità che la callback non venga chiamata in circostanze speciali.

process.finalization.unregister(ref)

Aggiunto in: v22.5.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

• ref <Oggetto> | <Funzione> Il riferimento alla risorsa che è stata registrata in precedenza.

Questa funzione rimuove la registrazione dell'oggetto dal registro di finalizzazione, quindi la callback non verrà più chiamata.

CJS

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

// Assicurarsi che la funzione passata a finalization.register()
// non crei una chiusura attorno a oggetti non necessari.
function onFinalize(obj, event) {
  // È possibile fare qualsiasi cosa con l'oggetto
  obj.dispose()
}

function setup() {
  // Questo oggetto può essere raccolto in modo sicuro come garbage,
  // e la funzione di arresto risultante non verrà chiamata.
  // Non ci sono perdite di memoria.
  const myDisposableObject = {
    dispose() {
      // Libera le tue risorse in modo sincrono
    },
  }

  finalization.register(myDisposableObject, onFinalize)

  // Fai qualcosa

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

setup()

ESM

import { finalization } from 'node:process'

// Assicurarsi che la funzione passata a finalization.register()
// non crei una chiusura attorno a oggetti non necessari.
function onFinalize(obj, event) {
  // È possibile fare qualsiasi cosa con l'oggetto
  obj.dispose()
}

function setup() {
  // Questo oggetto può essere raccolto in modo sicuro come garbage,
  // e la funzione di arresto risultante non verrà chiamata.
  // Non ci sono perdite di memoria.
  const myDisposableObject = {
    dispose() {
      // Libera le tue risorse in modo sincrono
    },
  }

  // Assicurarsi che la funzione passata a finalization.register()
  // non crei una chiusura attorno a oggetti non necessari.
  function onFinalize(obj, event) {
    // È possibile fare qualsiasi cosa con l'oggetto
    obj.dispose()
  }

  finalization.register(myDisposableObject, onFinalize)

  // Fai qualcosa

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

setup()

process.getActiveResourcesInfo()

Aggiunto in: v17.3.0, v16.14.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

• Restituisce: <string[]>

Il metodo process.getActiveResourcesInfo() restituisce un array di stringhe contenenti i tipi delle risorse attive che mantengono attualmente attivo il loop degli eventi.

ESM

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

console.log('Prima:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('Dopo:', getActiveResourcesInfo())
// Stampa:
//   Prima: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   Dopo: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

CJS

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

console.log('Prima:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('Dopo:', getActiveResourcesInfo())
// Stampa:
//   Prima: [ 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   Dopo: [ 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

process.getBuiltinModule(id)

Aggiunto in: v22.3.0, v20.16.0

• id <string> ID del modulo built-in richiesto.
• Restituisce: <Object> | <undefined>

process.getBuiltinModule(id) fornisce un modo per caricare moduli built-in in una funzione globalmente disponibile. I moduli ES che necessitano di supportare altri ambienti possono utilizzarlo per caricare condizionatamente un built-in di Node.js quando viene eseguito in Node.js, senza dover gestire l'errore di risoluzione che può essere lanciato da import in un ambiente non Node.js o dover utilizzare import() dinamico che trasforma il modulo in un modulo asincrono, o trasforma un'API sincrona in una asincrona.

if (globalThis.process?.getBuiltinModule) {
  // Eseguito in Node.js, usa il modulo fs di Node.js.
  const fs = globalThis.process.getBuiltinModule('fs')
  // Se `require()` è necessario per caricare i moduli utente, usa createRequire()
  const module = globalThis.process.getBuiltinModule('module')
  const require = module.createRequire(import.meta.url)
  const foo = require('foo')
}

Se id specifica un modulo built-in disponibile nel processo Node.js corrente, il metodo process.getBuiltinModule(id) restituisce il corrispondente modulo built-in. Se id non corrisponde a nessun modulo built-in, viene restituito undefined.

process.getBuiltinModule(id) accetta ID di moduli built-in riconosciuti da module.isBuiltin(id). Alcuni moduli built-in devono essere caricati con il prefisso node:, vedi moduli built-in con prefisso node: obbligatorio. I riferimenti restituiti da process.getBuiltinModule(id) puntano sempre al modulo built-in corrispondente a id anche se gli utenti modificano require.cache in modo che require(id) restituisca qualcos'altro.

process.getegid()

Aggiunto in: v2.0.0

Il metodo process.getegid() restituisce l'identità numerica del gruppo effettivo del processo Node.js. (Vedi getegid(2).)

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Questa funzione è disponibile solo su piattaforme POSIX (cioè non Windows o Android).

process.geteuid()

Aggiunto in: v2.0.0

• Restituisce: <Object>

Il metodo process.geteuid() restituisce l'identità numerica dell'utente effettivo del processo. (Vedi geteuid(2).)

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Questa funzione è disponibile solo su piattaforme POSIX (cioè non Windows o Android).

process.getgid()

Aggiunto in: v0.1.31

• Restituisce: <Object>

Il metodo process.getgid() restituisce l'identità numerica del gruppo del processo. (Vedi getgid(2).)

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Questa funzione è disponibile solo su piattaforme POSIX (cioè non Windows o Android).

process.getgroups()

Aggiunto in: v0.9.4

• Restituisce: <integer[]>

Il metodo process.getgroups() restituisce un array con gli ID dei gruppi supplementari. POSIX non specifica se l'ID del gruppo effettivo è incluso, ma Node.js garantisce che lo sia sempre.

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Questa funzione è disponibile solo su piattaforme POSIX (cioè non Windows o Android).

process.getuid()

Aggiunto in: v0.1.28

• Restituisce: <integer>

Il metodo process.getuid() restituisce l'identità numerica utente del processo. (Vedi getuid(2).)

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Questa funzione è disponibile solo sulle piattaforme POSIX (ad esempio, non Windows o Android).

process.hasUncaughtExceptionCaptureCallback()

Aggiunto in: v9.3.0

• Restituisce: <boolean>

Indica se è stata impostata una callback utilizzando process.setUncaughtExceptionCaptureCallback().

process.hrtime([time])

Aggiunto in: v0.7.6

[Stabile: 3 - Eredità]

Stabile: 3 Stabilità: 3 - Eredità. Usare process.hrtime.bigint() invece.

• time <integer[]> Il risultato di una precedente chiamata a process.hrtime()
• Restituisce: <integer[]>

Questa è la versione legacy di process.hrtime.bigint() prima che bigint venisse introdotto in JavaScript.

Il metodo process.hrtime() restituisce il tempo reale ad alta risoluzione corrente in una tupla Array [secondi, nanosecondi], dove nanosecondi è la parte rimanente del tempo reale che non può essere rappresentata con precisione in secondi.

time è un parametro opzionale che deve essere il risultato di una precedente chiamata a process.hrtime() per calcolare la differenza con il tempo corrente. Se il parametro passato non è una tupla Array, verrà generato un TypeError. Passare una matrice definita dall'utente invece del risultato di una precedente chiamata a process.hrtime() porterà a un comportamento indefinito.

Questi tempi sono relativi a un tempo arbitrario nel passato e non sono correlati all'ora del giorno e quindi non sono soggetti a deriva dell'orologio. L'uso principale è per misurare le prestazioni tra intervalli:

ESM

import { hrtime } from 'node:process'

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

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

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

CJS

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

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

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

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

process.hrtime.bigint()

Aggiunto in: v10.7.0

• Restituisce: <bigint>

La versione bigint del metodo process.hrtime() che restituisce il tempo reale ad alta risoluzione corrente in nanosecondi come bigint.

A differenza di process.hrtime(), non supporta un ulteriore argomento time poiché la differenza può essere semplicemente calcolata direttamente tramite la sottrazione dei due bigint.

ESM

import { hrtime } from 'node:process'

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

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

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

CJS

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

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

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

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

process.initgroups(user, extraGroup)

Aggiunto in: v0.9.4

• user <string> | <number> Il nome utente o l'identificativo numerico.
• extraGroup <string> | <number> Un nome di gruppo o un identificativo numerico.

Il metodo process.initgroups() legge il file /etc/group e inizializza l'elenco di accesso al gruppo, utilizzando tutti i gruppi di cui l'utente è membro. Questa è un'operazione privilegiata che richiede che il processo Node.js abbia accesso root o la capacità CAP_SETGID.

Prestare attenzione quando si eliminano i privilegi:

ESM

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

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

CJS

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

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

Questa funzione è disponibile solo su piattaforme POSIX (ovvero non Windows o Android). Questa funzionalità non è disponibile nei thread Worker.

process.kill(pid[, signal])

Aggiunto in: v0.0.6

• pid <number> Un ID di processo
• signal <string> | <number> Il segnale da inviare, come stringa o numero. Predefinito: 'SIGTERM'.

Il metodo process.kill() invia il signal al processo identificato da pid.

I nomi dei segnali sono stringhe come 'SIGINT' o 'SIGHUP'. Vedi Eventi di Segnale e kill(2) per maggiori informazioni.

Questo metodo solleverà un errore se il pid di destinazione non esiste. Come caso speciale, un segnale di 0 può essere usato per testare l'esistenza di un processo. Le piattaforme Windows solleveranno un errore se il pid viene utilizzato per terminare un gruppo di processi.

Anche se il nome di questa funzione è process.kill(), è in realtà solo un mittente di segnali, come la chiamata di sistema kill. Il segnale inviato potrebbe fare qualcosa di diverso dall'uccidere il processo di destinazione.

ESM

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

process.on('SIGHUP', () => {
  console.log('Ricevuto segnale SIGHUP.')
})

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

kill(process.pid, 'SIGHUP')

CJS

const process = require('node:process')

process.on('SIGHUP', () => {
  console.log('Ricevuto segnale SIGHUP.')
})

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

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

Quando SIGUSR1 viene ricevuto da un processo Node.js, Node.js avvierà il debugger. Vedi Eventi di Segnale.

process.loadEnvFile(path)

Aggiunto in: v21.7.0, v20.12.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

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

Carica il file .env in process.env. L'utilizzo di NODE_OPTIONS nel file .env non avrà alcun effetto su Node.js.

CJS

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

ESM

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

process.mainModule

Aggiunto in: v0.1.17

Deprecato da: v14.0.0

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato: Utilizzare require.main invece.

• <Oggetto>

La proprietà process.mainModule fornisce un modo alternativo per recuperare require.main. La differenza è che se il modulo principale cambia durante l'esecuzione, require.main potrebbe ancora fare riferimento al modulo principale originale nei moduli che sono stati richiesti prima che si verificasse il cambiamento. Generalmente, è sicuro presumere che i due facciano riferimento allo stesso modulo.

Come con require.main, process.mainModule sarà undefined se non c'è uno script di ingresso.

process.memoryUsage()

[Cronologia]

Versione	Modifiche
v13.9.0, v12.17.0	Aggiunto arrayBuffers all'oggetto restituito.
v7.2.0	Aggiunto external all'oggetto restituito.
v0.1.16	Aggiunto in: v0.1.16

• Restituisce: <Oggetto>
  • rss <intero>
  • heapTotal <intero>
  • heapUsed <intero>
  • external <intero>
  • arrayBuffers <intero>

Restituisce un oggetto che descrive l'utilizzo della memoria del processo Node.js misurato in byte.

ESM

import { memoryUsage } from 'node:process'

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

CJS

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

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

• heapTotal e heapUsed si riferiscono all'utilizzo della memoria di V8.
• external si riferisce all'utilizzo della memoria degli oggetti C++ associati agli oggetti JavaScript gestiti da V8.
• rss, Resident Set Size, è la quantità di spazio occupato nel dispositivo di memoria principale (che è un sottoinsieme della memoria totale allocata) per il processo, inclusi tutti gli oggetti e il codice C++ e JavaScript.
• arrayBuffers si riferisce alla memoria allocata per ArrayBuffer e SharedArrayBuffer, inclusi tutti i Buffer di Node.js. Questo è incluso anche nel valore external. Quando Node.js viene utilizzato come libreria incorporata, questo valore potrebbe essere 0 perché le allocazioni per ArrayBuffer potrebbero non essere tracciate in quel caso.

Quando si utilizzano thread Worker, rss sarà un valore valido per l'intero processo, mentre gli altri campi si riferiranno solo al thread corrente.

Il metodo process.memoryUsage() itera su ogni pagina per raccogliere informazioni sull'utilizzo della memoria, che potrebbe essere lento a seconda delle allocazioni di memoria del programma.

process.memoryUsage.rss()

Aggiunto in: v15.6.0, v14.18.0

• Restituisce: <integer>

Il metodo process.memoryUsage.rss() restituisce un intero che rappresenta la dimensione del Resident Set Size (RSS) in byte.

La dimensione del Resident Set Size è la quantità di spazio occupato nel dispositivo di memoria principale (che è un sottoinsieme della memoria totale allocata) per il processo, inclusi tutti gli oggetti e il codice C++ e JavaScript.

Questo valore è lo stesso della proprietà rss fornita da process.memoryUsage(), ma process.memoryUsage.rss() è più veloce.

ESM

import { memoryUsage } from 'node:process'

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

CJS

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

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

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

[Cronologia]

Versione	Modifiche
v22.7.0, v20.18.0	Stabilità cambiata in Legacy.
v18.0.0	Passare un callback non valido all'argomento callback ora genera ERR_INVALID_ARG_TYPE invece di ERR_INVALID_CALLBACK.
v1.8.1	Sono ora supportati argomenti aggiuntivi dopo callback.
v0.1.26	Aggiunto in: v0.1.26

[Stabile: 3 - Legacy]

Stabile: 3 Stabilità: 3 - Legacy: Usare queueMicrotask() invece.

• callback <Function>
• ...args <any> Argomenti aggiuntivi da passare durante l'invocazione del callback

process.nextTick() aggiunge callback alla "coda del prossimo tick". Questa coda viene completamente svuotata dopo che l'operazione corrente sullo stack JavaScript è terminata e prima che al loop degli eventi sia consentito di continuare. È possibile creare un loop infinito se si dovesse chiamare ricorsivamente process.nextTick(). Vedere la guida Event Loop per ulteriori informazioni.

ESM

import { nextTick } from 'node:process'

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

CJS

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

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

Questo è importante quando si sviluppano API per dare agli utenti l'opportunità di assegnare gestori di eventi dopo che un oggetto è stato costruito ma prima che si sia verificato qualsiasi I/O:

ESM

import { nextTick } from 'node:process'

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

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

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

// thing.startDoingStuff() viene chiamato ora, non prima.

CJS

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

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

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

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

// thing.startDoingStuff() viene chiamato ora, non prima.

È molto importante che le API siano o al 100% sincronizzate o al 100% asincrone. Considera questo esempio:

// AVVERTENZA! NON USARE! PERICOLO NON SICURO!
function maybeSync(arg, cb) {
  if (arg) {
    cb()
    return
  }

  fs.stat('file', cb)
}

Questa API è pericolosa perché nel caso seguente:

const maybeTrue = Math.random() > 0.5

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

bar()

Non è chiaro se foo() o bar() verrà chiamato per primo.

L'approccio seguente è molto migliore:

ESM

import { nextTick } from 'node:process'

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

  fs.stat('file', cb)
}

CJS

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

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

  fs.stat('file', cb)
}

Quando usare queueMicrotask() vs. process.nextTick()

L'API queueMicrotask() è un'alternativa a process.nextTick() che differisce anche l'esecuzione di una funzione usando la stessa coda di microattività usata per eseguire i gestori then, catch e finally delle promesse risolte. All'interno di Node.js, ogni volta che la "coda del prossimo tick" viene svuotata, la coda di microattività viene svuotata immediatamente dopo.

ESM

import { nextTick } from 'node:process'

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

CJS

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

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

Per la maggior parte dei casi d'uso da parte degli utenti, l'API queueMicrotask() fornisce un meccanismo portatile e affidabile per differire l'esecuzione che funziona su più ambienti di piattaforma JavaScript e dovrebbe essere preferita a process.nextTick(). In scenari semplici, queueMicrotask() può essere una sostituzione diretta di process.nextTick().

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

Una differenza degna di nota tra le due API è che process.nextTick() permette di specificare valori aggiuntivi che saranno passati come argomenti alla funzione differita quando viene chiamata. Raggiungere lo stesso risultato con queueMicrotask() richiede l'utilizzo di una closure o di una funzione legata:

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

Ci sono piccole differenze nel modo in cui vengono gestiti gli errori sollevati dalla coda del prossimo tick e dalla coda di microattività. Gli errori sollevati all'interno di una callback di microattività in coda dovrebbero essere gestiti all'interno della callback in coda quando possibile. In caso contrario, il gestore eventi process.on('uncaughtException') può essere utilizzato per catturare e gestire gli errori.

In caso di dubbio, a meno che non siano necessarie le capacità specifiche di process.nextTick(), utilizzare queueMicrotask().

process.noDeprecation

Aggiunto in: v0.8.0

• <boolean>

La proprietà process.noDeprecation indica se il flag --no-deprecation è impostato sul processo Node.js corrente. Vedi la documentazione per l'evento 'warning' e il metodo emitWarning() per maggiori informazioni sul comportamento di questo flag.

process.permission

Aggiunto in: v20.0.0

• <Object>

Questa API è disponibile tramite il flag --permission.

process.permission è un oggetto i cui metodi vengono utilizzati per gestire le autorizzazioni per il processo corrente. Ulteriori informazioni sono disponibili nel Modello di Autorizzazione.

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

Aggiunto in: v20.0.0

• scope <string>
• reference <string>
• Restituisce: <boolean>

Verifica che il processo sia in grado di accedere all'ambito e al riferimento specificati. Se non viene fornito alcun riferimento, si presume un ambito globale, ad esempio, process.permission.has('fs.read') verificherà se il processo ha TUTTE le autorizzazioni di lettura del file system.

Il riferimento ha un significato in base all'ambito fornito. Ad esempio, il riferimento quando l'ambito è File System indica file e cartelle.

Gli ambiti disponibili sono:

• fs - Tutto il File System
• fs.read - Operazioni di lettura del File System
• fs.write - Operazioni di scrittura del File System
• child - Operazioni di generazione di processi figlio
• worker - Operazione di generazione di thread worker

// Controlla se il processo ha l'autorizzazione per leggere il file README
process.permission.has('fs.read', './README.md')
// Controlla se il processo ha le autorizzazioni per le operazioni di lettura
process.permission.has('fs.read')

process.pid

Aggiunto in: v0.1.15

• <integer>

La proprietà process.pid restituisce il PID del processo.

ESM

import { pid } from 'node:process'

console.log(`Questo processo ha pid ${pid}`)

CJS

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

console.log(`Questo processo ha pid ${pid}`)

process.platform

Aggiunto in: v0.1.16

• <string>

La proprietà process.platform restituisce una stringa che identifica la piattaforma del sistema operativo per cui è stato compilato il binario Node.js.

I valori attualmente possibili sono:

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

ESM

import { platform } from 'node:process'

console.log(`Questa piattaforma è ${platform}`)

CJS

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

console.log(`Questa piattaforma è ${platform}`)

Il valore 'android' può anche essere restituito se Node.js è compilato sul sistema operativo Android. Tuttavia, il supporto Android in Node.js è sperimentale.

process.ppid

Aggiunto in: v9.2.0, v8.10.0, v6.13.0

• <integer>

La proprietà process.ppid restituisce il PID del padre del processo corrente.

ESM

import { ppid } from 'node:process'

console.log(`Il processo padre ha pid ${ppid}`)

CJS

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

console.log(`Il processo padre ha pid ${ppid}`)

process.release

[Cronologia]

Versione	Modifiche
v4.2.0	La proprietà lts è ora supportata.
v3.0.0	Aggiunto in: v3.0.0

• <Object>

La proprietà process.release restituisce un Object contenente metadati relativi all'attuale release, inclusi gli URL per il tarball sorgente e il tarball solo-intestazioni.

process.release contiene le seguenti proprietà:

• name <string> Un valore che sarà sempre 'node'.
• sourceUrl <string> un URL assoluto che punta a un file .tar.gz contenente il codice sorgente dell'attuale release.
• headersUrl<string> un URL assoluto che punta a un file .tar.gz contenente solo i file di intestazione sorgente per l'attuale release. Questo file è significativamente più piccolo del file sorgente completo e può essere utilizzato per compilare componenti aggiuntivi nativi di Node.js.
• libUrl <string> | <undefined> un URL assoluto che punta a un file node.lib corrispondente all'architettura e alla versione dell'attuale release. Questo file viene utilizzato per compilare componenti aggiuntivi nativi di Node.js. Questa proprietà è presente solo nelle build Windows di Node.js e mancherà su tutte le altre piattaforme.
• lts <string> | <undefined> un'etichetta stringa che identifica l'etichetta LTS per questa release. Questa proprietà esiste solo per le release LTS ed è undefined per tutti gli altri tipi di release, incluse le release Correnti. I valori validi includono i nomi in codice delle release LTS (inclusi quelli che non sono più supportati).
  • 'Fermium' per la linea LTS 14.x a partire da 14.15.0.
  • 'Gallium' per la linea LTS 16.x a partire da 16.13.0.
  • 'Hydrogen' per la linea LTS 18.x a partire da 18.12.0. Per altri nomi in codice delle release LTS, vedere Archivio del registro delle modifiche di 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'
}

Nelle build personalizzate da versioni non di rilascio dell'albero delle sorgenti, potrebbe essere presente solo la proprietà name. Non ci si dovrebbe affidare all'esistenza delle proprietà aggiuntive.

process.report

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa API non è più sperimentale.
v11.8.0	Aggiunta in: v11.8.0

• <Oggetto>

process.report è un oggetto i cui metodi vengono utilizzati per generare report diagnostici per il processo corrente. Ulteriori informazioni sono disponibili nella documentazione sui report.

process.report.compact

Aggiunto in: v13.12.0, v12.17.0

• <booleano>

Scrive i report in un formato compatto, JSON su singola riga, più facilmente utilizzabile dai sistemi di elaborazione dei log rispetto al formato multi-riga predefinito progettato per la lettura umana.

ESM

import { report } from 'node:process'

console.log(`I report sono compatti? ${report.compact}`)

CJS

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

console.log(`I report sono compatti? ${report.compact}`)

process.report.directory

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa API non è più sperimentale.
v11.12.0	Aggiunta in: v11.12.0

• <stringa>

Directory in cui viene scritto il report. Il valore predefinito è una stringa vuota, indicando che i report vengono scritti nella directory di lavoro corrente del processo Node.js.

ESM

import { report } from 'node:process'

console.log(`La directory del report è ${report.directory}`)

CJS

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

console.log(`La directory del report è ${report.directory}`)

process.report.filename

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa API non è più sperimentale.
v11.12.0	Aggiunta in: v11.12.0

• <stringa>

Nome del file in cui viene scritto il report. Se impostato su una stringa vuota, il nome del file di output sarà composto da un timestamp, PID e numero di sequenza. Il valore predefinito è una stringa vuota.

Se il valore di process.report.filename è impostato su 'stdout' o 'stderr', il report viene scritto rispettivamente su stdout o stderr del processo.

ESM

import { report } from 'node:process'

console.log(`Il nome del file del report è ${report.filename}`)

CJS

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

console.log(`Il nome del file del report è ${report.filename}`)

process.report.getReport([err])

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa API non è più sperimentale.
v11.8.0	Aggiunta in: v11.8.0

• err <Error> Un errore personalizzato utilizzato per la segnalazione dello stack JavaScript.
• Restituisce: <Object>

Restituisce una rappresentazione Object JavaScript di un report diagnostico per il processo in esecuzione. La traccia dello stack JavaScript del report è presa da err, se presente.

ESM

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

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

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

CJS

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

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

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

Ulteriori documentazioni sono disponibili nella documentazione sui report.

process.report.reportOnFatalError

[Cronologia]

Versione	Modifiche
v15.0.0, v14.17.0	Questa API non è più sperimentale.
v11.12.0	Aggiunta in: v11.12.0

• <boolean>

Se true, viene generato un report diagnostico in caso di errori fatali, come errori di memoria insufficiente o asserzioni C++ non riuscite.

ESM

import { report } from 'node:process'

console.log(`Report su errore fatale: ${report.reportOnFatalError}`)

CJS

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

console.log(`Report su errore fatale: ${report.reportOnFatalError}`)

process.report.reportOnSignal

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa API non è più sperimentale.
v11.12.0	Aggiunta in: v11.12.0

• <boolean>

Se true, viene generato un report diagnostico quando il processo riceve il segnale specificato da process.report.signal.

ESM

import { report } from 'node:process'

console.log(`Report sul segnale: ${report.reportOnSignal}`)

CJS

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

console.log(`Report sul segnale: ${report.reportOnSignal}`)

process.report.reportOnUncaughtException

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa API non è più sperimentale.
v11.12.0	Aggiunta in: v11.12.0

• <boolean>

Se true, viene generato un report diagnostico in caso di eccezione non gestita.

ESM

import { report } from 'node:process'

console.log(`Report sull'eccezione: ${report.reportOnUncaughtException}`)

CJS

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

console.log(`Report sull'eccezione: ${report.reportOnUncaughtException}`)

process.report.excludeEnv

Aggiunta in: v23.3.0

• <boolean>

Se true, viene generato un report diagnostico senza le variabili d'ambiente.

process.report.signal

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa API non è più sperimentale.
v11.12.0	Aggiunta in: v11.12.0

• <string>

Il segnale utilizzato per attivare la creazione di un report diagnostico. Di default è 'SIGUSR2'.

ESM

import { report } from 'node:process'

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

CJS

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

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

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

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa API non è più sperimentale.
v11.8.0	Aggiunta in: v11.8.0

• filename <string> Nome del file in cui viene scritto il report. Questo dovrebbe essere un percorso relativo, che verrà aggiunto alla directory specificata in process.report.directory, o alla directory di lavoro corrente del processo Node.js, se non specificato.
• err <Error> Un errore personalizzato utilizzato per la segnalazione dello stack JavaScript.
• Restituisce: <string> Restituisce il nome del file del report generato.

Scrive un report diagnostico in un file. Se filename non viene fornito, il nome del file predefinito include la data, l'ora, il PID e un numero di sequenza. La traccia dello stack JavaScript del report viene presa da err, se presente.

Se il valore di filename è impostato su 'stdout' o 'stderr', il report viene scritto rispettivamente su stdout o stderr del processo.

ESM

import { report } from 'node:process'

report.writeReport()

CJS

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

report.writeReport()

Ulteriori informazioni sono disponibili nella documentazione sui report.

process.resourceUsage()

Aggiunto in: v12.6.0

• Restituisce: <Object> l'utilizzo delle risorse per il processo corrente. Tutti questi valori provengono dalla chiamata uv_getrusage che restituisce una struttura uv_rusage_t.
  • userCPUTime <integer> corrisponde a ru_utime calcolato in microsecondi. È lo stesso valore di process.cpuUsage().user.
  • systemCPUTime <integer> corrisponde a ru_stime calcolato in microsecondi. È lo stesso valore di process.cpuUsage().system.
  • maxRSS <integer> corrisponde a ru_maxrss che è la dimensione massima del resident set utilizzata in kilobyte.
  • sharedMemorySize <integer> corrisponde a ru_ixrss ma non è supportato da nessuna piattaforma.
  • unsharedDataSize <integer> corrisponde a ru_idrss ma non è supportato da nessuna piattaforma.
  • unsharedStackSize <integer> corrisponde a ru_isrss ma non è supportato da nessuna piattaforma.
  • minorPageFault <integer> corrisponde a ru_minflt che è il numero di errori di pagina minori per il processo, vedi questo articolo per maggiori dettagli.
  • majorPageFault <integer> corrisponde a ru_majflt che è il numero di errori di pagina maggiori per il processo, vedi questo articolo per maggiori dettagli. Questo campo non è supportato su Windows.
  • swappedOut <integer> corrisponde a ru_nswap ma non è supportato da nessuna piattaforma.
  • fsRead <integer> corrisponde a ru_inblock che è il numero di volte in cui il file system ha dovuto eseguire l'input.
  • fsWrite <integer> corrisponde a ru_oublock che è il numero di volte in cui il file system ha dovuto eseguire l'output.
  • ipcSent <integer> corrisponde a ru_msgsnd ma non è supportato da nessuna piattaforma.
  • ipcReceived <integer> corrisponde a ru_msgrcv ma non è supportato da nessuna piattaforma.
  • signalsCount <integer> corrisponde a ru_nsignals ma non è supportato da nessuna piattaforma.
  • voluntaryContextSwitches <integer> corrisponde a ru_nvcsw che è il numero di volte in cui un cambio di contesto della CPU è avvenuto a causa di un processo che ha volontariamente rinunciato al processore prima che il suo time slice fosse completato (solitamente per attendere la disponibilità di una risorsa). Questo campo non è supportato su Windows.
  • involuntaryContextSwitches <integer> corrisponde a ru_nivcsw che è il numero di volte in cui un cambio di contesto della CPU è avvenuto a causa di un processo di priorità superiore che è diventato eseguibile o perché il processo corrente ha superato il suo time slice. Questo campo non è supportato su Windows.

ESM

import { resourceUsage } from 'node:process'

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

CJS

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

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

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

Aggiunto in: v0.5.9

• message <Object>

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

• options <Object> utilizzato per parametrizzare l'invio di determinati tipi di handle. options supporta le seguenti proprietà:

  • keepOpen <boolean> Un valore che può essere utilizzato quando si passano istanze di net.Socket. Quando true, il socket viene mantenuto aperto nel processo di invio. Default: false.

• callback <Function>

• Restituisce: <boolean>

Se Node.js viene generato con un canale IPC, il metodo process.send() può essere utilizzato per inviare messaggi al processo padre. I messaggi saranno ricevuti come evento 'message' sull'oggetto ChildProcess del padre.

Se Node.js non è stato generato con un canale IPC, process.send sarà undefined.

Il messaggio passa attraverso la serializzazione e l'analisi. Il messaggio risultante potrebbe non essere lo stesso di quello inviato in origine.

process.setegid(id)

Aggiunto in: v2.0.0

• id <string> | <number> Un nome o ID di gruppo

Il metodo process.setegid() imposta l'identità di gruppo effettiva del processo. (Vedi setegid(2).) L' id può essere passato come ID numerico o come stringa di nome di gruppo. Se viene specificato un nome di gruppo, questo metodo si blocca durante la risoluzione dell'ID numerico associato.

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Questa funzione è disponibile solo sulle piattaforme POSIX (ovvero non Windows o Android). Questa funzionalità non è disponibile nei thread Worker.

process.seteuid(id)

Aggiunto in: v2.0.0

• id <string> | <number> Un nome utente o un ID

Il metodo process.seteuid() imposta l'identità utente effettiva del processo. (Vedi seteuid(2).) L'id può essere passato come ID numerico o come stringa nome utente. Se viene specificato un nome utente, il metodo si blocca durante la risoluzione dell'ID numerico associato.

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Questa funzione è disponibile solo su piattaforme POSIX (ovvero non Windows o Android). Questa funzionalità non è disponibile nei thread Worker.

process.setgid(id)

Aggiunto in: v0.1.31

• id <string> | <number> Il nome o l'ID del gruppo

Il metodo process.setgid() imposta l'identità di gruppo del processo. (Vedi setgid(2).) L'id può essere passato come ID numerico o come stringa nome gruppo. Se viene specificato un nome gruppo, questo metodo si blocca durante la risoluzione dell'ID numerico associato.

ESM

import process from 'node:process'

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

CJS

const process = require('node:process')

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

Questa funzione è disponibile solo su piattaforme POSIX (ovvero non Windows o Android). Questa funzionalità non è disponibile nei thread Worker.

process.setgroups(groups)

Aggiunto in: v0.9.4

• groups <integer[]>

Il metodo process.setgroups() imposta gli ID dei gruppi supplementari per il processo Node.js. Questa è un'operazione privilegiata che richiede al processo Node.js di avere i privilegi di root o la capacità CAP_SETGID.

La matrice groups può contenere ID di gruppo numerici, nomi di gruppo o entrambi.

ESM

import process from 'node:process'

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // nuovi gruppi
  } catch (err) {
    console.error(`Impossibile impostare i gruppi: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // nuovi gruppi
  } catch (err) {
    console.error(`Impossibile impostare i gruppi: ${err}`)
  }
}

Questa funzione è disponibile solo sulle piattaforme POSIX (cioè non Windows o Android). Questa funzionalità non è disponibile nei thread Worker.

process.setuid(id)

Aggiunto in: v0.1.28

• id <integer> | <string>

Il metodo process.setuid(id) imposta l'identità utente del processo. (Vedi setuid(2).) id può essere passato come ID numerico o come stringa nome utente. Se viene specificato un nome utente, il metodo si blocca durante la risoluzione dell'ID numerico associato.

ESM

import process from 'node:process'

if (process.getuid && process.setuid) {
  console.log(`Uid corrente: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`Nuovo uid: ${process.getuid()}`)
  } catch (err) {
    console.error(`Impossibile impostare l'uid: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getuid && process.setuid) {
  console.log(`Uid corrente: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`Nuovo uid: ${process.getuid()}`)
  } catch (err) {
    console.error(`Impossibile impostare l'uid: ${err}`)
  }
}

Questa funzione è disponibile solo sulle piattaforme POSIX (cioè non Windows o Android). Questa funzionalità non è disponibile nei thread Worker.

process.setSourceMapsEnabled(val)

Aggiunto in: v16.6.0, v14.18.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

• val <boolean>

Questa funzione abilita o disabilita il supporto Source Map v3 per le tracce dello stack.

Fornisce le stesse funzionalità del lancio del processo Node.js con le opzioni della riga di comando --enable-source-maps.

Solo le source map nei file JavaScript caricati dopo che le source map sono state abilitate verranno analizzate e caricate.

process.setUncaughtExceptionCaptureCallback(fn)

Aggiunto in: v9.3.0

• fn <Function> | <null>

La funzione process.setUncaughtExceptionCaptureCallback() imposta una funzione che verrà invocata quando si verifica un'eccezione non gestita, che riceverà il valore dell'eccezione stessa come suo primo argomento.

Se tale funzione è impostata, l'evento 'uncaughtException' non verrà emesso. Se --abort-on-uncaught-exception è stato passato dalla riga di comando o impostato tramite v8.setFlagsFromString(), il processo non verrà interrotto. Anche le azioni configurate per essere eseguite su eccezioni, come le generazioni di report, saranno interessate.

Per disimpostare la funzione di cattura, è possibile utilizzare process.setUncaughtExceptionCaptureCallback(null). La chiamata a questo metodo con un argomento diverso da null mentre è impostata un'altra funzione di cattura genererà un errore.

L'utilizzo di questa funzione è mutuamente esclusivo con l'utilizzo del modulo built-in deprecato domain.

process.sourceMapsEnabled

Aggiunto in: v20.7.0, v18.19.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

• <boolean>

La proprietà process.sourceMapsEnabled restituisce se il supporto Source Map v3 per le tracce dello stack è abilitato.

process.stderr

• <Stream>

La proprietà process.stderr restituisce un flusso connesso a stderr (fd 2). È un net.Socket (che è un flusso Duplex) a meno che fd 2 non faccia riferimento a un file, nel qual caso è un flusso Writable.

process.stderr differisce dagli altri flussi di Node.js in modi importanti. Vedi nota sull'I/O del processo per maggiori informazioni.

process.stderr.fd

• <number>

Questa proprietà si riferisce al valore del descrittore di file sottostante di process.stderr. Il valore è fisso a 2. Nei thread Worker, questo campo non esiste.

process.stdin

• <Stream>

La proprietà process.stdin restituisce un flusso connesso a stdin (fd 0). È un net.Socket (che è un flusso Duplex) a meno che fd 0 non faccia riferimento a un file, nel qual caso è un flusso Readable.

Per i dettagli su come leggere da stdin vedere readable.read().

Come flusso Duplex, process.stdin può anche essere utilizzato in modalità "vecchia" compatibile con gli script scritti per Node.js precedenti alla v0.10. Per maggiori informazioni vedere Compatibilità Stream.

In modalità flussi "vecchia" il flusso stdin è in pausa per impostazione predefinita, quindi è necessario chiamare process.stdin.resume() per leggerne il contenuto. Si noti inoltre che la chiamata a process.stdin.resume() stessa commuta il flusso in modalità "vecchia".

process.stdin.fd

• <number>

Questa proprietà si riferisce al valore del descrittore di file sottostante di process.stdin. Il valore è fisso a 0. Nei thread Worker, questo campo non esiste.

process.stdout

• <Stream>

La proprietà process.stdout restituisce un flusso connesso a stdout (fd 1). È un net.Socket (che è un flusso Duplex) a meno che fd 1 non faccia riferimento a un file, nel qual caso è un flusso Writable.

Ad esempio, per copiare process.stdin in process.stdout:

ESM

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

stdin.pipe(stdout)

CJS

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

stdin.pipe(stdout)

process.stdout differisce dagli altri flussi di Node.js in modi importanti. Vedi nota sull'I/O del processo per maggiori informazioni.

process.stdout.fd

• <number>

Questa proprietà si riferisce al valore del descrittore di file sottostante di process.stdout. Il valore è fisso a 1. Nei thread Worker, questo campo non esiste.

Nota sull'I/O del processo

process.stdout e process.stderr differiscono dagli altri flussi di Node.js in modi importanti:

Questi comportamenti sono in parte dovuti a ragioni storiche, poiché modificarli creerebbe incompatibilità con le versioni precedenti, ma sono anche attesi da alcuni utenti.

Le scritture sincronizzate evitano problemi come l'output scritto con console.log() o console.error() che viene inaspettatamente interfogliato, o non scritto affatto se viene chiamato process.exit() prima che una scrittura asincrona sia completata. Vedi process.exit() per maggiori informazioni.

• Avviso: Le scritture sincronizzate bloccano il loop degli eventi fino al completamento della scrittura. Questo può essere quasi istantaneo nel caso di output su un file, ma sotto carico di sistema elevato, pipe che non vengono lette dall'estremità ricevente, o con terminali o file system lenti, è possibile che il loop degli eventi venga bloccato abbastanza spesso e a lungo da avere impatti negativi sulle prestazioni. Questo potrebbe non essere un problema quando si scrive in una sessione di terminale interattiva, ma consideralo particolarmente attentamente quando si esegue la registrazione di produzione nei flussi di output del processo.

Per verificare se un flusso è connesso a un contesto TTY, controlla la proprietà isTTY.

Ad esempio:

$ 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

Vedi la documentazione TTY per maggiori informazioni.

process.throwDeprecation

Aggiunto in: v0.9.12

• <boolean>

Il valore iniziale di process.throwDeprecation indica se il flag --throw-deprecation è impostato sul processo Node.js corrente. process.throwDeprecation è mutabile, quindi se gli avvisi di deprecazione risultano in errori può essere modificato durante l'esecuzione. Vedi la documentazione per l'evento 'warning' e il metodo emitWarning() per maggiori informazioni.

$ 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

Aggiunto in: v0.1.104

• <string>

La proprietà process.title restituisce il titolo del processo corrente (ovvero restituisce il valore corrente di ps). Assegnare un nuovo valore a process.title modifica il valore corrente di ps.

Quando viene assegnato un nuovo valore, diverse piattaforme impongono diverse restrizioni di lunghezza massima al titolo. Di solito tali restrizioni sono piuttosto limitate. Ad esempio, su Linux e macOS, process.title è limitato alla dimensione del nome del binario più la lunghezza degli argomenti della riga di comando perché l'impostazione di process.title sovrascrive la memoria argv del processo. Node.js v0.8 consentiva stringhe di titoli di processo più lunghe sovrascrivendo anche la memoria environ, ma ciò era potenzialmente insicuro e fonte di confusione in alcuni casi (piuttosto oscuri).

Assegnare un valore a process.title potrebbe non comportare un'etichetta accurata all'interno delle applicazioni di gestione dei processi come macOS Activity Monitor o Windows Services Manager.

process.traceDeprecation

Aggiunto in: v0.8.0

• <boolean>

La proprietà process.traceDeprecation indica se il flag --trace-deprecation è impostato sul processo Node.js corrente. Vedere la documentazione per l'evento 'warning' e il metodo emitWarning() per maggiori informazioni sul comportamento di questo flag.

process.umask()

[Cronologia]

Versione	Modifiche
v14.0.0, v12.19.0	La chiamata a process.umask() senza argomenti è deprecata.
v0.1.19	Aggiunto in: v0.1.19

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato. Chiamare process.umask() senza argomenti causa la scrittura due volte della umask a livello di processo. Questo introduce una condizione di gara tra i thread ed è una potenziale vulnerabilità di sicurezza. Non esiste un'API alternativa sicura e multipiattaforma.

process.umask() restituisce la maschera di creazione del modo file del processo Node.js. I processi figlio ereditano la maschera dal processo padre.

process.umask(mask)

Aggiunto in: v0.1.19

• mask <string> | <integer>

process.umask(mask) imposta la maschera di creazione del modo file del processo Node.js. I processi figlio ereditano la maschera dal processo padre. Restituisce la maschera precedente.

ESM

import { umask } from 'node:process'

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Maschera umask cambiata da ${oldmask.toString(8)} a ${newmask.toString(8)}`)

CJS

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

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Maschera umask cambiata da ${oldmask.toString(8)} a ${newmask.toString(8)}`)

Nei thread Worker, process.umask(mask) genererà un'eccezione.

process.uptime()

Aggiunto in: v0.5.0

• Restituisce: <number>

Il metodo process.uptime() restituisce il numero di secondi in cui il processo Node.js corrente è in esecuzione.

Il valore restituito include frazioni di secondo. Utilizzare Math.floor() per ottenere secondi interi.

process.version

Aggiunto in: v0.1.3

• <string>

La proprietà process.version contiene la stringa della versione di Node.js.

ESM

import { version } from 'node:process'

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

CJS

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

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

Per ottenere la stringa della versione senza la v iniziale, utilizzare process.versions.node.

process.versions

[Cronologia]

Versione	Modifiche
v9.0.0	La proprietà v8 ora include un suffisso specifico di Node.js.
v4.2.0	La proprietà icu è ora supportata.
v0.2.0	Aggiunto in: v0.2.0

• <Object>

La proprietà process.versions restituisce un oggetto che elenca le stringhe di versione di Node.js e delle sue dipendenze. process.versions.modules indica la versione ABI corrente, che viene incrementata ogni volta che cambia un'API C++. Node.js si rifiuterà di caricare moduli compilati con una versione ABI del modulo diversa.

ESM

import { versions } from 'node:process'

console.log(versions)

CJS

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

console.log(versions)

Genererà un oggetto simile a:

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

Codici di uscita

Node.js normalmente si chiude con un codice di stato 0 quando non ci sono più operazioni asincrone in sospeso. I seguenti codici di stato vengono utilizzati in altri casi:

• 1 Eccezione fatale non gestita: Si è verificata un'eccezione non gestita e non è stata gestita da un dominio o da un gestore eventi 'uncaughtException'.
• 2: Non utilizzato (riservato da Bash per uso improprio dei comandi integrati)
• 3 Errore di analisi JavaScript interno: Il codice sorgente JavaScript interno nel processo di avvio di Node.js ha causato un errore di analisi. Questo è estremamente raro e generalmente può accadere solo durante lo sviluppo di Node.js stesso.
• 4 Errore di valutazione JavaScript interno: Il codice sorgente JavaScript interno nel processo di avvio di Node.js non è riuscito a restituire un valore di funzione quando valutato. Questo è estremamente raro e generalmente può accadere solo durante lo sviluppo di Node.js stesso.
• 5 Errore fatale: Si è verificato un errore fatale irrecuperabile in V8. In genere viene stampato un messaggio su stderr con il prefisso FATAL ERROR.
• 6 Gestore di eccezioni interno non funzione: Si è verificata un'eccezione non gestita, ma la funzione di gestione delle eccezioni interne fatali è stata in qualche modo impostata su una non funzione e non è stato possibile chiamarla.
• 7 Errore di runtime del gestore di eccezioni interno: Si è verificata un'eccezione non gestita e la funzione di gestione delle eccezioni interne fatali stessa ha generato un errore durante il tentativo di gestirla. Ciò può accadere, ad esempio, se un gestore 'uncaughtException' o domain.on('error') genera un errore.
• 8: Non utilizzato. Nelle versioni precedenti di Node.js, il codice di uscita 8 a volte indicava un'eccezione non gestita.
• 9 Argomento non valido: È stata specificata un'opzione sconosciuta oppure è stata fornita un'opzione che richiede un valore senza un valore.
• 10 Errore di runtime JavaScript interno: Il codice sorgente JavaScript interno nel processo di avvio di Node.js ha generato un errore quando è stata chiamata la funzione di avvio. Questo è estremamente raro e generalmente può accadere solo durante lo sviluppo di Node.js stesso.
• 12 Argomento di debug non valido: Le opzioni --inspect e/o --inspect-brk sono state impostate, ma il numero di porta scelto non era valido o non era disponibile.
• 13 Await di primo livello non risolto: await è stato utilizzato al di fuori di una funzione nel codice di primo livello, ma la Promise passata non si è mai risolta.
• 14 Errore nello snapshot: Node.js è stato avviato per creare uno snapshot di avvio di V8 e ha avuto esito negativo perché non sono stati soddisfatti determinati requisiti dello stato dell'applicazione.
• \>128 Uscite del segnale: Se Node.js riceve un segnale fatale come SIGKILL o SIGHUP, il suo codice di uscita sarà 128 più il valore del codice del segnale. Questa è una pratica POSIX standard, poiché i codici di uscita sono definiti come numeri interi a 7 bit e le uscite del segnale impostano il bit di ordine superiore e quindi contengono il valore del codice del segnale. Ad esempio, il segnale SIGABRT ha valore 6, quindi il codice di uscita previsto sarà 128 + 6, ovvero 134.