Processus

L’objet process fournit des informations sur le processus Node.js actuel et permet de le contrôler.

ESMCJS

import process from 'node:process'

const process = require('node:process')

Événements de processus

L’objet process est une instance de EventEmitter.

Événement : `'beforeExit'`

Ajouté dans : v0.11.12

L’événement 'beforeExit' est émis lorsque Node.js vide sa boucle d’événements et n’a plus de travail supplémentaire à planifier. Normalement, le processus Node.js se termine lorsqu’il n’y a plus de travail prévu, mais un écouteur enregistré sur l’événement 'beforeExit' peut effectuer des appels asynchrones et, par conséquent, faire en sorte que le processus Node.js continue.

La fonction de rappel de l’écouteur est invoquée avec la valeur de process.exitCode passée comme seul argument.

L’événement 'beforeExit' n’est pas émis pour les conditions entraînant une fin explicite, telles que l’appel de process.exit() ou des exceptions non détectées.

L’événement 'beforeExit' ne doit pas être utilisé comme alternative à l’événement 'exit', sauf si l’intention est de planifier un travail supplémentaire.

ESMCJS

import process from 'node:process'

process.on('beforeExit', code => {
  console.log('Événement Process beforeExit avec le code : ', code)
})

process.on('exit', code => {
  console.log('Événement Process exit avec le code : ', code)
})

console.log('Ce message s’affiche en premier.')

// Affiche :
// Ce message s’affiche en premier.
// Événement Process beforeExit avec le code : 0
// Événement Process exit avec le code : 0

const process = require('node:process')

process.on('beforeExit', code => {
  console.log('Événement Process beforeExit avec le code : ', code)
})

process.on('exit', code => {
  console.log('Événement Process exit avec le code : ', code)
})

console.log('Ce message s’affiche en premier.')

// Affiche :
// Ce message s’affiche en premier.
// Événement Process beforeExit avec le code : 0
// Événement Process exit avec le code : 0

Événement : `'disconnect'`

Ajouté dans : v0.7.7

Si le processus Node.js est lancé avec un canal IPC (voir la documentation Processus enfant et Cluster), l'événement 'disconnect' sera émis lorsque le canal IPC est fermé.

Événement : `'exit'`

Ajouté dans : v0.1.7

code <integer>

L'événement 'exit' est émis lorsque le processus Node.js est sur le point de se terminer à la suite de l'une des actions suivantes :

La méthode process.exit() est appelée explicitement ;
La boucle d'événements Node.js n'a plus de travail supplémentaire à effectuer.

Il n'y a aucun moyen d'empêcher la sortie de la boucle d'événements à ce stade, et une fois que tous les écouteurs 'exit' ont terminé leur exécution, le processus Node.js se terminera.

La fonction de rappel de l'écouteur est invoquée avec le code de sortie spécifié soit par la propriété process.exitCode, soit par l'argument exitCode transmis à la méthode process.exit().

ESMCJS

import process from 'node:process'

process.on('exit', code => {
  console.log(`Sur le point de quitter avec le code : ${code}`)
})

const process = require('node:process')

process.on('exit', code => {
  console.log(`Sur le point de quitter avec le code : ${code}`)
})

Les fonctions d'écoute doivent uniquement effectuer des opérations synchrones. Le processus Node.js se terminera immédiatement après l'appel des écouteurs d'événement 'exit', ce qui entraînera l'abandon de tout travail supplémentaire toujours en file d'attente dans la boucle d'événements. Dans l'exemple suivant, par exemple, le délai d'attente ne se produira jamais :

ESMCJS

import process from 'node:process'

process.on('exit', code => {
  setTimeout(() => {
    console.log('Ceci ne sera pas exécuté')
  }, 0)
})

const process = require('node:process')

process.on('exit', code => {
  setTimeout(() => {
    console.log('Ceci ne sera pas exécuté')
  }, 0)
})

Événement : `'message'`

Ajouté dans : v0.5.10

message <Object> | <boolean> | <number> | <string> | <null> un objet JSON analysé ou une valeur primitive sérialisable.
sendHandle <net.Server> | <net.Socket> un objet net.Server ou net.Socket ou undefined.

Si le processus Node.js est lancé avec un canal IPC (voir la documentation Processus enfant et Cluster), l’événement 'message' est émis chaque fois qu’un message envoyé par un processus parent à l’aide de childprocess.send() est reçu par le processus enfant.

Le message passe par la sérialisation et l’analyse. Le message résultant peut ne pas être le même que celui qui est envoyé à l’origine.

Si l’option serialization était définie sur advanced lors du lancement du processus, l’argument message peut contenir des données que JSON n’est pas en mesure de représenter. Consultez Sérialisation avancée pour child_process pour plus de détails.

Événement : `'multipleResolves'`

Ajouté dans : v10.12.0

Obsolète depuis : v17.6.0, v16.15.0

[Stable : 0 - Obsolète]

Stable : 0 Stabilité : 0 - Obsolète

type <string> Le type de résolution. L’un des deux : 'resolve' ou 'reject'.
promise <Promise> La promesse qui a été résolue ou rejetée plus d’une fois.
value <any> La valeur avec laquelle la promesse a été résolue ou rejetée après la résolution initiale.

L’événement 'multipleResolves' est émis chaque fois qu’une Promise a été :

Résolue plus d’une fois.
Rejetée plus d’une fois.
Rejetée après la résolution.
Résolue après le rejet.

Ceci est utile pour suivre les erreurs potentielles dans une application lors de l’utilisation du constructeur Promise, car plusieurs résolutions sont ignorées en silence. Toutefois, l’occurrence de cet événement n’indique pas nécessairement une erreur. Par exemple, Promise.race() peut déclencher un événement 'multipleResolves'.

En raison du manque de fiabilité de l’événement dans des cas comme l’exemple de Promise.race() ci-dessus, il a été rendu obsolète.

ESMCJS

import process from 'node:process'

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

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call')
      resolve('Swallowed resolve')
      reject(new Error('Swallowed reject'))
    })
  } catch {
    throw new Error('Failed')
  }
}

main().then(console.log)
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First call

const process = require('node:process')

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

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call')
      resolve('Swallowed resolve')
      reject(new Error('Swallowed reject'))
    })
  } catch {
    throw new Error('Failed')
  }
}

main().then(console.log)
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First call

Événement : `'rejectionHandled'`

Ajouté dans la version : v1.4.1

promise <Promise> La promesse traitée tardivement.

L'événement 'rejectionHandled' est émis chaque fois qu'une Promise a été rejetée et qu'un gestionnaire d'erreurs y a été attaché (en utilisant promise.catch(), par exemple) plus tard qu'un tour de boucle d'événements Node.js.

L'objet Promise aurait été précédemment émis dans un événement 'unhandledRejection', mais au cours du traitement, il a obtenu un gestionnaire de rejet.

Il n'y a pas de notion de niveau supérieur pour une chaîne Promise où les rejets peuvent toujours être traités. De nature intrinsèquement asynchrone, un rejet de Promise peut être traité à un moment ultérieur, éventuellement beaucoup plus tard que le tour de boucle d'événements nécessaire à l'émission de l'événement 'unhandledRejection'.

Une autre façon de dire cela est que, contrairement au code synchrone où il existe une liste toujours croissante d'exceptions non traitées, avec les Promises, il peut y avoir une liste croissante et décroissante de rejets non traités.

Dans le code synchrone, l'événement 'uncaughtException' est émis lorsque la liste des exceptions non traitées s'allonge.

Dans le code asynchrone, l'événement 'unhandledRejection' est émis lorsque la liste des rejets non traités s'allonge, et l'événement 'rejectionHandled' est émis lorsque la liste des rejets non traités diminue.

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Dans cet exemple, le Map unhandledRejections va croître et diminuer au fil du temps, reflétant les rejets qui commencent non traités puis deviennent traités. Il est possible d'enregistrer ces erreurs dans un journal des erreurs, soit périodiquement (ce qui est probablement préférable pour les applications de longue durée), soit à la sortie du processus (ce qui est probablement le plus pratique pour les scripts).

Événement : `'workerMessage'`

Ajouté dans : v22.5.0

value <any> Une valeur transmise en utilisant postMessageToThread().
source <number> L'identifiant du thread de worker émetteur ou 0 pour le thread principal.

L'événement 'workerMessage' est émis pour tout message entrant envoyé par l'autre partie en utilisant postMessageToThread().

Événement : `'uncaughtException'`

[Historique]

Version	Changements
v12.0.0, v10.17.0	Ajout de l'argument `origin`.
v0.1.18	Ajouté dans : v0.1.18

err <Error> L'exception non interceptée.
origin <string> Indique si l'exception provient d'un rejet non géré ou d'une erreur synchrone. Peut être 'uncaughtException' ou 'unhandledRejection'. Le dernier est utilisé lorsqu'une exception se produit dans un contexte asynchrone basé sur Promise (ou si une Promise est rejetée) et que l'indicateur --unhandled-rejections est défini sur strict ou throw (qui est la valeur par défaut) et que le rejet n'est pas géré, ou lorsqu'un rejet se produit pendant la phase de chargement statique du module ES du point d'entrée de la ligne de commande.

L'événement 'uncaughtException' est émis lorsqu'une exception JavaScript non interceptée remonte jusqu'à la boucle d'événements. Par défaut, Node.js gère ces exceptions en affichant la trace de la pile dans stderr et en se terminant avec le code 1, remplaçant toute valeur précédemment définie pour process.exitCode. L'ajout d'un gestionnaire pour l'événement 'uncaughtException' remplace ce comportement par défaut. Alternativement, modifiez le process.exitCode dans le gestionnaire 'uncaughtException', ce qui entraînera la fin du processus avec le code de sortie fourni. Sinon, en présence d'un tel gestionnaire, le processus se terminera avec 0.

ESMCJS

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

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Exception interceptée : ${err}\n` + `Origine de l’exception : ${origin}\n`)
})

setTimeout(() => {
  console.log('Ceci sera toujours exécuté.')
}, 500)

// Provoquer intentionnellement une exception, mais ne pas l’intercepter.
nonexistentFunc()
console.log('Ceci ne sera pas exécuté.')

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

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Exception interceptée : ${err}\n` + `Origine de l’exception : ${origin}\n`)
})

setTimeout(() => {
  console.log('Ceci sera toujours exécuté.')
}, 500)

// Provoquer intentionnellement une exception, mais ne pas l’intercepter.
nonexistentFunc()
console.log('Ceci ne sera pas exécuté.')

Il est possible de surveiller les événements 'uncaughtException' sans remplacer le comportement par défaut de fin du processus en installant un écouteur 'uncaughtExceptionMonitor'.

Avertissement : Utilisation correcte de `'uncaughtException'`

'uncaughtException' est un mécanisme rudimentaire de gestion des exceptions destiné à être utilisé uniquement en dernier recours. L'événement ne doit pas être utilisé comme équivalent à On Error Resume Next. Les exceptions non gérées signifient intrinsèquement qu'une application est dans un état indéfini. Tenter de reprendre le code de l'application sans récupérer correctement de l'exception peut entraîner des problèmes imprévus et imprévisibles supplémentaires.

Les exceptions levées à l'intérieur du gestionnaire d'événements ne seront pas interceptées. Au lieu de cela, le processus se terminera avec un code de sortie non nul et la trace de la pile sera imprimée. Ceci afin d'éviter une récursion infinie.

Tenter de reprendre normalement après une exception non interceptée peut être similaire à la déconnexion du cordon d'alimentation lors de la mise à niveau d'un ordinateur. Neuf fois sur dix, rien ne se passe. Mais la dixième fois, le système est corrompu.

L'utilisation correcte de 'uncaughtException' est d'effectuer un nettoyage synchrone des ressources allouées (par exemple, les descripteurs de fichiers, les handles, etc.) avant d'arrêter le processus. Il n'est pas sûr de reprendre un fonctionnement normal après 'uncaughtException'.

Pour redémarrer une application en panne de manière plus fiable, que 'uncaughtException' soit émis ou non, un moniteur externe doit être employé dans un processus distinct pour détecter les pannes d'application et récupérer ou redémarrer si nécessaire.

Événement : `'uncaughtExceptionMonitor'`

Ajouté dans : v13.7.0, v12.17.0

err <Error> L'exception non interceptée.
origin <string> Indique si l'exception provient d'un rejet non géré ou d'erreurs synchrones. Peut être 'uncaughtException' ou 'unhandledRejection'. Ce dernier est utilisé lorsqu'une exception se produit dans un contexte asynchrone basé sur Promise (ou si une Promise est rejetée) et que l'indicateur --unhandled-rejections est défini sur strict ou throw (qui est la valeur par défaut) et que le rejet n'est pas géré, ou lorsqu'un rejet se produit pendant la phase de chargement statique du module ES du point d'entrée de la ligne de commande.

L'événement 'uncaughtExceptionMonitor' est émis avant qu'un événement 'uncaughtException' ne soit émis ou qu'un hook installé via process.setUncaughtExceptionCaptureCallback() ne soit appelé.

L'installation d'un écouteur 'uncaughtExceptionMonitor' ne modifie pas le comportement une fois qu'un événement 'uncaughtException' est émis. Le processus plantera toujours si aucun écouteur 'uncaughtException' n'est installé.

ESMCJS

import process from 'node:process'

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

// Provoque intentionnellement une exception, mais ne l'intercepte pas.
nonexistentFunc()
// Plante toujours Node.js

const process = require('node:process')

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

// Provoque intentionnellement une exception, mais ne l'intercepte pas.
nonexistentFunc()
// Plante toujours Node.js

Événement : `'unhandledRejection'`

[Historique]

Version	Modifications
v7.0.0	Le fait de ne pas gérer les rejets de `Promise` est obsolète.
v6.6.0	Les rejets de `Promise` non gérés émettront désormais un avertissement de processus.
v1.4.1	Ajouté dans : v1.4.1

reason <Error> | <any> L’objet avec lequel la promesse a été rejetée (généralement un objet Error).
promise <Promise> La promesse rejetée.

L’événement 'unhandledRejection' est émis chaque fois qu’une Promise est rejetée et qu’aucun gestionnaire d’erreurs n’est attaché à la promesse dans un tour de la boucle d’événements. Lors de la programmation avec des Promises, les exceptions sont encapsulées en tant que « promesses rejetées ». Les rejets peuvent être interceptés et gérés à l’aide de promise.catch() et sont propagés par le biais d’une chaîne de Promise. L’événement 'unhandledRejection' est utile pour détecter et suivre les promesses qui ont été rejetées et dont les rejets n’ont pas encore été gérés.

ESMCJS

import process from 'node:process'

process.on('unhandledRejection', (reason, promise) => {
  console.log('Rejet non géré à :', promise, 'motif :', reason)
  // Journalisation propre à l’application, levée d’une erreur ou autre logique ici
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // Notez la faute de frappe (`pasre`)
}) // Pas de `.catch()` ni de `.then()`

const process = require('node:process')

process.on('unhandledRejection', (reason, promise) => {
  console.log('Rejet non géré à :', promise, 'motif :', reason)
  // Journalisation propre à l’application, levée d’une erreur ou autre logique ici
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // Notez la faute de frappe (`pasre`)
}) // Pas de `.catch()` ni de `.then()`

Les éléments suivants déclencheront également l’émission de l’événement 'unhandledRejection' :

ESMCJS

import process from 'node:process'

function SomeResource() {
  // Initialement, définir l’état chargé sur une promesse rejetée
  this.loaded = Promise.reject(new Error('Ressource pas encore chargée !'))
}

const resource = new SomeResource()
// Pas de .catch ou de .then sur resource.loaded pendant au moins un tour

const process = require('node:process')

function SomeResource() {
  // Initialement, définir l’état chargé sur une promesse rejetée
  this.loaded = Promise.reject(new Error('Ressource pas encore chargée !'))
}

const resource = new SomeResource()
// Pas de .catch ou de .then sur resource.loaded pendant au moins un tour

Dans cet exemple, il est possible de suivre le rejet comme une erreur de développeur, comme ce serait généralement le cas pour d’autres événements 'unhandledRejection'. Pour corriger de telles erreurs, un gestionnaire non opérationnel .catch(() => { }) peut être attaché à resource.loaded, ce qui empêcherait l’émission de l’événement 'unhandledRejection'.

Événement : `'warning'`

Ajouté dans la version : v6.0.0

warning <Error> Les propriétés clés de l’avertissement sont :
- name <string> Le nom de l’avertissement. Par défaut : 'Warning'.
- message <string> Une description de l’avertissement fournie par le système.
- stack <string> Une trace de la pile vers l’emplacement dans le code où l’avertissement a été émis.

L’événement 'warning' est émis chaque fois que Node.js émet un avertissement de processus.

Un avertissement de processus est semblable à une erreur en ce qu’il décrit des conditions exceptionnelles qui sont portées à l’attention de l’utilisateur. Cependant, les avertissements ne font pas partie du flux normal de gestion des erreurs de Node.js et JavaScript. Node.js peut émettre des avertissements chaque fois qu’il détecte de mauvaises pratiques de codage qui pourraient entraîner des performances d’application sous-optimales, des bogues ou des vulnérabilités de sécurité.

ESMCJS

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // Affiche le nom de l’avertissement
  console.warn(warning.message) // Affiche le message d’avertissement
  console.warn(warning.stack) // Affiche la trace de la pile
})

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // Affiche le nom de l’avertissement
  console.warn(warning.message) // Affiche le message d’avertissement
  console.warn(warning.stack) // Affiche la trace de la pile
})

Par défaut, Node.js affichera les avertissements de processus dans stderr. L’option de ligne de commande --no-warnings peut être utilisée pour supprimer la sortie de console par défaut, mais l’événement 'warning' sera toujours émis par l’objet process. Actuellement, il n’est pas possible de supprimer des types d’avertissement spécifiques autres que les avertissements de dépréciation. Pour supprimer les avertissements de dépréciation, consultez l’indicateur --no-deprecation.

L’exemple suivant illustre l’avertissement qui est affiché dans stderr lorsque trop d’écouteurs ont été ajoutés à un événement :

bash

$ node
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> (node:38638) MaxListenersExceededWarning : Fuite de mémoire possible détectée dans EventEmitter. 2 écouteurs foo ajoutés. Utilisez emitter.setMaxListeners() pour augmenter la limite.

En revanche, l’exemple suivant désactive la sortie d’avertissement par défaut et ajoute un gestionnaire personnalisé à l’événement 'warning' :

bash

$ node --no-warnings
> const p = process.on('warning', (warning) => console.warn('Ne faites pas ça !'));
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> Ne faites pas ça !

L’option de ligne de commande --trace-warnings peut être utilisée pour que la sortie de console par défaut pour les avertissements inclue la trace de pile complète de l’avertissement.

Le lancement de Node.js à l’aide de l’indicateur de ligne de commande --throw-deprecation entraînera la levée d’avertissements de dépréciation personnalisés sous forme d’exceptions.

L’utilisation de l’indicateur de ligne de commande --trace-deprecation entraînera l’impression de la dépréciation personnalisée dans stderr avec la trace de la pile.

L’utilisation de l’indicateur de ligne de commande --no-deprecation supprimera tous les rapports de la dépréciation personnalisée.

Les indicateurs de ligne de commande *-deprecation n’affectent que les avertissements qui utilisent le nom 'DeprecationWarning'.

Émettre des avertissements personnalisés

Consultez la méthode process.emitWarning() pour émettre des avertissements personnalisés ou spécifiques à l'application.

Noms d'avertissements Node.js

Il n'y a pas de directives strictes pour les types d'avertissements (tels qu'identifiés par la propriété name) émis par Node.js. De nouveaux types d'avertissements peuvent être ajoutés à tout moment. Voici quelques-uns des types d'avertissements les plus courants :

'DeprecationWarning' - Indique l'utilisation d'une API ou d'une fonctionnalité Node.js obsolète. Ces avertissements doivent inclure une propriété 'code' identifiant le code d'obsolescence.
'ExperimentalWarning' - Indique l'utilisation d'une API ou d'une fonctionnalité expérimentale de Node.js. Ces fonctionnalités doivent être utilisées avec prudence, car elles peuvent changer à tout moment et ne sont pas soumises aux mêmes politiques strictes de contrôle de version sémantique et de prise en charge à long terme que les fonctionnalités prises en charge.
'MaxListenersExceededWarning' - Indique qu'un trop grand nombre d'écouteurs pour un événement donné ont été enregistrés sur un EventEmitter ou un EventTarget. C'est souvent le signe d'une fuite de mémoire.
'TimeoutOverflowWarning' - Indique qu'une valeur numérique ne pouvant pas tenir dans un entier signé de 32 bits a été fournie aux fonctions setTimeout() ou setInterval().
'TimeoutNegativeWarning' - Indique qu'un nombre négatif a été fourni aux fonctions setTimeout() ou setInterval().
'TimeoutNaNWarning' - Indique qu'une valeur qui n'est pas un nombre a été fournie aux fonctions setTimeout() ou setInterval().
'UnsupportedWarning' - Indique l'utilisation d'une option ou d'une fonctionnalité non prise en charge qui sera ignorée plutôt que traitée comme une erreur. Un exemple est l'utilisation du message d'état de la réponse HTTP lors de l'utilisation de l'API de compatibilité HTTP/2.

Événement : `'worker'`

Ajouté dans : v16.2.0, v14.18.0

worker <Worker> Le <Worker> qui a été créé.

L'événement 'worker' est émis après la création d'un nouveau thread <Worker>.

Événements de signaux

Des événements de signaux seront émis lorsque le processus Node.js reçoit un signal. Veuillez vous référer à signal(7) pour une liste des noms de signaux POSIX standard tels que 'SIGINT', 'SIGHUP', etc.

Les signaux ne sont pas disponibles sur les threads Worker.

Le gestionnaire de signal recevra le nom du signal ('SIGINT', 'SIGTERM', etc.) comme premier argument.

Le nom de chaque événement sera le nom commun en majuscules du signal (par exemple, 'SIGINT' pour les signaux SIGINT).

ESMCJS

import process from 'node:process'

// Commencer la lecture depuis stdin pour que le processus ne se termine pas.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('Signal SIGINT reçu. Appuyez sur Ctrl-D pour quitter.')
})

// Utilisation d'une seule fonction pour gérer plusieurs signaux
function handle(signal) {
  console.log(`Signal ${signal} reçu`)
}

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

const process = require('node:process')

// Commencer la lecture depuis stdin pour que le processus ne se termine pas.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('Signal SIGINT reçu. Appuyez sur Ctrl-D pour quitter.')
})

// Utilisation d'une seule fonction pour gérer plusieurs signaux
function handle(signal) {
  console.log(`Signal ${signal} reçu`)
}

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

'SIGUSR1' est réservé par Node.js pour démarrer le débogueur. Il est possible d'installer un écouteur, mais cela pourrait interférer avec le débogueur.
'SIGTERM' et 'SIGINT' ont des gestionnaires par défaut sur les plateformes non-Windows qui réinitialisent le mode terminal avant de quitter avec le code 128 + numéro de signal. Si l'un de ces signaux a un écouteur installé, son comportement par défaut sera supprimé (Node.js ne quittera plus).
'SIGPIPE' est ignoré par défaut. Il peut avoir un écouteur installé.
'SIGHUP' est généré sous Windows lorsque la fenêtre de la console est fermée, et sur d'autres plateformes dans diverses conditions similaires. Voir signal(7). Il peut avoir un écouteur installé, cependant Node.js sera inconditionnellement terminé par Windows environ 10 secondes plus tard. Sur les plateformes non-Windows, le comportement par défaut de SIGHUP est de terminer Node.js, mais une fois qu'un écouteur a été installé, son comportement par défaut sera supprimé.
'SIGTERM' n'est pas pris en charge sur Windows, il peut être écouté.
'SIGINT' depuis le terminal est pris en charge sur toutes les plateformes, et peut généralement être généré avec + (bien que cela puisse être configurable). Il n'est pas généré lorsque le mode brut du terminal est activé et que + est utilisé.
'SIGBREAK' est livré sous Windows lorsque + est pressé. Sur les plateformes non-Windows, il peut être écouté, mais il n'y a aucun moyen de l'envoyer ou de le générer.
'SIGWINCH' est livré lorsque la console a été redimensionnée. Sous Windows, cela ne se produira qu'en écriture dans la console lorsque le curseur est déplacé, ou lorsqu'un tty lisible est utilisé en mode brut.
'SIGKILL' ne peut pas avoir d'écouteur installé, il terminera inconditionnellement Node.js sur toutes les plateformes.
'SIGSTOP' ne peut pas avoir d'écouteur installé.
'SIGBUS', 'SIGFPE', 'SIGSEGV' et 'SIGILL', lorsqu'ils ne sont pas déclenchés artificiellement à l'aide de kill(2), laissent intrinsèquement le processus dans un état à partir duquel il n'est pas sûr d'appeler des écouteurs JS. Cela pourrait entraîner l'arrêt de la réponse du processus.
0 peut être envoyé pour tester l'existence d'un processus, cela n'a aucun effet si le processus existe, mais lèvera une erreur si le processus n'existe pas.

Windows ne prend pas en charge les signaux et n'a donc pas d'équivalent à la terminaison par signal, mais Node.js offre une certaine émulation avec process.kill() et subprocess.kill() :

L'envoi de SIGINT, SIGTERM et SIGKILL entraînera la terminaison inconditionnelle du processus cible, et ensuite, le sous-processus signalera que le processus a été terminé par un signal.
L'envoi du signal 0 peut être utilisé comme un moyen indépendant de la plateforme pour tester l'existence d'un processus.

`process.abort()`

Ajouté dans : v0.7.0

La méthode process.abort() provoque l'arrêt immédiat du processus Node.js et génère un fichier core.

Cette fonctionnalité n'est pas disponible dans les threads Worker.

`process.allowedNodeEnvironmentFlags`

Ajouté dans : v10.10.0

<Set>

La propriété process.allowedNodeEnvironmentFlags est un Set spécial, en lecture seule, des drapeaux autorisés dans la variable d'environnement NODE_OPTIONS.

process.allowedNodeEnvironmentFlags étend Set, mais remplace Set.prototype.has pour reconnaître plusieurs représentations de drapeaux possibles. process.allowedNodeEnvironmentFlags.has() retournera true dans les cas suivants :

Les drapeaux peuvent omettre les tirets simples (-) ou doubles (--) de début ; par ex. inspect-brk pour --inspect-brk, ou r pour -r.
Les drapeaux transmis à V8 (tels que listés dans --v8-options) peuvent remplacer un ou plusieurs tirets non initiaux par un trait de soulignement, ou vice versa ; par ex. --perf_basic_prof, --perf-basic-prof, --perf_basic-prof, etc.
Les drapeaux peuvent contenir un ou plusieurs caractères égaux (=) ; tous les caractères après et y compris le premier signe égal seront ignorés ; par ex. --stack-trace-limit=100.
Les drapeaux doivent être autorisés dans NODE_OPTIONS.

Lors de l'itération sur process.allowedNodeEnvironmentFlags, les drapeaux n'apparaîtront qu'une seule fois ; chacun commencera par un ou plusieurs tirets. Les drapeaux transmis à V8 contiendront des traits de soulignement au lieu de tirets non initiaux :

ESMCJS

import { allowedNodeEnvironmentFlags } from 'node:process'

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

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

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

Les méthodes add(), clear() et delete() de process.allowedNodeEnvironmentFlags ne font rien, et échoueront silencieusement.

Si Node.js a été compilé sans la prise en charge de NODE_OPTIONS (indiqué dans process.config), process.allowedNodeEnvironmentFlags contiendra ce qui aurait été autorisé.

`process.arch`

Ajouté dans : v0.5.0

<string>

L’architecture du CPU du système d’exploitation pour laquelle le binaire Node.js a été compilé. Les valeurs possibles sont : 'arm', 'arm64', 'ia32', 'loong64', 'mips', 'mipsel', 'ppc', 'ppc64', 'riscv64', 's390', 's390x' et 'x64'.

ESMCJS

import { arch } from 'node:process'

console.log(`L'architecture de ce processeur est ${arch}`)

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

console.log(`L'architecture de ce processeur est ${arch}`)

`process.argv`

Ajouté dans : v0.1.27

<string[]>

La propriété process.argv renvoie un tableau contenant les arguments de la ligne de commande passés lors du lancement du processus Node.js. Le premier élément sera process.execPath. Consultez process.argv0 si l’accès à la valeur d’origine de argv[0] est nécessaire. Le deuxième élément sera le chemin d’accès au fichier JavaScript en cours d’exécution. Les éléments restants seront tous les arguments de ligne de commande supplémentaires.

Par exemple, en supposant le script suivant pour process-args.js :

ESMCJS

import { argv } from 'node:process'

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

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

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

Le lancement du processus Node.js comme suit :

bash

node process-args.js un deux=trois quatre

générerait la sortie :

text

0: /usr/local/bin/node
1: /Users/mjr/work/node/process-args.js
2: un
3: deux=trois
4: quatre

`process.argv0`

Ajouté dans : v6.4.0

<string>

La propriété process.argv0 stocke une copie en lecture seule de la valeur d’origine de argv[0] passée au démarrage de Node.js.

bash

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

`process.channel`

[Historique]

Version	Modifications
v14.0.0	L'objet n'expose plus accidentellement les liaisons C++ natives.
v7.1.0	Ajouté dans : v7.1.0

<Objet>

Si le processus Node.js a été lancé avec un canal IPC (voir la documentation Processus enfant), la propriété process.channel est une référence au canal IPC. Si aucun canal IPC n'existe, cette propriété est undefined.

`process.channel.ref()`

Ajouté dans : v7.1.0

Cette méthode fait en sorte que le canal IPC maintienne la boucle d'événements du processus en cours d'exécution si .unref() a été appelé auparavant.

En général, cela est géré par le nombre d'écouteurs 'disconnect' et 'message' sur l'objet process. Cependant, cette méthode peut être utilisée pour demander explicitement un comportement spécifique.

`process.channel.unref()`

Ajouté dans : v7.1.0

Cette méthode fait en sorte que le canal IPC ne maintienne pas la boucle d'événements du processus en cours d'exécution et la laisse se terminer même si le canal est ouvert.

`process.chdir(répertoire)`

Ajouté dans : v0.1.17

répertoire <string>

La méthode process.chdir() modifie le répertoire de travail actuel du processus Node.js ou lève une exception si cela échoue (par exemple, si le répertoire spécifié n'existe pas).

ESMCJS

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

console.log(`Répertoire de démarrage : ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`Nouveau répertoire : ${cwd()}`)
} catch (err) {
  console.error(`chdir : ${err}`)
}

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

console.log(`Répertoire de démarrage : ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`Nouveau répertoire : ${cwd()}`)
} catch (err) {
  console.error(`chdir : ${err}`)
}

Cette fonctionnalité n'est pas disponible dans les threads Worker.

`process.config`

[Historique]

Version	Modifications
v19.0.0	L'objet `process.config` est désormais figé.
v16.0.0	La modification de process.config est dépréciée.
v0.7.7	Ajouté dans la version : v0.7.7

<Object>

La propriété process.config renvoie un Object figé contenant la représentation JavaScript des options de configuration utilisées pour compiler l'exécutable Node.js actuel. C'est la même chose que le fichier config.gypi qui a été produit lors de l'exécution du script ./configure.

Un exemple de sortie possible ressemble à :

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

Ajouté dans la version : v0.7.2

<boolean>

Si le processus Node.js est lancé avec un canal IPC (voir la documentation Processus enfant et Cluster), la propriété process.connected renverra true tant que le canal IPC est connecté et renverra false après l'appel de process.disconnect().

Une fois que process.connected est false, il n'est plus possible d'envoyer des messages sur le canal IPC en utilisant process.send().

`process.constrainedMemory()`

[Historique]

Version	Modifications
v22.0.0, v20.13.0	Valeur de retour alignée avec `uv_get_constrained_memory`.
v19.6.0, v18.15.0	Ajouté dans la version : v19.6.0, v18.15.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

<number>

Obtient la quantité de mémoire disponible pour le processus (en octets) en fonction des limites imposées par le système d'exploitation. S'il n'y a pas une telle contrainte, ou si la contrainte est inconnue, 0 est renvoyé.

Voir uv_get_constrained_memory pour plus d'informations.

`process.availableMemory()`

Ajouté dans : v22.0.0, v20.13.0

[Stable: 1 - Expérimental]

Stable: 1 Stabilité : 1 - Expérimental

<number>

Obtient la quantité de mémoire libre encore disponible pour le processus (en octets).

Voir uv_get_available_memory pour plus d’informations.

`process.cpuUsage([previousValue])`

Ajouté dans : v6.1.0

previousValue <Object> Une valeur de retour précédente d’un appel à process.cpuUsage()
Retourne : <Object>
- user <integer>
- system <integer>

La méthode process.cpuUsage() retourne l’utilisation du temps CPU utilisateur et système du processus actuel, dans un objet avec les propriétés user et system, dont les valeurs sont des valeurs en microsecondes (millionième de seconde). Ces valeurs mesurent le temps passé dans le code utilisateur et système respectivement, et peuvent finir par être supérieures au temps écoulé réel si plusieurs cœurs de CPU effectuent du travail pour ce processus.

Le résultat d’un appel précédent à process.cpuUsage() peut être transmis comme argument à la fonction, afin d’obtenir une lecture de différence.

ESMCJS

import { cpuUsage } from 'node:process'

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

// faire tourner le CPU pendant 500 millisecondes
const now = Date.now()
while (Date.now() - now < 500);

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

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

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

// faire tourner le CPU pendant 500 millisecondes
const now = Date.now()
while (Date.now() - now < 500);

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

`process.cwd()`

Ajouté dans : v0.1.8

Retourne : <string>

La méthode process.cwd() renvoie le répertoire de travail actuel du processus Node.js.

ESMCJS

import { cwd } from 'node:process'

console.log(`Répertoire actuel : ${cwd()}`)

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

console.log(`Répertoire actuel : ${cwd()}`)

`process.debugPort`

Ajouté dans : v0.7.2

<number>

Le port utilisé par le débogueur Node.js lorsqu'il est activé.

ESMCJS

import process from 'node:process'

process.debugPort = 5858

const process = require('node:process')

process.debugPort = 5858

`process.disconnect()`

Ajouté dans : v0.7.2

Si le processus Node.js est créé avec un canal IPC (voir la documentation Processus enfant et Cluster), la méthode process.disconnect() fermera le canal IPC vers le processus parent, permettant au processus enfant de se terminer correctement une fois qu'il n'y a plus d'autres connexions le maintenant en vie.

L'effet de l'appel de process.disconnect() est le même que l'appel de ChildProcess.disconnect() depuis le processus parent.

Si le processus Node.js n'a pas été créé avec un canal IPC, process.disconnect() sera undefined.

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

[Historique]

Version	Modifications
v9.0.0	Ajout de la prise en charge de l'argument `flags`.
v0.1.16	Ajouté dans : v0.1.16

module <Object>
filename <string>
flags <os.constants.dlopen> Par défaut : os.constants.dlopen.RTLD_LAZY

La méthode process.dlopen() permet de charger dynamiquement des objets partagés. Elle est principalement utilisée par require() pour charger des extensions C++, et ne doit pas être utilisée directement, sauf dans des cas particuliers. En d'autres termes, require() doit être préféré à process.dlopen() sauf s'il existe des raisons spécifiques telles que des drapeaux dlopen personnalisés ou le chargement à partir de modules ES.

L'argument flags est un entier qui permet de spécifier le comportement de dlopen. Voir la documentation os.constants.dlopen pour plus de détails.

Une exigence importante lors de l'appel de process.dlopen() est que l'instance module doit être passée. Les fonctions exportées par l'extension C++ sont alors accessibles via module.exports.

L'exemple ci-dessous montre comment charger une extension C++, nommée local.node, qui exporte une fonction foo. Tous les symboles sont chargés avant le retour de l'appel, en passant la constante RTLD_NOW. Dans cet exemple, la constante est supposée être disponible.

ESMCJS

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

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

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

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

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

Ajouté dans : v8.0.0

warning <string> | <Error> L'avertissement à émettre.
options <Object>
- type <string> Lorsque warning est une String, type est le nom à utiliser pour le type d'avertissement émis. Par défaut : 'Warning'.
- code <string> Un identifiant unique pour l'instance d'avertissement émise.
- ctor <Function> Lorsque warning est une String, ctor est une fonction optionnelle utilisée pour limiter la trace de la pile générée. Par défaut : process.emitWarning.
- detail <string> Texte supplémentaire à inclure avec l’erreur.

La méthode process.emitWarning() peut être utilisée pour émettre des avertissements de processus personnalisés ou spécifiques à l’application. Ceux-ci peuvent être écoutés en ajoutant un gestionnaire à l’événement 'warning'.

ESMCJS

import { emitWarning } from 'node:process'

// Émettre un avertissement avec un code et des détails supplémentaires.
emitWarning('Quelque chose s’est produit !', {
  code: 'MY_WARNING',
  detail: 'Voici des informations supplémentaires',
})
// Émet :
// (node:56338) [MY_WARNING] Avertissement : Quelque chose s’est produit !
// Voici des informations supplémentaires

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

// Émettre un avertissement avec un code et des détails supplémentaires.
emitWarning('Quelque chose s’est produit !', {
  code: 'MY_WARNING',
  detail: 'Voici des informations supplémentaires',
})
// Émet :
// (node:56338) [MY_WARNING] Avertissement : Quelque chose s’est produit !
// Voici des informations supplémentaires

Dans cet exemple, un objet Error est généré en interne par process.emitWarning() et transmis au gestionnaire 'warning'.

ESMCJS

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // 'Quelque chose s’est produit !'
  console.warn(warning.code) // 'MY_WARNING'
  console.warn(warning.stack) // Trace de la pile
  console.warn(warning.detail) // 'Voici des informations supplémentaires'
})

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // 'Quelque chose s’est produit !'
  console.warn(warning.code) // 'MY_WARNING'
  console.warn(warning.stack) // Trace de la pile
  console.warn(warning.detail) // 'Voici des informations supplémentaires'
})

Si warning est transmis en tant qu’objet Error, l’argument options est ignoré.

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

Ajouté dans : v6.0.0

avertissement <string> | <Error> L’avertissement à émettre.
type <string> Lorsque avertissement est une String, type est le nom à utiliser pour le type d’avertissement émis. Par défaut : 'Warning'.
code <string> Un identifiant unique pour l’instance d’avertissement en cours d’émission.
ctor <Function> Lorsque avertissement est une String, ctor est une fonction facultative utilisée pour limiter la trace de pile générée. Par défaut : process.emitWarning.

ESMCJS

import { emitWarning } from 'node:process'

// Émettre un avertissement à l’aide d’une chaîne.
emitWarning('Quelque chose s’est produit !')
// Émet : (node : 56338) Warning : Quelque chose s’est produit !

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

// Émettre un avertissement à l’aide d’une chaîne.
emitWarning('Quelque chose s’est produit !')
// Émet : (node : 56338) Warning : Quelque chose s’est produit !

ESMCJS

import { emitWarning } from 'node:process'

// Émettre un avertissement à l’aide d’une chaîne et d’un type.
emitWarning('Quelque chose s’est produit !', 'CustomWarning')
// Émet : (node:56338) CustomWarning: Quelque chose s’est produit !

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

// Émettre un avertissement à l’aide d’une chaîne et d’un type.
emitWarning('Quelque chose s’est produit !', 'CustomWarning')
// Émet : (node:56338) CustomWarning: Quelque chose s’est produit !

ESMCJS

import { emitWarning } from 'node:process'

emitWarning('Quelque chose s’est produit !', 'CustomWarning', 'WARN001')
// Émet : (node:56338) [WARN001] CustomWarning : Quelque chose s’est produit !

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

process.emitWarning('Quelque chose s’est produit !', 'CustomWarning', 'WARN001')
// Émet : (node:56338) [WARN001] CustomWarning : Quelque chose s’est produit !

Dans chacun des exemples précédents, un objet Error est généré en interne par process.emitWarning() et transmis au gestionnaire 'warning'.

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Si avertissement est transmis comme un objet Error, il sera transmis au gestionnaire d’événement 'warning' sans modification (et les arguments facultatifs type, code et ctor seront ignorés) :

ESMCJS

import { emitWarning } from 'node:process'

// Émettre un avertissement à l’aide d’un objet Error.
const myWarning = new Error('Quelque chose s’est produit !')
// Utilisez la propriété Error name pour spécifier le nom du type
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// Émet : (node:56338) [WARN001] CustomWarning : Quelque chose s’est produit !

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

// Émettre un avertissement à l’aide d’un objet Error.
const myWarning = new Error('Quelque chose s’est produit !')
// Utilisez la propriété Error name pour spécifier le nom du type
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// Émet : (node:56338) [WARN001] CustomWarning : Quelque chose s’est produit !

Une TypeError est levée si avertissement est autre chose qu’une chaîne ou un objet Error.

Bien que les avertissements de processus utilisent des objets Error, le mécanisme d’avertissement de processus ne remplace pas les mécanismes normaux de traitement des erreurs.

La gestion supplémentaire suivante est implémentée si le type d’avertissement est 'DeprecationWarning' :

Si l’indicateur de ligne de commande --throw-deprecation est utilisé, l’avertissement de dépréciation est levé comme une exception plutôt que d’être émis comme un événement.
Si l’indicateur de ligne de commande --no-deprecation est utilisé, l’avertissement de dépréciation est supprimé.
Si l’indicateur de ligne de commande --trace-deprecation est utilisé, l’avertissement de dépréciation est imprimé dans stderr avec la trace de pile complète.

Éviter les avertissements en double

Il est recommandé de n'émettre des avertissements qu'une seule fois par processus. Pour ce faire, placez emitWarning() derrière un booléen.

ESMCJS

import { emitWarning } from 'node:process'

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning("N'avertir qu'une seule fois !")
  }
}
emitMyWarning()
// Émet : (node : 56339) Avertissement : N'avertir qu'une seule fois !
emitMyWarning()
// N'émet rien

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

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning("N'avertir qu'une seule fois !")
  }
}
emitMyWarning()
// Émet : (node : 56339) Avertissement : N'avertir qu'une seule fois !
emitMyWarning()
// N'émet rien

`process.env`

[Historique]

Version	Changements
v11.14.0	Les threads Worker utiliseront désormais une copie de `process.env` du thread parent par défaut, configurable via l'option `env` du constructeur `Worker`.
v10.0.0	La conversion implicite de la valeur d'une variable en chaîne de caractères est obsolète.
v0.1.27	Ajouté dans : v0.1.27

<Object>

La propriété process.env renvoie un objet contenant l'environnement utilisateur. Voir environ(7).

Voici un exemple de cet objet :

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

Il est possible de modifier cet objet, mais ces modifications ne seront pas reflétées en dehors du processus Node.js, ou (sauf demande explicite) pour d'autres threads Worker. En d'autres termes, l'exemple suivant ne fonctionnerait pas :

bash

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

Alors que le suivant le fera :

ESMCJS

import { env } from 'node:process'

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

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

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

L'attribution d'une propriété sur process.env convertira implicitement la valeur en chaîne de caractères. Ce comportement est obsolète. Les futures versions de Node.js peuvent générer une erreur lorsque la valeur n'est pas une chaîne de caractères, un nombre ou un booléen.

ESMCJS

import { env } from 'node:process'

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

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

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

Utilisez delete pour supprimer une propriété de process.env.

ESMCJS

import { env } from 'node:process'

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

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

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

Sur les systèmes d'exploitation Windows, les variables d'environnement ne sont pas sensibles à la casse.

ESMCJS

import { env } from 'node:process'

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

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

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

Sauf indication contraire lors de la création d'une instance Worker, chaque thread Worker possède sa propre copie de process.env, basée sur le process.env de son thread parent, ou sur ce qui a été spécifié comme option env au constructeur Worker. Les modifications apportées à process.env ne seront pas visibles entre les threads Worker, et seul le thread principal peut effectuer des modifications qui sont visibles par le système d'exploitation ou par les add-ons natifs. Sous Windows, une copie de process.env sur une instance Worker fonctionne de manière sensible à la casse contrairement au thread principal.

`process.execArgv`

Ajouté dans : v0.7.7

<string[]>

La propriété process.execArgv retourne l'ensemble des options de ligne de commande spécifiques à Node.js passées lorsque le processus Node.js a été lancé. Ces options n'apparaissent pas dans le tableau retourné par la propriété process.argv, et n'incluent pas l'exécutable Node.js, le nom du script, ou toute option suivant le nom du script. Ces options sont utiles pour générer des processus enfants avec le même environnement d'exécution que le parent.

bash

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

Résultat dans process.execArgv :

json

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

Et process.argv :

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

Consultez le constructeur Worker pour le comportement détaillé des threads de travail avec cette propriété.

`process.execPath`

Ajouté dans : v0.1.100

<string>

La propriété process.execPath retourne le chemin d'accès absolu de l'exécutable qui a démarré le processus Node.js. Les liens symboliques, s'il y en a, sont résolus.

'/usr/local/bin/node'

`process.exit([code])`

[Historique]

Version	Modifications
v20.0.0	N'accepte qu'un code de type nombre, ou de type chaîne s'il représente un entier.
v0.1.13	Ajouté dans : v0.1.13

code <integer> | <string> | <null> | <undefined> Le code de sortie. Pour le type chaîne, seules les chaînes d'entiers (par exemple, "1") sont autorisées. Par défaut : 0.

La méthode process.exit() demande à Node.js de terminer le processus de manière synchrone avec un code de sortie égal à code. Si code est omis, exit utilise soit le code de "succès" 0 ou la valeur de process.exitCode s'il a été défini. Node.js ne se terminera pas tant que tous les écouteurs d'événements 'exit' n'ont pas été appelés.

Pour sortir avec un code d'erreur :

ESMCJS

import { exit } from 'node:process'

exit(1)

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

exit(1)

Le shell qui a exécuté Node.js doit voir le code de sortie comme 1.

L'appel à process.exit() forcera le processus à se terminer le plus rapidement possible, même s'il reste des opérations asynchrones en attente qui n'ont pas encore été entièrement terminées, y compris les opérations d'E/S vers process.stdout et process.stderr.

Dans la plupart des situations, il n'est en fait pas nécessaire d'appeler process.exit() explicitement. Le processus Node.js se terminera de lui-même s'il n'y a pas de travail supplémentaire en attente dans la boucle d'événements. La propriété process.exitCode peut être définie pour indiquer au processus quel code de sortie utiliser lorsque le processus se termine correctement.

Par exemple, l'exemple suivant illustre une mauvaise utilisation de la méthode process.exit() qui pourrait entraîner la troncature et la perte de données imprimées sur stdout :

ESMCJS

import { exit } from 'node:process'

// Voici un exemple de ce qu'il *ne faut pas* faire :
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

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

// Voici un exemple de ce qu'il *ne faut pas* faire :
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

La raison pour laquelle cela est problématique est que les écritures dans process.stdout dans Node.js sont parfois asynchrones et peuvent se produire sur plusieurs cycles de la boucle d'événements Node.js. L'appel à process.exit(), cependant, force le processus à se terminer avant que ces écritures supplémentaires dans stdout puissent être effectuées.

Au lieu d'appeler process.exit() directement, le code devrait définir process.exitCode et permettre au processus de se terminer naturellement en évitant de planifier tout travail supplémentaire pour la boucle d'événements :

ESMCJS

import process from 'node:process'

// Comment définir correctement le code de sortie tout en laissant
// le processus se terminer correctement.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

const process = require('node:process')

// Comment définir correctement le code de sortie tout en laissant
// le processus se terminer correctement.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

S'il est nécessaire de mettre fin au processus Node.js en raison d'une condition d'erreur, le fait de lever une erreur non interceptée et de permettre au processus de se terminer en conséquence est plus sûr que d'appeler process.exit().

Dans les threads Worker, cette fonction arrête le thread courant plutôt que le processus courant.

`process.exitCode`

[Historique]

Version	Modifications
v20.0.0	N'accepte qu'un code de type nombre, ou de type chaîne s'il représente un entier.
v0.11.8	Ajouté dans : v0.11.8

<entier> | <chaîne> | <null> | <indéfini> Le code de sortie. Pour le type chaîne, seules les chaînes entières (par exemple, "1") sont autorisées. Par défaut : undefined.

Un nombre qui sera le code de sortie du processus, lorsque le processus se termine normalement ou est arrêté via process.exit() sans spécifier de code.

La spécification d'un code à process.exit(code) remplace tout paramètre précédent de process.exitCode.

`process.features.cached_builtins`

Ajouté dans : v12.0.0

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js met en cache les modules intégrés.

`process.features.debug`

Ajouté dans : v0.5.5

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js est une version de débogage.

`process.features.inspector`

Ajouté dans : v11.10.0

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js inclut l'inspecteur.

`process.features.ipv6`

Ajouté dans : v0.5.3

Déprécié depuis : v23.4.0

[Stable : 0 - Déprécié]

Stable : 0 Stabilité : 0 - Déprécié. Cette propriété est toujours vraie et toute vérification basée sur elle est redondante.

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js inclut la prise en charge d'IPv6.

Puisque toutes les versions de Node.js prennent en charge IPv6, cette valeur est toujours true.

`process.features.require_module`

Ajouté dans : v23.0.0

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js prend en charge le chargement des modules ECMAScript à l'aide de require().

`process.features.tls`

Ajouté dans : v0.5.3

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js inclut la prise en charge de TLS.

`process.features.tls_alpn`

Ajouté dans : v4.8.0

Obsolète depuis : v23.4.0

[Stable : 0 - Obsolète]

Stable : 0 Stabilité : 0 - Obsolète. Utilisez process.features.tls à la place.

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js inclut la prise en charge d’ALPN dans TLS.

Dans Node.js 11.0.0 et les versions ultérieures, les dépendances OpenSSL incluent la prise en charge inconditionnelle d’ALPN. Cette valeur est donc identique à celle de process.features.tls.

`process.features.tls_ocsp`

Ajouté dans : v0.11.13

Obsolète depuis : v23.4.0

[Stable : 0 - Obsolète]

Stable : 0 Stabilité : 0 - Obsolète. Utilisez process.features.tls à la place.

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js inclut la prise en charge d’OCSP dans TLS.

Dans Node.js 11.0.0 et les versions ultérieures, les dépendances OpenSSL incluent la prise en charge inconditionnelle d’OCSP. Cette valeur est donc identique à celle de process.features.tls.

`process.features.tls_sni`

Ajouté dans : v0.5.3

Obsolète depuis : v23.4.0

[Stable : 0 - Obsolète]

Stable : 0 Stabilité : 0 - Obsolète. Utilisez process.features.tls à la place.

<booléen>

Une valeur booléenne qui est true si la version actuelle de Node.js inclut la prise en charge de SNI dans TLS.

Dans Node.js 11.0.0 et les versions ultérieures, les dépendances OpenSSL incluent la prise en charge inconditionnelle de SNI. Cette valeur est donc identique à celle de process.features.tls.

`process.features.typescript`

Ajouté dans : v23.0.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1.1 - Développement actif

<booléen> | <chaîne>

Une valeur qui est "strip" si Node.js est exécuté avec --experimental-strip-types, "transform" si Node.js est exécuté avec --experimental-transform-types, et false sinon.

`process.features.uv`

Ajouté dans : v0.5.3

Déprécié depuis : v23.4.0

[Stable : 0 - Déprécié]

Stable : 0 Stabilité : 0 - Déprécié. Cette propriété est toujours vraie, et toutes les vérifications basées dessus sont redondantes.

<booléen>

Une valeur booléenne qui est true si la build Node.js actuelle inclut le support pour libuv.

Puisqu’il n’est pas possible de construire Node.js sans libuv, cette valeur est toujours true.

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

Ajouté dans : v22.5.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1.1 - Développement actif

ref <Objet> | <Fonction> La référence à la ressource qui est suivie.
callback <Fonction> La fonction de rappel à appeler lorsque la ressource est finalisée.
- ref <Objet> | <Fonction> La référence à la ressource qui est suivie.
- event <chaîne> L’événement qui a déclenché la finalisation. Par défaut à 'exit'.

Cette fonction enregistre une fonction de rappel à appeler lorsque le processus émet l’événement exit si l’objet ref n’a pas été collecté par le ramasse-miettes. Si l’objet ref a été collecté par le ramasse-miettes avant que l’événement exit ne soit émis, la fonction de rappel sera supprimée du registre de finalisation, et elle ne sera pas appelée lors de la sortie du processus.

À l’intérieur de la fonction de rappel, vous pouvez libérer les ressources allouées par l’objet ref. Sachez que toutes les limitations appliquées à l’événement beforeExit sont également appliquées à la fonction callback, ce qui signifie qu’il est possible que la fonction de rappel ne soit pas appelée dans des circonstances particulières.

L’idée de cette fonction est de vous aider à libérer des ressources lorsque le processus de démarrage se termine, mais aussi de laisser l’objet être collecté par le ramasse-miettes s’il n’est plus utilisé.

Par exemple : vous pouvez enregistrer un objet qui contient un tampon, vous voulez vous assurer que le tampon est libéré lorsque le processus se termine, mais si l’objet est collecté par le ramasse-miettes avant la fin du processus, nous n’avons plus besoin de libérer le tampon, donc dans ce cas, nous supprimons simplement la fonction de rappel du registre de finalisation.

CJSESM

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

// Veuillez vous assurer que la fonction passée à finalization.register()
// ne crée pas de fermeture autour d’objets inutiles.
function onFinalize(obj, event) {
  // Vous pouvez faire ce que vous voulez avec l’objet
  obj.dispose()
}

function setup() {
  // Cet objet peut être collecté en toute sécurité par le ramasse-miettes,
  // et la fonction d’arrêt qui en résulte ne sera pas appelée.
  // Il n’y a pas de fuites.
  const myDisposableObject = {
    dispose() {
      // Libérez vos ressources de manière synchrone
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

import { finalization } from 'node:process'

// Veuillez vous assurer que la fonction passée à finalization.register()
// ne crée pas de fermeture autour d’objets inutiles.
function onFinalize(obj, event) {
  // Vous pouvez faire ce que vous voulez avec l’objet
  obj.dispose()
}

function setup() {
  // Cet objet peut être collecté en toute sécurité par le ramasse-miettes,
  // et la fonction d’arrêt qui en résulte ne sera pas appelée.
  // Il n’y a pas de fuites.
  const myDisposableObject = {
    dispose() {
      // Libérez vos ressources de manière synchrone
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

Le code ci-dessus repose sur les hypothèses suivantes :

les fonctions fléchées sont évitées
il est recommandé que les fonctions régulières se trouvent dans le contexte global (racine)

Les fonctions régulières pourraient faire référence au contexte où vit obj, ce qui empêcherait obj d’être collecté par le ramasse-miettes.

Les fonctions fléchées conserveront le contexte précédent. Prenons, par exemple :

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

    // Même quelque chose comme ça est fortement déconseillé
    // finalization.register(this, () => this.dispose());
  }
  dispose() {}
}

Il est très peu probable (mais pas impossible) que cet objet soit collecté par le ramasse-miettes, mais s’il ne l’est pas, dispose sera appelé lorsque process.exit est appelé.

Soyez prudent et évitez de vous fier à cette fonctionnalité pour la suppression des ressources critiques, car il n’est pas garanti que la fonction de rappel sera appelée dans toutes les circonstances.

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

Ajouté dans : v22.5.0

[Stable: 1 - Expérimental]

Stable: 1 Stabilité: 1.1 - Développement actif

ref <Object> | <Function> La référence à la ressource qui est suivie.
callback <Function> La fonction de rappel à appeler lorsque la ressource est finalisée.
- ref <Object> | <Function> La référence à la ressource qui est suivie.
- event <string> L'événement qui a déclenché la finalisation. La valeur par défaut est 'beforeExit'.

Cette fonction se comporte exactement comme register, sauf que la fonction de rappel sera appelée lorsque le processus émet l'événement beforeExit si l'objet ref n'a pas été collecté par le ramasse-miettes.

Sachez que toutes les limitations appliquées à l'événement beforeExit sont également appliquées à la fonction callback, ce qui signifie qu'il est possible que la fonction de rappel ne soit pas appelée dans des circonstances particulières.

`process.finalization.unregister(ref)`

Ajouté dans : v22.5.0

[Stable: 1 - Expérimental]

Stable: 1 Stabilité: 1.1 - Développement actif

ref <Object> | <Function> La référence à la ressource qui a été enregistrée précédemment.

Cette fonction supprime l'enregistrement de l'objet du registre de finalisation, de sorte que la fonction de rappel ne sera plus appelée.

CJSESM

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

// Veuillez vous assurer que la fonction passée à finalization.register()
// ne crée pas de fermeture autour d'objets inutiles.
function onFinalize(obj, event) {
  // Vous pouvez faire ce que vous voulez avec l'objet
  obj.dispose()
}

function setup() {
  // Cet objet peut être collecté en toute sécurité par le ramasse-miettes,
  // et la fonction d'arrêt résultante ne sera pas appelée.
  // Il n'y a pas de fuites.
  const myDisposableObject = {
    dispose() {
      // Libérez vos ressources de manière synchrone
    },
  }

  finalization.register(myDisposableObject, onFinalize)

  // Faire quelque chose

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

setup()

import { finalization } from 'node:process'

// Veuillez vous assurer que la fonction passée à finalization.register()
// ne crée pas de fermeture autour d'objets inutiles.
function onFinalize(obj, event) {
  // Vous pouvez faire ce que vous voulez avec l'objet
  obj.dispose()
}

function setup() {
  // Cet objet peut être collecté en toute sécurité par le ramasse-miettes,
  // et la fonction d'arrêt résultante ne sera pas appelée.
  // Il n'y a pas de fuites.
  const myDisposableObject = {
    dispose() {
      // Libérez vos ressources de manière synchrone
    },
  }

  // Veuillez vous assurer que la fonction passée à finalization.register()
  // ne crée pas de fermeture autour d'objets inutiles.
  function onFinalize(obj, event) {
    // Vous pouvez faire ce que vous voulez avec l'objet
    obj.dispose()
  }

  finalization.register(myDisposableObject, onFinalize)

  // Faire quelque chose

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

setup()

`process.getActiveResourcesInfo()`

Ajouté dans : v17.3.0, v16.14.0

[Stable: 1 - Expérimental]

Stable: 1 Stabilité: 1 - Expérimental

Retourne : <string[]>

La méthode process.getActiveResourcesInfo() retourne un tableau de chaînes de caractères contenant les types de ressources actives qui maintiennent actuellement la boucle d’événements active.

ESMCJS

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

console.log('Avant :', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('Après :', getActiveResourcesInfo())
// Affiche :
//   Avant : [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   Après : [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

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

console.log('Avant :', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('Après :', getActiveResourcesInfo())
// Affiche :
//   Avant : [ 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   Après : [ 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

`process.getBuiltinModule(id)`

Ajouté dans : v22.3.0, v20.16.0

id <string> ID du module intégré demandé.
Retourne : <Object> | <undefined>

process.getBuiltinModule(id) fournit un moyen de charger les modules intégrés dans une fonction disponible globalement. Les modules ES qui doivent prendre en charge d’autres environnements peuvent l’utiliser pour charger conditionnellement un intégré Node.js lorsqu’il est exécuté dans Node.js, sans avoir à gérer l’erreur de résolution qui peut être levée par import dans un environnement non-Node.js ou avoir à utiliser import() dynamique, ce qui transforme soit le module en module asynchrone, soit transforme une API synchrone en API asynchrone.

if (globalThis.process?.getBuiltinModule) {
  // S’exécute dans Node.js, utilisez le module fs de Node.js.
  const fs = globalThis.process.getBuiltinModule('fs')
  // Si `require()` est nécessaire pour charger des modules utilisateurs, utilisez createRequire()
  const module = globalThis.process.getBuiltinModule('module')
  const require = module.createRequire(import.meta.url)
  const foo = require('foo')
}

Si id spécifie un module intégré disponible dans le processus Node.js actuel, la méthode process.getBuiltinModule(id) retourne le module intégré correspondant. Si id ne correspond à aucun module intégré, undefined est retourné.

process.getBuiltinModule(id) accepte les ID de modules intégrés reconnus par module.isBuiltin(id). Certains modules intégrés doivent être chargés avec le préfixe node:, voir modules intégrés avec préfixe node: obligatoire. Les références retournées par process.getBuiltinModule(id) pointent toujours vers le module intégré correspondant à id même si les utilisateurs modifient require.cache de sorte que require(id) retourne autre chose.

`process.getegid()`

Ajouté dans : v2.0.0

La méthode process.getegid() renvoie l'identité numérique du groupe effectif du processus Node.js. (Voir getegid(2).)

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Cette fonction n'est disponible que sur les plateformes POSIX (c'est-à-dire pas Windows ou Android).

`process.geteuid()`

Ajouté dans : v2.0.0

Renvoie : <Object>

La méthode process.geteuid() renvoie l'identité numérique de l'utilisateur effectif du processus. (Voir geteuid(2).)

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Cette fonction n'est disponible que sur les plateformes POSIX (c'est-à-dire pas Windows ou Android).

`process.getgid()`

Ajouté dans : v0.1.31

Renvoie : <Object>

La méthode process.getgid() renvoie l'identité numérique du groupe du processus. (Voir getgid(2).)

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Cette fonction n'est disponible que sur les plateformes POSIX (c'est-à-dire pas Windows ou Android).

`process.getgroups()`

Ajouté dans : v0.9.4

Renvoie : <integer[]>

La méthode process.getgroups() renvoie un tableau avec les ID de groupes supplémentaires. POSIX ne précise pas si l'ID de groupe effectif est inclus, mais Node.js s'assure qu'il le soit toujours.

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Cette fonction n'est disponible que sur les plateformes POSIX (c'est-à-dire pas Windows ou Android).

`process.getuid()`

Ajouté dans : v0.1.28

Retourne : <entier>

La méthode process.getuid() retourne l’identité numérique de l’utilisateur du processus. (Voir getuid(2).)

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

Cette fonction est uniquement disponible sur les plates-formes POSIX (c’est-à-dire pas sur Windows ou Android).

`process.hasUncaughtExceptionCaptureCallback()`

Ajouté dans : v9.3.0

Retourne : <boolean>

Indique si un rappel a été défini en utilisant process.setUncaughtExceptionCaptureCallback().

`process.hrtime([time])`

Ajouté dans : v0.7.6

[Stable : 3 - Hérité]

Stable : 3 Stabilité : 3 - Hérité. Utilisez plutôt process.hrtime.bigint().

time <entier[]> Le résultat d’un appel précédent à process.hrtime()
Retourne : <entier[]>

Il s’agit de l’ancienne version de process.hrtime.bigint() avant l’introduction de bigint en JavaScript.

La méthode process.hrtime() retourne le temps réel haute résolution actuel dans un Array tuple [secondes, nanosecondes], où nanosecondes est la partie restante du temps réel qui ne peut pas être représentée en précision de seconde.

time est un paramètre facultatif qui doit être le résultat d’un appel précédent à process.hrtime() pour faire la différence avec le temps actuel. Si le paramètre passé n’est pas un Array tuple, un TypeError sera lancé. Passer un tableau défini par l’utilisateur au lieu du résultat d’un appel précédent à process.hrtime() entraînera un comportement indéfini.

Ces temps sont relatifs à un temps arbitraire dans le passé, et ne sont pas liés à l’heure de la journée et ne sont donc pas sujets à la dérive de l’horloge. L’utilisation principale est pour mesurer les performances entre les intervalles :

ESMCJS

import { hrtime } from 'node:process'

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

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

  console.log(`Le benchmark a pris ${diff[0] * NS_PAR_SEC + diff[1]} nanosecondes`)
  // Le benchmark a pris 1000000552 nanosecondes
}, 1000)

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

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

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

  console.log(`Le benchmark a pris ${diff[0] * NS_PAR_SEC + diff[1]} nanosecondes`)
  // Le benchmark a pris 1000000552 nanosecondes
}, 1000)

`process.hrtime.bigint()`

Ajouté dans : v10.7.0

Retourne : <bigint>

La version bigint de la méthode process.hrtime() retournant le temps réel haute résolution actuel en nanosecondes sous forme de bigint.

Contrairement à process.hrtime(), elle ne prend pas en charge un argument time supplémentaire étant donné que la différence peut simplement être calculée directement par soustraction des deux bigint.

ESMCJS

import { hrtime } from 'node:process'

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

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

  console.log(`L'évaluation comparative a pris ${end - start} nanosecondes`)
  // L'évaluation comparative a pris 1154389282 nanosecondes
}, 1000)

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

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

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

  console.log(`L'évaluation comparative a pris ${end - start} nanosecondes`)
  // L'évaluation comparative a pris 1154389282 nanosecondes
}, 1000)

`process.initgroups(user, extraGroup)`

Ajouté dans : v0.9.4

user <string> | <number> Le nom d’utilisateur ou l’identifiant numérique.
extraGroup <string> | <number> Un nom de groupe ou un identifiant numérique.

La méthode process.initgroups() lit le fichier /etc/group et initialise la liste d’accès au groupe, en utilisant tous les groupes dont l’utilisateur est membre. Il s’agit d’une opération privilégiée qui nécessite que le processus Node.js ait un accès root ou la capacité CAP_SETGID.

Soyez prudent lors de la suppression des privilèges :

ESMCJS

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

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // changer d’utilisateur
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // supprimer le gid root
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

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

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // changer d’utilisateur
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // supprimer le gid root
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

Cette fonction n’est disponible que sur les plates-formes POSIX (c’est-à-dire pas Windows ou Android). Cette fonctionnalité n’est pas disponible dans les threads Worker.

`process.kill(pid[, signal])`

Ajouté dans : v0.0.6

pid <number> Un ID de processus
signal <string> | <number> Le signal à envoyer, soit sous forme de chaîne, soit sous forme de nombre. Par défaut : 'SIGTERM'.

La méthode process.kill() envoie le signal au processus identifié par pid.

Les noms de signaux sont des chaînes telles que 'SIGINT' ou 'SIGHUP'. Consultez Événements de signal et kill(2) pour plus d’informations.

Cette méthode lèvera une erreur si le pid cible n’existe pas. Dans un cas particulier, un signal de 0 peut être utilisé pour tester l’existence d’un processus. Les plateformes Windows lèveront une erreur si le pid est utilisé pour tuer un groupe de processus.

Bien que le nom de cette fonction soit process.kill(), il s’agit en réalité d’un simple expéditeur de signaux, comme l’appel système kill. Le signal envoyé peut faire autre chose que tuer le processus cible.

ESMCJS

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

process.on('SIGHUP', () => {
  console.log('Signal SIGHUP reçu.')
})

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

kill(process.pid, 'SIGHUP')

const process = require('node:process')

process.on('SIGHUP', () => {
  console.log('Signal SIGHUP reçu.')
})

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

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

Lorsque SIGUSR1 est reçu par un processus Node.js, Node.js démarre le débogueur. Consultez Événements de signal.

`process.loadEnvFile(path)`

Ajouté dans : v21.7.0, v20.12.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1.1 - Développement actif

path <string> | <URL> | <Buffer> | <undefined>. Par défaut : './.env'

Charge le fichier .env dans process.env. L’utilisation de NODE_OPTIONS dans le fichier .env n’aura aucun effet sur Node.js.

CJSESM

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

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

`process.mainModule`

Ajouté en : v0.1.17

Déprécié depuis : v14.0.0

[Stable: 0 - Déprécié]

Stable: 0 Stabilité: 0 - Déprécié: Utilisez plutôt require.main.

<Object>

La propriété process.mainModule fournit une autre manière de récupérer require.main. La différence est que si le module principal change pendant l'exécution, require.main peut toujours faire référence au module principal d'origine dans les modules qui ont été requis avant que le changement ne se produise. Généralement, on peut supposer sans risque que les deux font référence au même module.

Comme avec require.main, process.mainModule sera undefined s'il n'y a pas de script d'entrée.

`process.memoryUsage()`

[Historique]

Version	Modifications
v13.9.0, v12.17.0	Ajout de `arrayBuffers` à l'objet retourné.
v7.2.0	Ajout de `external` à l'objet retourné.
v0.1.16	Ajouté en: v0.1.16

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

Retourne un objet décrivant l'utilisation de la mémoire du processus Node.js mesurée en octets.

ESMCJS

import { memoryUsage } from 'node:process'

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

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

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

heapTotal et heapUsed font référence à l'utilisation de la mémoire de V8.
external fait référence à l'utilisation de la mémoire des objets C++ liés aux objets JavaScript gérés par V8.
rss, Resident Set Size, est la quantité d'espace occupé dans la mémoire principale (qui est un sous-ensemble de la mémoire totale allouée) pour le processus, y compris tous les objets et codes C++ et JavaScript.
arrayBuffers fait référence à la mémoire allouée pour les ArrayBuffers et les SharedArrayBuffers, y compris tous les Buffers de Node.js. Ceci est également inclus dans la valeur external. Lorsque Node.js est utilisé comme une bibliothèque intégrée, cette valeur peut être 0 car les allocations pour les ArrayBuffers peuvent ne pas être suivies dans ce cas.

Lors de l'utilisation des threads Worker, rss sera une valeur valide pour l'ensemble du processus, tandis que les autres champs ne feront référence qu'au thread actuel.

La méthode process.memoryUsage() itère sur chaque page pour recueillir des informations sur l'utilisation de la mémoire, ce qui peut être lent en fonction des allocations de mémoire du programme.

`process.memoryUsage.rss()`

Ajouté dans : v15.6.0, v14.18.0

Retourne : <integer>

La méthode process.memoryUsage.rss() renvoie un entier représentant la taille de l’ensemble résident (RSS) en octets.

La taille de l’ensemble résident est la quantité d’espace occupée dans la mémoire principale (c’est-à-dire un sous-ensemble de la mémoire totale allouée) pour le processus, y compris tous les objets et codes C++ et JavaScript.

Il s’agit de la même valeur que la propriété rss fournie par process.memoryUsage(), mais process.memoryUsage.rss() est plus rapide.

ESMCJS

import { memoryUsage } from 'node:process'

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

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

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

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

[Historique]

Version	Modifications
v22.7.0, v20.18.0	Stabilité modifiée en Legacy.
v18.0.0	Le fait de passer un rappel non valide à l’argument `callback` lève désormais `ERR_INVALID_ARG_TYPE` au lieu de `ERR_INVALID_CALLBACK`.
v1.8.1	Les arguments supplémentaires après `callback` sont désormais pris en charge.
v0.1.26	Ajouté dans : v0.1.26

[Stable : 3 - Legacy]

Stable : 3 Stabilité : 3 - Legacy : utilisez plutôt queueMicrotask().

callback <Function>
...args <any> Arguments supplémentaires à transmettre lors de l’invocation de callback

process.nextTick() ajoute callback à la « file d’attente du prochain tick ». Cette file d’attente est complètement vidée une fois que l’opération actuelle sur la pile JavaScript a terminé son exécution et avant que la boucle d’événement ne soit autorisée à continuer. Il est possible de créer une boucle infinie si l’on devait appeler récursivement process.nextTick(). Consultez le guide Boucle d’événement pour plus d’informations.

ESMCJS

import { nextTick } from 'node:process'

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

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

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

C’est important lors du développement d’API afin de donner aux utilisateurs la possibilité d’attribuer des gestionnaires d’événements après qu’un objet a été construit, mais avant que toute E/S ne se soit produite :

ESMCJS

import { nextTick } from 'node:process'

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

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

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

// thing.startDoingStuff() est appelé maintenant, et non avant.

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

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

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

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

// thing.startDoingStuff() est appelé maintenant, et non avant.

Il est très important que les API soient soit 100 % synchrones, soit 100 % asynchrones. Examinez cet exemple :

// AVERTISSEMENT !  NE PAS UTILISER !  MAUVAIS DANGER NON SÉCURISÉ !
function maybeSync(arg, cb) {
  if (arg) {
    cb()
    return
  }

  fs.stat('file', cb)
}

Cette API est dangereuse car dans le cas suivant :

const maybeTrue = Math.random() > 0.5

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

bar()

Il n’est pas clair si foo() ou bar() sera appelé en premier.

L’approche suivante est bien meilleure :

ESMCJS

import { nextTick } from 'node:process'

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

  fs.stat('file', cb)
}

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

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

  fs.stat('file', cb)
}

Quand utiliser `queueMicrotask()` vs. `process.nextTick()`

L'API queueMicrotask() est une alternative à process.nextTick() qui reporte également l'exécution d'une fonction en utilisant la même file d'attente de microtâches que celle utilisée pour exécuter les gestionnaires then, catch et finally des promesses résolues. Dans Node.js, chaque fois que la "file d'attente du prochain tick" est vidée, la file d'attente des microtâches est vidée immédiatement après.

ESMCJS

import { nextTick } from 'node:process'

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

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

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

Pour la plupart des cas d'utilisation en espace utilisateur, l'API queueMicrotask() fournit un mécanisme portable et fiable pour reporter l'exécution qui fonctionne dans plusieurs environnements de plateforme JavaScript et doit être privilégié par rapport à process.nextTick(). Dans des scénarios simples, queueMicrotask() peut être un remplacement direct de process.nextTick().

console.log('début')
queueMicrotask(() => {
  console.log('callback microtâche')
})
console.log('planifié')
// Sortie :
// début
// planifié
// callback microtâche

Une différence notable entre les deux API est que process.nextTick() permet de spécifier des valeurs supplémentaires qui seront passées en arguments à la fonction différée lorsqu'elle est appelée. Pour obtenir le même résultat avec queueMicrotask(), il faut utiliser soit une fermeture, soit une fonction liée :

function deferred(a, b) {
  console.log('microtâche', a + b)
}

console.log('début')
queueMicrotask(deferred.bind(undefined, 1, 2))
console.log('planifié')
// Sortie :
// début
// planifié
// microtâche 3

Il existe des différences mineures dans la manière dont les erreurs levées dans la file d'attente du prochain tick et la file d'attente des microtâches sont gérées. Les erreurs levées dans un callback de microtâche en file d'attente doivent être traitées dans le callback en file d'attente lorsque cela est possible. Si ce n'est pas le cas, le gestionnaire d'événements process.on('uncaughtException') peut être utilisé pour capturer et gérer les erreurs.

En cas de doute, à moins que les capacités spécifiques de process.nextTick() ne soient nécessaires, utilisez queueMicrotask().

`process.noDeprecation`

Ajouté dans : v0.8.0

<boolean>

La propriété process.noDeprecation indique si l’indicateur --no-deprecation est défini sur le processus Node.js actuel. Consultez la documentation de l’événement 'warning' et de la méthode emitWarning() pour plus d’informations sur le comportement de cet indicateur.

`process.permission`

Ajouté dans : v20.0.0

<Object>

Cette API est disponible via l’indicateur --permission.

process.permission est un objet dont les méthodes sont utilisées pour gérer les autorisations du processus actuel. Vous trouverez des documents supplémentaires dans le Modèle d’autorisation.

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

Ajouté dans : v20.0.0

scope <string>
reference <string>
Retourne : <boolean>

Vérifie que le processus est en mesure d’accéder à l’étendue et à la référence données. Si aucune référence n’est fournie, une portée globale est supposée, par exemple, process.permission.has('fs.read') vérifiera si le processus possède TOUTES les autorisations de lecture du système de fichiers.

La référence a une signification basée sur la portée fournie. Par exemple, la référence lorsque la portée est le système de fichiers signifie les fichiers et les dossiers.

Les portées disponibles sont :

fs - Tout le système de fichiers
fs.read - Opérations de lecture du système de fichiers
fs.write - Opérations d’écriture du système de fichiers
child - Opérations de création de processus enfant
worker - Opération de création de thread Worker

// Vérifie si le processus a l’autorisation de lire le fichier README
process.permission.has('fs.read', './README.md')
// Vérifie si le processus a des opérations d’autorisation de lecture
process.permission.has('fs.read')

`process.pid`

Ajouté dans : v0.1.15

<integer>

La propriété process.pid renvoie le PID du processus.

ESMCJS

import { pid } from 'node:process'

console.log(`Ce processus a le PID ${pid}`)

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

console.log(`Ce processus a le PID ${pid}`)

`process.platform`

Ajouté dans : v0.1.16

<string>

La propriété process.platform renvoie une chaîne de caractères identifiant la plateforme du système d'exploitation pour laquelle le binaire Node.js a été compilé.

Les valeurs possibles sont actuellement :

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

ESMCJS

import { platform } from 'node:process'

console.log(`Cette plateforme est ${platform}`)

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

console.log(`Cette plateforme est ${platform}`)

La valeur 'android' peut également être renvoyée si Node.js est construit sur le système d'exploitation Android. Cependant, le support d'Android dans Node.js est expérimental.

`process.ppid`

Ajouté dans : v9.2.0, v8.10.0, v6.13.0

<integer>

La propriété process.ppid renvoie le PID du parent du processus actuel.

ESMCJS

import { ppid } from 'node:process'

console.log(`Le processus parent a le PID ${ppid}`)

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

console.log(`Le processus parent a le PID ${ppid}`)

`process.release`

[Historique]

Version	Modifications
v4.2.0	La propriété `lts` est désormais supportée.
v3.0.0	Ajouté dans : v3.0.0

<Object>

La propriété process.release renvoie un Object contenant des métadonnées relatives à la version actuelle, y compris les URL du fichier tarball source et du fichier tarball contenant uniquement les en-têtes.

process.release contient les propriétés suivantes :

name <string> Une valeur qui sera toujours 'node'.
sourceUrl <string> une URL absolue pointant vers un fichier .tar.gz contenant le code source de la version actuelle.
headersUrl<string> une URL absolue pointant vers un fichier .tar.gz contenant uniquement les fichiers d'en-tête source de la version actuelle. Ce fichier est significativement plus petit que le fichier source complet et peut être utilisé pour compiler des extensions natives Node.js.
libUrl <string> | <undefined> une URL absolue pointant vers un fichier node.lib correspondant à l'architecture et à la version de la version actuelle. Ce fichier est utilisé pour compiler les extensions natives Node.js. Cette propriété n'est présente que sur les versions Windows de Node.js et sera absente sur toutes les autres plateformes.
lts <string> | <undefined> une étiquette de chaîne identifiant l'étiquette LTS pour cette version. Cette propriété n'existe que pour les versions LTS et est undefined pour tous les autres types de versions, y compris les versions Current. Les valeurs valides incluent les noms de code des versions LTS (y compris celles qui ne sont plus prises en charge).
- 'Fermium' pour la ligne LTS 14.x commençant par 14.15.0.
- 'Gallium' pour la ligne LTS 16.x commençant par 16.13.0.
- 'Hydrogen' pour la ligne LTS 18.x commençant par 18.12.0. Pour les autres noms de code de versions LTS, voir Node.js Changelog Archive

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

Dans les builds personnalisées à partir de versions non publiées de l'arborescence source, seule la propriété name peut être présente. Il ne faut pas s'attendre à ce que les propriétés supplémentaires existent.

`process.report`

[Historique]

Version	Changements
v13.12.0, v12.17.0	Cette API n'est plus expérimentale.
v11.8.0	Ajoutée dans : v11.8.0

<Object>

process.report est un objet dont les méthodes sont utilisées pour générer des rapports de diagnostic pour le processus actuel. Une documentation supplémentaire est disponible dans la documentation sur les rapports.

`process.report.compact`

Ajouté dans : v13.12.0, v12.17.0

<boolean>

Écrit les rapports dans un format compact, en JSON sur une seule ligne, plus facilement consommable par les systèmes de traitement des journaux que le format multiligne par défaut conçu pour la consommation humaine.

ESMCJS

import { report } from 'node:process'

console.log(`Les rapports sont-ils compacts ? ${report.compact}`)

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

console.log(`Les rapports sont-ils compacts ? ${report.compact}`)

`process.report.directory`

[Historique]

Version	Changements
v13.12.0, v12.17.0	Cette API n'est plus expérimentale.
v11.12.0	Ajoutée dans : v11.12.0

<string>

Répertoire où le rapport est écrit. La valeur par défaut est la chaîne vide, indiquant que les rapports sont écrits dans le répertoire de travail actuel du processus Node.js.

ESMCJS

import { report } from 'node:process'

console.log(`Le répertoire des rapports est ${report.directory}`)

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

console.log(`Le répertoire des rapports est ${report.directory}`)

`process.report.filename`

[Historique]

Version	Changements
v13.12.0, v12.17.0	Cette API n'est plus expérimentale.
v11.12.0	Ajoutée dans : v11.12.0

<string>

Nom de fichier où le rapport est écrit. S'il est défini sur la chaîne vide, le nom de fichier de sortie sera composé d'un horodatage, du PID et d'un numéro de séquence. La valeur par défaut est la chaîne vide.

Si la valeur de process.report.filename est définie sur 'stdout' ou 'stderr', le rapport est écrit sur le stdout ou le stderr du processus respectivement.

ESMCJS

import { report } from 'node:process'

console.log(`Le nom de fichier du rapport est ${report.filename}`)

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

console.log(`Le nom de fichier du rapport est ${report.filename}`)

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

[Historique]

Version	Changements
v13.12.0, v12.17.0	Cette API n'est plus expérimentale.
v11.8.0	Ajouté dans : v11.8.0

err <Error> Une erreur personnalisée utilisée pour signaler la pile JavaScript.
Retourne : <Object>

Retourne une représentation d’Objet JavaScript d’un rapport de diagnostic pour le processus en cours d’exécution. La trace de la pile JavaScript du rapport est extraite de err, si elle est présente.

ESMCJS

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

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

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

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

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

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

Une documentation supplémentaire est disponible dans la documentation du rapport.

`process.report.reportOnFatalError`

[Historique]

Version	Changements
v15.0.0, v14.17.0	Cette API n'est plus expérimentale.
v11.12.0	Ajouté dans : v11.12.0

<boolean>

Si true, un rapport de diagnostic est généré en cas d'erreurs fatales, telles que les erreurs de mémoire insuffisante ou les assertions C++ qui ont échoué.

ESMCJS

import { report } from 'node:process'

console.log(`Rapport sur une erreur fatale : ${report.reportOnFatalError}`)

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

console.log(`Rapport sur une erreur fatale : ${report.reportOnFatalError}`)

`process.report.reportOnSignal`

[Historique]

Version	Modifications
v13.12.0, v12.17.0	Cette API n'est plus expérimentale.
v11.12.0	Ajouté dans : v11.12.0

<boolean>

Si true, un rapport de diagnostic est généré lorsque le processus reçoit le signal spécifié par process.report.signal.

ESMCJS

import { report } from 'node:process'

console.log(`Rapport sur le signal : ${report.reportOnSignal}`)

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

console.log(`Rapport sur le signal : ${report.reportOnSignal}`)

`process.report.reportOnUncaughtException`

[Historique]

Version	Modifications
v13.12.0, v12.17.0	Cette API n'est plus expérimentale.
v11.12.0	Ajouté dans : v11.12.0

<boolean>

Si true, un rapport de diagnostic est généré en cas d'exception non gérée.

ESMCJS

import { report } from 'node:process'

console.log(`Rapport sur l’exception : ${report.reportOnUncaughtException}`)

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

console.log(`Rapport sur l’exception : ${report.reportOnUncaughtException}`)

`process.report.excludeEnv`

Ajouté dans : v23.3.0

<boolean>

Si true, un rapport de diagnostic est généré sans les variables d'environnement.

`process.report.signal`

[Historique]

Version	Modifications
v13.12.0, v12.17.0	Cette API n'est plus expérimentale.
v11.12.0	Ajouté dans : v11.12.0

<string>

Le signal utilisé pour déclencher la création d'un rapport de diagnostic. La valeur par défaut est 'SIGUSR2'.

ESMCJS

import { report } from 'node:process'

console.log(`Signal de rapport : ${report.signal}`)

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

console.log(`Signal de rapport : ${report.signal}`)

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

[Historique]

Version	Changements
v13.12.0, v12.17.0	Cette API n'est plus expérimentale.
v11.8.0	Ajoutée en : v11.8.0

filename <string> Nom du fichier dans lequel le rapport est écrit. Il doit s’agir d’un chemin relatif qui sera ajouté au répertoire spécifié dans process.report.directory, ou au répertoire de travail actuel du processus Node.js, s’il n’est pas spécifié.
err <Error> Une erreur personnalisée utilisée pour signaler la pile JavaScript.
Retourne : <string> Retourne le nom de fichier du rapport généré.

Écrit un rapport de diagnostic dans un fichier. Si filename n’est pas fourni, le nom de fichier par défaut comprend la date, l’heure, le PID et un numéro de séquence. La trace de pile JavaScript du rapport est extraite de err, si elle est présente.

Si la valeur de filename est définie sur 'stdout' ou 'stderr', le rapport est écrit respectivement dans la sortie standard ou la sortie d’erreur du processus.

ESMCJS

import { report } from 'node:process'

report.writeReport()

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

report.writeReport()

Des documents supplémentaires sont disponibles dans la documentation du rapport.

`process.resourceUsage()`

Ajouté en : v12.6.0

Retourne : <Object> l’utilisation des ressources pour le processus actuel. Toutes ces valeurs proviennent de l’appel uv_getrusage qui retourne une uv_rusage_t struct.
- userCPUTime <integer> correspond à ru_utime calculé en microsecondes. C’est la même valeur que process.cpuUsage().user.
- systemCPUTime <integer> correspond à ru_stime calculé en microsecondes. C’est la même valeur que process.cpuUsage().system.
- maxRSS <integer> correspond à ru_maxrss qui est la taille maximale de l’ensemble résident utilisé en kilo-octets.
- sharedMemorySize <integer> correspond à ru_ixrss, mais n’est pris en charge par aucune plateforme.
- unsharedDataSize <integer> correspond à ru_idrss, mais n’est pris en charge par aucune plateforme.
- unsharedStackSize <integer> correspond à ru_isrss, mais n’est pris en charge par aucune plateforme.
- minorPageFault <integer> correspond à ru_minflt qui est le nombre de défauts de page mineurs pour le processus, voir cet article pour plus de détails.
- majorPageFault <integer> correspond à ru_majflt qui est le nombre de défauts de page majeurs pour le processus, voir cet article pour plus de détails. Ce champ n’est pas pris en charge sur Windows.
- swappedOut <integer> correspond à ru_nswap, mais n’est pris en charge par aucune plateforme.
- fsRead <integer> correspond à ru_inblock qui est le nombre de fois où le système de fichiers a dû effectuer une entrée.
- fsWrite <integer> correspond à ru_oublock qui est le nombre de fois où le système de fichiers a dû effectuer une sortie.
- ipcSent <integer> correspond à ru_msgsnd, mais n’est pris en charge par aucune plateforme.
- ipcReceived <integer> correspond à ru_msgrcv, mais n’est pris en charge par aucune plateforme.
- signalsCount <integer> correspond à ru_nsignals, mais n’est pris en charge par aucune plateforme.
- voluntaryContextSwitches <integer> correspond à ru_nvcsw qui est le nombre de fois où un changement de contexte du CPU a résulté du fait qu’un processus a volontairement abandonné le processeur avant que sa tranche de temps ne soit terminée (généralement pour attendre la disponibilité d’une ressource). Ce champ n’est pas pris en charge sur Windows.
- involuntaryContextSwitches <integer> correspond à ru_nivcsw qui est le nombre de fois où un changement de contexte du CPU a résulté du fait qu’un processus de priorité plus élevée est devenu exécutable ou parce que le processus actuel a dépassé sa tranche de temps. Ce champ n’est pas pris en charge sur Windows.

ESMCJS

import { resourceUsage } from 'node:process'

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

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

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

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

Ajouté dans : v0.5.9

message <Object>
sendHandle <net.Server> | <net.Socket>
options <Object> utilisé pour paramétrer l'envoi de certains types de handles. options prend en charge les propriétés suivantes :
- keepOpen <boolean> Une valeur qui peut être utilisée lors du passage d'instances de net.Socket. Lorsque true, le socket est maintenu ouvert dans le processus d'envoi. Par défaut : false.
callback <Function>
Retourne : <boolean>

Si Node.js est lancé avec un canal IPC, la méthode process.send() peut être utilisée pour envoyer des messages au processus parent. Les messages seront reçus en tant qu'événement 'message' sur l'objet ChildProcess du parent.

Si Node.js n'a pas été lancé avec un canal IPC, process.send sera undefined.

Le message passe par la sérialisation et l'analyse. Le message résultant peut ne pas être identique à celui qui est envoyé à l'origine.

`process.setegid(id)`

Ajouté dans : v2.0.0

id <string> | <number> Un nom ou un ID de groupe

La méthode process.setegid() définit l'identité de groupe effective du processus. (Voir setegid(2).) L'id peut être transmis sous la forme d'un ID numérique ou d'une chaîne de nom de groupe. Si un nom de groupe est spécifié, cette méthode se bloque lors de la résolution de l'ID numérique associé.

ESMCJS

import process from 'node:process'

if (process.getegid && process.setegid) {
  console.log(`GID actuel : ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`Nouveau GID : ${process.getegid()}`)
  } catch (err) {
    console.error(`Échec de la définition du GID : ${err}`)
  }
}

const process = require('node:process')

if (process.getegid && process.setegid) {
  console.log(`GID actuel : ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`Nouveau GID : ${process.getegid()}`)
  } catch (err) {
    console.error(`Échec de la définition du GID : ${err}`)
  }
}

Cette fonction est uniquement disponible sur les plateformes POSIX (c'est-à-dire pas Windows ou Android). Cette fonctionnalité n'est pas disponible dans les threads Worker.

`process.seteuid(id)`

Ajouté dans : v2.0.0

id <string> | <number> Un nom d’utilisateur ou un ID

La méthode process.seteuid() définit l’identité utilisateur effective du processus. (Voir seteuid(2).) L’id peut être transmis soit en tant qu’ID numérique, soit en tant que chaîne de caractères de nom d’utilisateur. Si un nom d’utilisateur est spécifié, la méthode se bloque pendant la résolution de l’ID numérique associé.

ESMCJS

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

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

Cette fonction n’est disponible que sur les plateformes POSIX (c’est-à-dire pas Windows ni Android). Cette fonctionnalité n’est pas disponible dans les threads Worker.

`process.setgid(id)`

Ajouté dans : v0.1.31

id <string> | <number> Le nom ou l’ID du groupe

La méthode process.setgid() définit l’identité du groupe du processus. (Voir setgid(2).) L’id peut être transmis soit en tant qu’ID numérique, soit en tant que chaîne de caractères de nom de groupe. Si un nom de groupe est spécifié, cette méthode se bloque pendant la résolution de l’ID numérique associé.

ESMCJS

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

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

Cette fonction n’est disponible que sur les plateformes POSIX (c’est-à-dire pas Windows ni Android). Cette fonctionnalité n’est pas disponible dans les threads Worker.

`process.setgroups(groups)`

Ajouté dans : v0.9.4

groups <integer[]>

La méthode process.setgroups() définit les ID de groupe supplémentaires pour le processus Node.js. Il s'agit d'une opération privilégiée qui exige que le processus Node.js soit root ou possède la capacité CAP_SETGID.

Le tableau groups peut contenir des ID de groupe numériques, des noms de groupe, ou les deux.

ESMCJS

import process from 'node:process'

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // nouveaux groupes
  } catch (err) {
    console.error(`Échec de la définition des groupes : ${err}`)
  }
}

const process = require('node:process')

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // nouveaux groupes
  } catch (err) {
    console.error(`Échec de la définition des groupes : ${err}`)
  }
}

Cette fonction est uniquement disponible sur les plateformes POSIX (c'est-à-dire pas Windows ou Android). Cette fonctionnalité n'est pas disponible dans les threads Worker.

`process.setuid(id)`

Ajouté dans : v0.1.28

id <integer> | <string>

La méthode process.setuid(id) définit l'identité utilisateur du processus. (Voir setuid(2).) L'id peut être passé soit sous la forme d'un ID numérique, soit sous la forme d'une chaîne de nom d'utilisateur. Si un nom d'utilisateur est spécifié, la méthode se bloque pendant la résolution de l'ID numérique associé.

ESMCJS

import process from 'node:process'

if (process.getuid && process.setuid) {
  console.log(`UID actuel : ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`Nouvel UID : ${process.getuid()}`)
  } catch (err) {
    console.error(`Échec de la définition de l'UID : ${err}`)
  }
}

const process = require('node:process')

if (process.getuid && process.setuid) {
  console.log(`UID actuel : ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`Nouvel UID : ${process.getuid()}`)
  } catch (err) {
    console.error(`Échec de la définition de l'UID : ${err}`)
  }
}

Cette fonction est uniquement disponible sur les plateformes POSIX (c'est-à-dire pas Windows ou Android). Cette fonctionnalité n'est pas disponible dans les threads Worker.

`process.setSourceMapsEnabled(val)`

Ajouté dans : v16.6.0, v14.18.0

[Stable: 1 - Expérimental]

Stable: 1 Stabilité : 1 - Expérimental

val <boolean>

Cette fonction active ou désactive la prise en charge des Source Map v3 pour les traces de pile.

Elle offre les mêmes fonctionnalités que le lancement du processus Node.js avec les options de ligne de commande --enable-source-maps.

Seules les cartes sources des fichiers JavaScript qui sont chargées après l'activation des cartes sources seront analysées et chargées.

`process.setUncaughtExceptionCaptureCallback(fn)`

Ajouté dans : v9.3.0

fn <Function> | <null>

La fonction process.setUncaughtExceptionCaptureCallback() définit une fonction qui sera invoquée lorsqu'une exception non interceptée se produit, qui recevra la valeur de l'exception elle-même comme premier argument.

Si une telle fonction est définie, l'événement 'uncaughtException' ne sera pas émis. Si --abort-on-uncaught-exception a été transmis à partir de la ligne de commande ou défini via v8.setFlagsFromString(), le processus ne s'arrêtera pas. Les actions configurées pour avoir lieu sur les exceptions telles que la génération de rapports seront également affectées.

Pour annuler la fonction de capture, process.setUncaughtExceptionCaptureCallback(null) peut être utilisé. L'appel de cette méthode avec un argument non-null alors qu'une autre fonction de capture est définie lèvera une erreur.

L'utilisation de cette fonction est mutuellement exclusive avec l'utilisation du module intégré domain déprécié.

`process.sourceMapsEnabled`

Ajouté dans : v20.7.0, v18.19.0

[Stable: 1 - Expérimental]

Stable: 1 Stabilité : 1 - Expérimental

<boolean>

La propriété process.sourceMapsEnabled renvoie si la prise en charge de la Source Map v3 pour les traces de pile est activée.

`process.stderr`

<Stream>

La propriété process.stderr renvoie un flux connecté à stderr (fd 2). Il s'agit d'un net.Socket (qui est un flux Duplex) sauf si fd 2 fait référence à un fichier, auquel cas il s'agit d'un flux Writable.

process.stderr diffère des autres flux Node.js de manière importante. Voir note sur les E/S de processus pour plus d'informations.

`process.stderr.fd`

<number>

Cette propriété fait référence à la valeur du descripteur de fichier sous-jacent de process.stderr. La valeur est fixée à 2. Dans les threads Worker, ce champ n'existe pas.

`process.stdin`

<Stream>

La propriété process.stdin renvoie un flux connecté à stdin (fd 0). Il s'agit d'un net.Socket (qui est un flux Duplex) sauf si fd 0 fait référence à un fichier, auquel cas il s'agit d'un flux Readable.

Pour plus de détails sur la façon de lire à partir de stdin, voir readable.read().

En tant que flux Duplex, process.stdin peut également être utilisé en mode "ancien" qui est compatible avec les scripts écrits pour Node.js avant la v0.10. Pour plus d'informations, voir Compatibilité des flux.

En mode de flux "ancien", le flux stdin est mis en pause par défaut, il faut donc appeler process.stdin.resume() pour lire à partir de celui-ci. Notez également que l'appel de process.stdin.resume() lui-même ferait basculer le flux en mode "ancien".

`process.stdin.fd`

<number>

Cette propriété fait référence à la valeur du descripteur de fichier sous-jacent de process.stdin. La valeur est fixée à 0. Dans les threads Worker, ce champ n'existe pas.

`process.stdout`

<Stream>

La propriété process.stdout retourne un flux connecté à stdout (fd 1). Il s'agit d'un net.Socket (qui est un flux Duplex) à moins que fd 1 ne référence un fichier, auquel cas il s'agit d'un flux Writable.

Par exemple, pour copier process.stdin vers process.stdout :

ESMCJS

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

stdin.pipe(stdout)

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

stdin.pipe(stdout)

process.stdout diffère des autres flux Node.js de manière importante. Consultez note sur les E/S de processus pour plus d'informations.

`process.stdout.fd`

<number>

Cette propriété fait référence à la valeur du descripteur de fichier sous-jacent de process.stdout. La valeur est fixée à 1. Dans les threads Worker, ce champ n'existe pas.

Note sur les E/S de processus

process.stdout et process.stderr diffèrent des autres flux Node.js de manières importantes :

Ces comportements sont en partie pour des raisons historiques, car les modifier créerait une incompatibilité ascendante, mais ils sont également attendus par certains utilisateurs.

Les écritures synchrones évitent des problèmes tels que des sorties écrites avec console.log() ou console.error() qui seraient inopinément entrelacées, ou qui ne seraient pas écrites du tout si process.exit() est appelé avant qu'une écriture asynchrone ne soit terminée. Consultez process.exit() pour plus d'informations.

Avertissement: Les écritures synchrones bloquent la boucle d'événement jusqu'à ce que l'écriture soit terminée. Cela peut être quasi instantané dans le cas d'une sortie vers un fichier, mais sous une forte charge du système, les pipes qui ne sont pas lus à l'extrémité de réception, ou avec des terminaux ou des systèmes de fichiers lents, il est possible que la boucle d'événement soit bloquée assez souvent et assez longtemps pour avoir de graves impacts négatifs sur les performances. Cela peut ne pas être un problème lors de l'écriture dans une session de terminal interactive, mais soyez particulièrement attentif lors de la journalisation en production vers les flux de sortie du processus.

Pour vérifier si un flux est connecté à un contexte TTY, vérifiez la propriété isTTY.

Par exemple :

bash

$ node -p "Boolean(process.stdin.isTTY)"
true
$ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
false
$ node -p "Boolean(process.stdout.isTTY)"
true
$ node -p "Boolean(process.stdout.isTTY)" | cat
false

Consultez la documentation TTY pour plus d'informations.

`process.throwDeprecation`

Ajouté dans : v0.9.12

<boolean>

La valeur initiale de process.throwDeprecation indique si l’indicateur --throw-deprecation est défini sur le processus Node.js actuel. process.throwDeprecation est modifiable, de sorte que la question de savoir si les avertissements de dépréciation entraînent ou non des erreurs peut être modifiée lors de l’exécution. Voir la documentation pour l’événement 'warning' et la méthode emitWarning() pour plus d’informations.

bash

$ node --throw-deprecation -p "process.throwDeprecation"
true
$ node -p "process.throwDeprecation"
undefined
$ node
> process.emitWarning('test', 'DeprecationWarning');
undefined
> (node:26598) DeprecationWarning: test
> process.throwDeprecation = true;
true
> process.emitWarning('test', 'DeprecationWarning');
Thrown:
[DeprecationWarning: test] { name: 'DeprecationWarning' }

`process.title`

Ajouté dans : v0.1.104

<string>

La propriété process.title renvoie le titre actuel du processus (c.-à-d. renvoie la valeur actuelle de ps). L’attribution d’une nouvelle valeur à process.title modifie la valeur actuelle de ps.

Lorsqu’une nouvelle valeur est affectée, différentes plateformes imposent différentes restrictions de longueur maximale au titre. Généralement, ces restrictions sont assez limitées. Par exemple, sous Linux et macOS, process.title est limité à la taille du nom binaire plus la longueur des arguments de ligne de commande, car la définition de process.title écrase la mémoire argv du processus. Node.js v0.8 autorisait des chaînes de titre de processus plus longues en écrasant également la mémoire environ, mais cela était potentiellement non sécurisé et déroutant dans certains cas (plutôt obscurs).

L’attribution d’une valeur à process.title peut ne pas entraîner un libellé précis dans les applications de gestion de processus telles que le Moniteur d’activité macOS ou le Gestionnaire de services Windows.

`process.traceDeprecation`

Ajouté dans : v0.8.0

<boolean>

La propriété process.traceDeprecation indique si l'indicateur --trace-deprecation est défini sur le processus Node.js actuel. Consultez la documentation de l'événement 'warning' et de la méthode emitWarning() pour plus d'informations sur le comportement de cet indicateur.

`process.umask()`

[Historique]

Version	Modifications
v14.0.0, v12.19.0	L'appel à `process.umask()` sans arguments est déprécié.
v0.1.19	Ajouté dans : v0.1.19

[Stable : 0 - Déprécié]

Stable : 0 Stabilité : 0 - Déprécié. L’appel à process.umask() sans argument provoque l’écriture du masque umask à l’échelle du processus deux fois. Cela introduit une situation de concurrence entre les threads et constitue une vulnérabilité potentielle en matière de sécurité. Il n’existe pas d’API alternative sûre et multiplateforme.

process.umask() renvoie le masque de création du mode de fichier du processus Node.js. Les processus enfants héritent du masque du processus parent.

`process.umask(mask)`

Ajouté dans : v0.1.19

mask <string> | <integer>

process.umask(mask) définit le masque de création du mode de fichier du processus Node.js. Les processus enfants héritent du masque du processus parent. Renvoie le masque précédent.

ESMCJS

import { umask } from 'node:process'

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Umask modifié de ${oldmask.toString(8)} à ${newmask.toString(8)}`)

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

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Umask modifié de ${oldmask.toString(8)} à ${newmask.toString(8)}`)

Dans les threads Worker, process.umask(mask) lève une exception.

`process.uptime()`

Ajouté dans : v0.5.0

Retourne : <nombre>

La méthode process.uptime() retourne le nombre de secondes pendant lesquelles le processus Node.js actuel est en cours d’exécution.

La valeur de retour inclut des fractions de seconde. Utilisez Math.floor() pour obtenir des secondes entières.

`process.version`

Ajouté dans : v0.1.3

<chaîne de caractères>

La propriété process.version contient la chaîne de version de Node.js.

ESMCJS

import { version } from 'node:process'

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

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

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

Pour obtenir la chaîne de version sans le v ajouté en préfixe, utilisez process.versions.node.

`process.versions`

[Historique]

Version	Changements
v9.0.0	La propriété `v8` inclut désormais un suffixe spécifique à Node.js.
v4.2.0	La propriété `icu` est désormais prise en charge.
v0.2.0	Ajouté dans : v0.2.0

<Objet>

La propriété process.versions retourne un objet répertoriant les chaînes de version de Node.js et de ses dépendances. process.versions.modules indique la version ABI actuelle, qui est incrémentée à chaque changement d’une API C++. Node.js refusera de charger les modules compilés avec une version ABI de module différente.

ESMCJS

import { versions } from 'node:process'

console.log(versions)

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

console.log(versions)

Générera un objet similaire à :

bash

{ node: '23.0.0',
  acorn: '8.11.3',
  ada: '2.7.8',
  ares: '1.28.1',
  base64: '0.5.2',
  brotli: '1.1.0',
  cjs_module_lexer: '1.2.2',
  cldr: '45.0',
  icu: '75.1',
  llhttp: '9.2.1',
  modules: '127',
  napi: '9',
  nghttp2: '1.61.0',
  nghttp3: '0.7.0',
  ngtcp2: '1.3.0',
  openssl: '3.0.13+quic',
  simdjson: '3.8.0',
  simdutf: '5.2.4',
  sqlite: '3.46.0',
  tz: '2024a',
  undici: '6.13.0',
  unicode: '15.1',
  uv: '1.48.0',
  uvwasi: '0.0.20',
  v8: '12.4.254.14-node.11',
  zlib: '1.3.0.1-motley-7d77fb7' }

Codes de sortie

Node.js se terminera normalement avec un code d'état 0 lorsqu'il n'y a plus d'opérations asynchrones en attente. Les codes d'état suivants sont utilisés dans d'autres cas :

1 Exception Fatale Non Gérée : Il y a eu une exception non gérée, et elle n'a pas été traitée par un domaine ou un gestionnaire d'événement 'uncaughtException'.
2 : Inutilisé (réservé par Bash pour une mauvaise utilisation intégrée)
3 Erreur d'Analyse Interne de JavaScript : Le code source JavaScript interne au processus d'amorçage de Node.js a provoqué une erreur d'analyse. C'est extrêmement rare, et cela ne peut généralement se produire que pendant le développement de Node.js lui-même.
4 Échec d'Évaluation Interne de JavaScript : Le code source JavaScript interne au processus d'amorçage de Node.js n'a pas réussi à renvoyer une valeur de fonction lors de l'évaluation. C'est extrêmement rare, et cela ne peut généralement se produire que pendant le développement de Node.js lui-même.
5 Erreur Fatale : Il y a eu une erreur fatale irrécupérable dans V8. En général, un message sera imprimé sur stderr avec le préfixe FATAL ERROR.
6 Gestionnaire d'Exception Interne Non-Fonction : Il y a eu une exception non gérée, mais la fonction interne de gestion des exceptions fatales a été définie d'une manière ou d'une autre sur une non-fonction, et n'a pas pu être appelée.
7 Échec d'Exécution du Gestionnaire d'Exception Interne : Il y a eu une exception non gérée, et la fonction interne de gestion des exceptions fatales a elle-même déclenché une erreur lors de sa tentative de gestion. Cela peut arriver, par exemple, si un gestionnaire 'uncaughtException' ou domain.on('error') déclenche une erreur.
8 : Inutilisé. Dans les versions précédentes de Node.js, le code de sortie 8 indiquait parfois une exception non gérée.
9 Argument Invalide : Soit une option inconnue a été spécifiée, soit une option nécessitant une valeur a été fournie sans valeur.
10 Échec d'Exécution Interne de JavaScript : Le code source JavaScript interne au processus d'amorçage de Node.js a déclenché une erreur lorsque la fonction d'amorçage a été appelée. C'est extrêmement rare, et cela ne peut généralement se produire que pendant le développement de Node.js lui-même.
12 Argument de Débogage Invalide : Les options --inspect et/ou --inspect-brk ont été définies, mais le numéro de port choisi était invalide ou indisponible.
13 Await de Niveau Supérieur Non Résolu : await a été utilisé en dehors d'une fonction dans le code de niveau supérieur, mais la Promise passée n'a jamais été résolue.
14 Échec de l'Instantané : Node.js a été démarré pour construire un instantané de démarrage V8 et cela a échoué parce que certaines exigences de l'état de l'application n'étaient pas remplies.
\>128 Sorties de Signal : Si Node.js reçoit un signal fatal tel que SIGKILL ou SIGHUP, alors son code de sortie sera 128 plus la valeur du code du signal. C'est une pratique POSIX standard, car les codes de sortie sont définis comme des entiers sur 7 bits, et les sorties de signal définissent le bit de poids fort, puis contiennent la valeur du code du signal. Par exemple, le signal SIGABRT a la valeur 6, donc le code de sortie attendu sera 128 + 6, ou 134.

Processus ​

Événements de processus ​

Événement : 'beforeExit' ​

Événement : 'disconnect' ​

Événement : 'exit' ​

Événement : 'message' ​

Événement : 'multipleResolves' ​

Événement : 'rejectionHandled' ​

Événement : 'workerMessage' ​

Événement : 'uncaughtException' ​

Avertissement : Utilisation correcte de 'uncaughtException' ​

Événement : 'uncaughtExceptionMonitor' ​

Événement : 'unhandledRejection' ​

Événement : 'warning' ​

Émettre des avertissements personnalisés ​

Noms d'avertissements Node.js ​

Événement : 'worker' ​

Événements de signaux ​

process.abort() ​

process.allowedNodeEnvironmentFlags ​

process.arch ​

process.argv ​

process.argv0 ​

process.channel ​

process.channel.ref() ​

process.channel.unref() ​

process.chdir(répertoire) ​

process.config ​

process.connected ​

process.constrainedMemory() ​

process.availableMemory() ​

process.cpuUsage([previousValue]) ​

process.cwd() ​

process.debugPort ​

process.disconnect() ​

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

process.emitWarning(warning[, options]) ​

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

Éviter les avertissements en double ​

process.env ​

process.execArgv ​

process.execPath ​

process.exit([code]) ​

process.exitCode ​

process.features.cached_builtins ​

process.features.debug ​

process.features.inspector ​

process.features.ipv6 ​

process.features.require_module ​

process.features.tls ​

process.features.tls_alpn ​

process.features.tls_ocsp ​

process.features.tls_sni ​

process.features.typescript ​

process.features.uv ​

process.finalization.register(ref, callback) ​

process.finalization.registerBeforeExit(ref, callback) ​

process.finalization.unregister(ref) ​

process.getActiveResourcesInfo() ​

process.getBuiltinModule(id) ​

process.getegid() ​

process.geteuid() ​

process.getgid() ​

process.getgroups() ​

process.getuid() ​

process.hasUncaughtExceptionCaptureCallback() ​

process.hrtime([time]) ​

process.hrtime.bigint() ​

process.initgroups(user, extraGroup) ​

process.kill(pid[, signal]) ​

process.loadEnvFile(path) ​

process.mainModule ​

process.memoryUsage() ​

process.memoryUsage.rss() ​

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

Quand utiliser queueMicrotask() vs. process.nextTick() ​

process.noDeprecation ​

process.permission ​

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

process.pid ​

Processus

Événements de processus

Événement : `'beforeExit'`

Événement : `'disconnect'`

Événement : `'exit'`

Événement : `'message'`

Événement : `'multipleResolves'`

Événement : `'rejectionHandled'`

Événement : `'workerMessage'`

Événement : `'uncaughtException'`

Avertissement : Utilisation correcte de `'uncaughtException'`

Événement : `'uncaughtExceptionMonitor'`

Événement : `'unhandledRejection'`

Événement : `'warning'`

Émettre des avertissements personnalisés

Noms d'avertissements Node.js

Événement : `'worker'`

Événements de signaux

`process.abort()`

`process.allowedNodeEnvironmentFlags`

`process.arch`

`process.argv`

`process.argv0`

`process.channel`

`process.channel.ref()`

`process.channel.unref()`

`process.chdir(répertoire)`

`process.config`

`process.connected`

`process.constrainedMemory()`

`process.availableMemory()`

`process.cpuUsage([previousValue])`

`process.cwd()`

`process.debugPort`

`process.disconnect()`

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

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

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

Éviter les avertissements en double

`process.env`

`process.execArgv`

`process.execPath`

`process.exit([code])`

`process.exitCode`

`process.features.cached_builtins`

`process.features.debug`

`process.features.inspector`

`process.features.ipv6`

`process.features.require_module`

`process.features.tls`

`process.features.tls_alpn`

`process.features.tls_ocsp`

`process.features.tls_sni`

`process.features.typescript`

`process.features.uv`

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

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

`process.finalization.unregister(ref)`

`process.getActiveResourcesInfo()`

`process.getBuiltinModule(id)`

`process.getegid()`

`process.geteuid()`

`process.getgid()`

`process.getgroups()`

`process.getuid()`

`process.hasUncaughtExceptionCaptureCallback()`

`process.hrtime([time])`

`process.hrtime.bigint()`

`process.initgroups(user, extraGroup)`

`process.kill(pid[, signal])`

`process.loadEnvFile(path)`

`process.mainModule`

`process.memoryUsage()`

`process.memoryUsage.rss()`

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

Quand utiliser `queueMicrotask()` vs. `process.nextTick()`

`process.noDeprecation`

`process.permission`

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

`process.pid`