API en ligne de commande

Node.js est fourni avec une variété d'options CLI. Ces options exposent le débogage intégré, plusieurs manières d'exécuter des scripts et d'autres options d'exécution utiles.

Pour afficher cette documentation comme une page de manuel dans un terminal, exécutez man node.

Synopsis

node [options] [options V8] [\<point d'entrée du programme\> | -e "script" | -] [--] [arguments]

node inspect [\<point d'entrée du programme\> | -e "script" | \<hôte\>:\<port\>] …

node --v8-options

Exécutez sans arguments pour démarrer le REPL.

Pour plus d'informations sur node inspect, consultez la documentation du débogueur.

Point d'entrée du programme

Le point d'entrée du programme est une chaîne de caractères de type spécificateur. Si la chaîne n'est pas un chemin absolu, elle est résolue comme un chemin relatif à partir du répertoire de travail actuel. Ce chemin est ensuite résolu par le chargeur de modules CommonJS. Si aucun fichier correspondant n'est trouvé, une erreur est levée.

Si un fichier est trouvé, son chemin sera passé au chargeur de modules ES sous l'une des conditions suivantes :

• Le programme a été démarré avec un indicateur de ligne de commande qui force le point d'entrée à être chargé avec le chargeur de modules ECMAScript, tel que --import.
• Le fichier a une extension .mjs.
• Le fichier n'a pas d'extension .cjs, et le fichier package.json parent le plus proche contient un champ de premier niveau "type" avec la valeur "module".

Sinon, le fichier est chargé à l'aide du chargeur de modules CommonJS. Voir Chargeurs de modules pour plus de détails.

Avertissement sur le point d'entrée du chargeur de modules ECMAScript

Lors du chargement, le chargeur de modules ES charge le point d'entrée du programme, la commande node n'acceptera comme entrée que les fichiers avec les extensions .js, .mjs ou .cjs ; et avec les extensions .wasm lorsque [--experimental-wasm-modules`](/fr/api/cli#--experimental-wasm-modules) est activé.

Options

[Historique]

Version	Modifications
v10.12.0	Les traits de soulignement au lieu des tirets sont désormais autorisés pour les options Node.js ainsi que pour les options V8.

Toutes les options, y compris les options V8, permettent aux mots d'être séparés par des tirets (-) ou des traits de soulignement (_). Par exemple, --pending-deprecation est équivalent à --pending_deprecation.

Si une option qui prend une seule valeur (telle que --max-http-header-size) est passée plus d'une fois, la dernière valeur passée est utilisée. Les options de la ligne de commande ont priorité sur les options transmises via la variable d'environnement NODE_OPTIONS.

-

Ajouté dans : v8.0.0

Alias pour stdin. Analogue à l’utilisation de - dans d’autres utilitaires en ligne de commande, signifiant que le script est lu depuis stdin, et que le reste des options est passé à ce script.

--

Ajouté dans : v6.11.0

Indique la fin des options de nœud. Passe le reste des arguments au script. Si aucun nom de fichier de script ou script eval/print n’est fourni avant cela, alors l’argument suivant est utilisé comme nom de fichier de script.

--abort-on-uncaught-exception

Ajouté dans : v0.10.8

L’interruption au lieu de la sortie provoque la génération d’un fichier core pour l’analyse post-mortem à l’aide d’un débogueur (tel que lldb, gdb et mdb).

Si cet indicateur est passé, le comportement peut toujours être défini pour ne pas interrompre via process.setUncaughtExceptionCaptureCallback() (et via l’utilisation du module node:domain qui l’utilise).

--allow-addons

Ajouté dans : v21.6.0, v20.12.0

[Stable : 1 - Expérimental]

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

Lors de l’utilisation du Modèle d’autorisation, le processus ne pourra pas utiliser les modules natifs par défaut. Les tentatives de le faire déclencheront une erreur ERR_DLOPEN_DISABLED à moins que l’utilisateur ne passe explicitement l’indicateur --allow-addons au démarrage de Node.js.

Exemple :

// Tentative de require d'un module natif
require('nodejs-addon-example')

$ node --permission --allow-fs-read=* index.js
node:internal/modules/cjs/loader:1319
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: Cannot load native addon because loading addons is disabled.
    at Module._extensions..node (node:internal/modules/cjs/loader:1319:18)
    at Module.load (node:internal/modules/cjs/loader:1091:32)
    at Module._load (node:internal/modules/cjs/loader:938:12)
    at Module.require (node:internal/modules/cjs/loader:1115:19)
    at require (node:internal/modules/helpers:130:18)
    at Object.<anonymous> (/home/index.js:1:15)
    at Module._compile (node:internal/modules/cjs/loader:1233:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1287:10)
    at Module.load (node:internal/modules/cjs/loader:1091:32)
    at Module._load (node:internal/modules/cjs/loader:938:12) {
  code: 'ERR_DLOPEN_DISABLED'
}

--allow-child-process

Ajouté dans : v20.0.0

[Stable : 1 - Expérimental]

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

Lors de l'utilisation du modèle d'autorisation, le processus ne pourra pas générer de processus enfant par défaut. Toute tentative entraînera une erreur ERR_ACCESS_DENIED à moins que l'utilisateur ne passe explicitement l'indicateur --allow-child-process au démarrage de Node.js.

Exemple :

const childProcess = require('node:child_process')
// Tentative de contournement de l'autorisation
childProcess.spawn('node', ['-e', 'require("fs").writeFileSync("/new-file", "example")'])

$ node --permission --allow-fs-read=* index.js
node:internal/child_process:388
  const err = this._handle.spawn(options);
                           ^
Error: Access to this API has been restricted
    at ChildProcess.spawn (node:internal/child_process:388:28)
    at Object.spawn (node:child_process:723:9)
    at Object.<anonymous> (/home/index.js:3:14)
    at Module._compile (node:internal/modules/cjs/loader:1120:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1174:10)
    at Module.load (node:internal/modules/cjs/loader:998:32)
    at Module._load (node:internal/modules/cjs/loader:839:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'ChildProcess'
}

--allow-fs-read

[Historique]

Version	Modifications
v23.5.0	Le modèle d'autorisation et les indicateurs --allow-fs sont stables.
v20.7.0	Les chemins délimités par une virgule (,) ne sont plus autorisés.
v20.0.0	Ajouté dans : v20.0.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable.

Cet indicateur configure les autorisations de lecture du système de fichiers à l'aide du modèle d'autorisation.

Les arguments valides pour l'indicateur --allow-fs-read sont :

• * - Pour autoriser toutes les opérations FileSystemRead.
• Plusieurs chemins peuvent être autorisés en utilisant plusieurs indicateurs --allow-fs-read. Exemple : --allow-fs-read=/folder1/ --allow-fs-read=/folder1/

Des exemples se trouvent dans la documentation des autorisations du système de fichiers.

Le module initialisateur doit également être autorisé. Considérez l'exemple suivant :

$ node --permission index.js

Error: Access to this API has been restricted
    at node:internal/main/run_main_module:23:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'FileSystemRead',
  resource: '/Users/rafaelgss/repos/os/node/index.js'
}

Le processus doit avoir accès au module index.js :

node --permission --allow-fs-read=/path/to/index.js index.js

--allow-fs-write

[Historique]

Version	Modifications
v23.5.0	Le modèle d'autorisation et les indicateurs --allow-fs sont stables.
v20.7.0	Les chemins délimités par une virgule (,) ne sont plus autorisés.
v20.0.0	Ajouté dans : v20.0.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable.

Cet indicateur configure les autorisations d'écriture du système de fichiers à l'aide du modèle d'autorisation.

Les arguments valides pour l'indicateur --allow-fs-write sont :

• * - Pour autoriser toutes les opérations FileSystemWrite.
• Plusieurs chemins peuvent être autorisés à l'aide de plusieurs indicateurs --allow-fs-write. Exemple : --allow-fs-write=/folder1/ --allow-fs-write=/folder1/

Les chemins délimités par une virgule (,) ne sont plus autorisés. Lorsqu'un seul indicateur avec une virgule est passé, un avertissement s'affiche.

Des exemples sont disponibles dans la documentation Autorisations du système de fichiers.

--allow-wasi

Ajouté dans : v22.3.0, v20.16.0

[Stable : 1 - Expérimental]

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

Lors de l'utilisation du modèle d'autorisation, le processus ne sera pas en mesure de créer d'instances WASI par défaut. Pour des raisons de sécurité, l'appel lèvera une exception ERR_ACCESS_DENIED à moins que l'utilisateur ne passe explicitement l'indicateur --allow-wasi dans le processus principal Node.js.

Exemple :

const { WASI } = require('node:wasi')
// Tentative de contournement de l'autorisation
new WASI({
  version: 'preview1',
  // Tentative de montage de l'intégralité du système de fichiers
  preopens: {
    '/': '/',
  },
})

$ node --permission --allow-fs-read=* index.js

Error: Access to this API has been restricted
    at node:internal/main/run_main_module:30:49 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'WASI',
}

--allow-worker

Ajouté dans : v20.0.0

[Stable : 1 - Expérimental]

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

Lors de l'utilisation du modèle d'autorisation, le processus ne pourra pas créer de threads worker par défaut. Pour des raisons de sécurité, l'appel lèvera une exception ERR_ACCESS_DENIED à moins que l'utilisateur ne passe explicitement l'indicateur --allow-worker dans le processus principal Node.js.

Exemple :

const { Worker } = require('node:worker_threads')
// Tentative de contournement de l'autorisation
new Worker(__filename)

$ node --permission --allow-fs-read=* index.js

Error: Access to this API has been restricted
    at node:internal/main/run_main_module:17:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'WorkerThreads'
}

--build-snapshot

Ajouté dans : v18.8.0

[Stable : 1 - Expérimental]

Stable : 1 Stability : 1 - Expérimental

Génère un blob de snapshot à la fin du processus et l'écrit sur le disque. Il peut être chargé ultérieurement avec --snapshot-blob.

Lors de la création du snapshot, si --snapshot-blob n'est pas spécifié, le blob généré sera écrit, par défaut, dans snapshot.blob dans le répertoire de travail actuel. Sinon, il sera écrit au chemin spécifié par --snapshot-blob.

$ echo "globalThis.foo = 'I am from the snapshot'" > snapshot.js

# Exécuter snapshot.js pour initialiser l'application et prendre un snapshot de {#run-snapshotjs-to-initialize-the-application-and-snapshot-the}
# son état dans snapshot.blob.
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js

$ echo "console.log(globalThis.foo)" > index.js

# Charger le snapshot généré et démarrer l'application depuis index.js. {#state-of-it-into-snapshotblob}
$ node --snapshot-blob snapshot.blob index.js
I am from the snapshot

L'API v8.startupSnapshot peut être utilisée pour spécifier un point d'entrée lors de la création du snapshot, évitant ainsi la nécessité d'un script d'entrée supplémentaire lors de la désérialisation :

$ echo "require('v8').startupSnapshot.setDeserializeMainFunction(() => console.log('I am from the snapshot'))" > snapshot.js
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js
$ node --snapshot-blob snapshot.blob
I am from the snapshot

Pour plus d'informations, consultez la documentation de l'API v8.startupSnapshot.

Actuellement, la prise en charge du snapshot d'exécution est expérimentale car :

--build-snapshot-config

Ajouté dans : v21.6.0, v20.12.0

[Stable : 1 - Expérimental]

Stable : 1 Stability : 1 - Expérimental

Spécifie le chemin d'accès à un fichier de configuration JSON qui configure le comportement de création du snapshot.

Les options suivantes sont actuellement prises en charge :

• builder <string> Obligatoire. Fournit le nom du script qui est exécuté avant la création du snapshot, comme si --build-snapshot avait été passé avec builder comme nom du script principal.
• withoutCodeCache <boolean> Facultatif. L'inclusion du cache de code réduit le temps passé à compiler les fonctions incluses dans le snapshot au prix d'une taille de snapshot plus importante et potentiellement de la rupture de la portabilité du snapshot.

Lors de l'utilisation de ce drapeau, les fichiers de script supplémentaires fournis sur la ligne de commande ne seront pas exécutés et seront interprétés comme des arguments de ligne de commande réguliers.

-c, --check

[Historique]

Version	Modifications
v10.0.0	L'option --require est désormais prise en charge lors de la vérification d'un fichier.
v5.0.0, v4.2.0	Ajouté dans : v5.0.0, v4.2.0

Vérification syntaxique du script sans exécution.

--completion-bash

Ajouté dans : v10.12.0

Affiche le script de complétion bash utilisable pour Node.js.

node --completion-bash > node_bash_completion
source node_bash_completion

-C condition, --conditions=condition

[Historique]

Version	Modifications
v22.9.0, v20.18.0	L'indicateur n'est plus expérimental.
v14.9.0, v12.19.0	Ajouté dans : v14.9.0, v12.19.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Fournit des conditions de résolution d'exportations conditionnelles personnalisées exportations conditionnelles.

N'importe quel nombre de noms de conditions de chaîne personnalisés sont autorisés.

Les conditions Node.js par défaut de "node", "default", "import" et "require" s'appliqueront toujours comme défini.

Par exemple, pour exécuter un module avec des résolutions "développement" :

node -C development app.js

--cpu-prof

[Historique]

Version	Modifications
v22.4.0, v20.16.0	Les indicateurs --cpu-prof sont désormais stables.
v12.0.0	Ajouté dans : v12.0.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Démarre le profileur CPU V8 au démarrage et écrit le profil CPU sur le disque avant la sortie.

Si --cpu-prof-dir n'est pas spécifié, le profil généré est placé dans le répertoire de travail actuel.

Si --cpu-prof-name n'est pas spécifié, le profil généré est nommé CPU.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.cpuprofile.

$ node --cpu-prof index.js
$ ls *.cpuprofile
CPU.20190409.202950.15293.0.0.cpuprofile

--cpu-prof-dir

[Historique]

Version	Modifications
v22.4.0, v20.16.0	Les indicateurs --cpu-prof sont désormais stables.
v12.0.0	Ajouté dans : v12.0.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Spécifie le répertoire où les profils CPU générés par --cpu-prof seront placés.

La valeur par défaut est contrôlée par l'option de ligne de commande --diagnostic-dir.

--cpu-prof-interval

[Historique]

Version	Modifications
v22.4.0, v20.16.0	Les indicateurs --cpu-prof sont maintenant stables.
v12.2.0	Ajouté dans : v12.2.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Spécifie l'intervalle d'échantillonnage en microsecondes pour les profils CPU générés par --cpu-prof. La valeur par défaut est de 1000 microsecondes.

--cpu-prof-name

[Historique]

Version	Modifications
v22.4.0, v20.16.0	Les indicateurs --cpu-prof sont maintenant stables.
v12.0.0	Ajouté dans : v12.0.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Spécifie le nom du fichier du profil CPU généré par --cpu-prof.

--diagnostic-dir=directory

Définit le répertoire dans lequel tous les fichiers de sortie de diagnostic sont écrits. Par défaut, le répertoire de travail actuel.

Affecte le répertoire de sortie par défaut de :

• --cpu-prof-dir
• --heap-prof-dir
• --redirect-warnings

--disable-proto=mode

Ajouté dans : v13.12.0, v12.17.0

Désactive la propriété Object.prototype.__proto__. Si mode est delete, la propriété est entièrement supprimée. Si mode est throw, les accès à la propriété lèvent une exception avec le code ERR_PROTO_ACCESS.

--disable-warning=code-or-type

[Stable : 1 - Expérimental]

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

Ajouté dans : v21.3.0, v20.11.0

Désactive les avertissements de processus spécifiques par code ou type.

Les avertissements émis par process.emitWarning() peuvent contenir un code et un type. Cette option n'émettra pas d'avertissements ayant un code ou un type correspondant.

Liste des avertissements d'obsolescence.

Les types d'avertissement principaux de Node.js sont : DeprecationWarning et ExperimentalWarning

Par exemple, le script suivant n'émettra pas DEP0025 require('node:sys') lorsqu'il est exécuté avec node --disable-warning=DEP0025 :

ESM

import sys from 'node:sys'

CJS

const sys = require('node:sys')

Par exemple, le script suivant émettra DEP0025 require('node:sys'), mais pas les avertissements expérimentaux (tels que ExperimentalWarning : vm.measureMemory est une fonctionnalité expérimentale dans <=v21) lorsqu'il est exécuté avec node --disable-warning=ExperimentalWarning :

ESM

import sys from 'node:sys'
import vm from 'node:vm'

vm.measureMemory()

CJS

const sys = require('node:sys')
const vm = require('node:vm')

vm.measureMemory()

--disable-wasm-trap-handler

Ajouté dans : v22.2.0, v20.15.0

Par défaut, Node.js active les vérifications de limites WebAssembly basées sur le gestionnaire de pièges. Par conséquent, V8 n'a pas besoin d'insérer des vérifications de limites en ligne dans le code compilé à partir de WebAssembly, ce qui peut accélérer considérablement l'exécution de WebAssembly, mais cette optimisation nécessite l'allocation d'une grande cage de mémoire virtuelle (actuellement 10 Go). Si le processus Node.js n'a pas accès à un espace d'adressage de mémoire virtuelle suffisamment grand en raison de configurations système ou de limitations matérielles, les utilisateurs ne pourront pas exécuter de WebAssembly impliquant une allocation dans cette cage de mémoire virtuelle et verront une erreur de mémoire insuffisante.

$ ulimit -v 5000000
$ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });"
[eval]:1
new WebAssembly.Memory({ initial: 10, maximum: 100 });
^

RangeError: WebAssembly.Memory(): impossible d'allouer la mémoire
    at [eval]:1:1
    at runScriptInThisContext (node:internal/vm:209:10)
    at node:internal/process/execution:118:14
    at [eval]-wrapper:6:24
    at runScript (node:internal/process/execution:101:62)
    at evalScript (node:internal/process/execution:136:3)
    at node:internal/main/eval_string:49:3

--disable-wasm-trap-handler désactive cette optimisation afin que les utilisateurs puissent au moins exécuter WebAssembly (avec des performances moins optimales) lorsque l'espace d'adressage de mémoire virtuelle disponible pour leur processus Node.js est inférieur à celui dont a besoin la cage de mémoire WebAssembly de V8.

--disallow-code-generation-from-strings

Ajouté dans : v9.8.0

Faire en sorte que les fonctionnalités linguistiques intégrées telles que eval et new Function qui génèrent du code à partir de chaînes lèvent une exception. Cela n'affecte pas le module node:vm de Node.js.

--dns-result-order=order

[Historique]

Version	Modifications
v22.1.0, v20.13.0	ipv6first est désormais pris en charge.
v17.0.0	Valeur par défaut modifiée en verbatim.
v16.4.0, v14.18.0	Ajouté dans : v16.4.0, v14.18.0

Définit la valeur par défaut de order dans dns.lookup() et dnsPromises.lookup(). La valeur peut être :

• ipv4first : définit la valeur par défaut de order sur ipv4first.
• ipv6first : définit la valeur par défaut de order sur ipv6first.
• verbatim : définit la valeur par défaut de order sur verbatim.

La valeur par défaut est verbatim et dns.setDefaultResultOrder() a une priorité plus élevée que --dns-result-order.

--enable-fips

Ajouté dans : v6.0.0

Active le chiffrement conforme à FIPS au démarrage. (Nécessite que Node.js soit compilé avec OpenSSL compatible FIPS.)

--enable-network-family-autoselection

Ajouté dans : v18.18.0

Active l'algorithme de sélection automatique de la famille, sauf si les options de connexion le désactivent explicitement.

--enable-source-maps

[Historique]

Version	Modifications
v15.11.0, v14.18.0	Cette API n'est plus expérimentale.
v12.12.0	Ajouté dans : v12.12.0

Active la prise en charge des Source Map v3 pour les traces de pile.

Lors de l'utilisation d'un transpileur, tel que TypeScript, les traces de pile levées par une application font référence au code transpilé, et non à la position source d'origine. --enable-source-maps active la mise en cache des Source Maps et fait de son mieux pour signaler les traces de pile par rapport au fichier source d'origine.

Le remplacement de Error.prepareStackTrace peut empêcher --enable-source-maps de modifier la trace de pile. Appelez et renvoyez les résultats de la fonction Error.prepareStackTrace d'origine dans la fonction de remplacement pour modifier la trace de pile avec les source maps.

const originalPrepareStackTrace = Error.prepareStackTrace
Error.prepareStackTrace = (error, trace) => {
  // Modifier l'erreur et la trace et formater la trace de pile avec
  // Error.prepareStackTrace d'origine.
  return originalPrepareStackTrace(error, trace)
}

Notez que l'activation des source maps peut introduire une latence dans votre application lorsque Error.stack est accédé. Si vous accédez fréquemment à Error.stack dans votre application, tenez compte des implications sur les performances de --enable-source-maps.

--entry-url

Ajouté dans : v23.0.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Lorsqu'il est présent, Node.js interprétera le point d'entrée comme une URL, plutôt qu'un chemin.

Suit les règles de résolution des modules ECMAScript.

Tout paramètre de requête ou hachage dans l'URL sera accessible via import.meta.url.

node --entry-url 'file:///path/to/file.js?queryparams=work#and-hashes-too'
node --entry-url --experimental-strip-types 'file.ts?query#hash'
node --entry-url 'data:text/javascript,console.log("Hello")'

--env-file-if-exists=config

Ajouté dans : v22.9.0

Le comportement est le même que celui de --env-file, mais aucune erreur n'est levée si le fichier n'existe pas.

--env-file=config

[Stable : 1 - Expérimental]

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

[Historique]

Version	Modifications
v21.7.0, v20.12.0	Ajout de la prise en charge des valeurs multilignes.
v20.6.0	Ajouté dans : v20.6.0

Charge les variables d'environnement à partir d'un fichier relatif au répertoire courant, les rendant disponibles pour les applications sur process.env. Les variables d'environnement qui configurent Node.js, telles que NODE_OPTIONS, sont analysées et appliquées. Si la même variable est définie dans l'environnement et dans le fichier, la valeur de l'environnement a priorité.

Vous pouvez passer plusieurs arguments --env-file. Les fichiers suivants remplacent les variables préexistantes définies dans les fichiers précédents.

Une erreur est levée si le fichier n'existe pas.

node --env-file=.env --env-file=.development.env index.js

Le format du fichier doit être une ligne par paire clé-valeur de nom et de valeur de variable d'environnement séparées par = :

PORT=3000

Tout texte après un # est traité comme un commentaire :

# Ceci est un commentaire {#--env-file=config}
PORT=3000 # Ceci est aussi un commentaire

Les valeurs peuvent commencer et se terminer par les guillemets suivants : ```, "ou'. Elles sont omises des valeurs.

USERNAME="nodejs" # donnera `nodejs` comme valeur.

Les valeurs multilignes sont prises en charge :

MULTI_LINE="CECI EST
UNE MULTILIGNE"
# donnera `CECI EST\nUNE MULTILIGNE` comme valeur. {#this-is-a-comment}

Le mot clé export avant une clé est ignoré :

export USERNAME="nodejs" # donnera `nodejs` comme valeur.

Si vous souhaitez charger des variables d'environnement à partir d'un fichier qui peut ne pas exister, vous pouvez utiliser l'indicateur --env-file-if-exists à la place.

-e, --eval "script" {#will-result-in-this-is\na-multiline-as-the-value}

[Historique]

Version	Modifications
v22.6.0	L'évaluation prend désormais en charge le retrait expérimental des types.
v5.11.0	Les bibliothèques intégrées sont désormais disponibles en tant que variables prédéfinies.
v0.5.2	Ajouté dans : v0.5.2

Évalue l'argument suivant en tant que JavaScript. Les modules prédéfinis dans l'environnement REPL peuvent également être utilisés dans script.

Sous Windows, l'utilisation de cmd.exe avec une simple quote ne fonctionnera pas correctement car il ne reconnaît que les doubles guillemets " pour les citations. Dans Powershell ou Git bash, les quotes simples ' et doubles " sont utilisables.

Il est possible d'exécuter du code contenant des types inline en passant --experimental-strip-types.

--experimental-async-context-frame

Ajouté dans : v22.7.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Active l'utilisation de AsyncLocalStorage basé sur AsyncContextFrame plutôt que l'implémentation par défaut qui repose sur async_hooks. Ce nouveau modèle est implémenté de manière très différente et pourrait donc présenter des différences dans la façon dont les données de contexte circulent au sein de l'application. En tant que tel, il est actuellement recommandé de vous assurer que le comportement de votre application n'est pas affecté par ce changement avant de l'utiliser en production.

--experimental-eventsource

Ajouté dans : v22.3.0, v20.18.0

Active l'exposition de l'API Web EventSource sur la portée globale.

--experimental-import-meta-resolve

[Historique]

Version	Modifications
v20.6.0, v18.19.0	import.meta.resolve synchrone disponible par défaut, le drapeau étant conservé pour activer le deuxième argument expérimental comme précédemment supporté.
v13.9.0, v12.16.2	Ajouté dans : v13.9.0, v12.16.2

Active le support expérimental de l'URL parent import.meta.resolve(), qui permet de passer un deuxième argument parentURL pour une résolution contextuelle.

Auparavant, la fonctionnalité entière import.meta.resolve était contrôlée par ce drapeau.

--experimental-loader=module

[Historique]

Version	Modifications
v12.11.1	Cet indicateur a été renommé de --loader à --experimental-loader.
v8.8.0	Ajouté dans : v8.8.0

Spécifie le module contenant les hooks de personnalisation de module exportés. module peut être n'importe quelle chaîne acceptée comme spécificateur import.

--experimental-network-inspection

Ajouté dans : v22.6.0, v20.18.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Active la prise en charge expérimentale de l'inspection réseau avec Chrome DevTools.

--experimental-print-required-tla

Ajouté dans : v22.0.0, v20.17.0

Si le module ES qui est require() contient des await de niveau supérieur, cet indicateur permet à Node.js d'évaluer le module, d'essayer de localiser les await de niveau supérieur et d'afficher leur emplacement pour aider les utilisateurs à les trouver.

--experimental-require-module

[Historique]

Version	Modifications
v23.0.0	Ceci est maintenant vrai par défaut.
v22.0.0, v20.17.0	Ajouté dans : v22.0.0, v20.17.0

[Stable : 1 - Expérimental]

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

Prend en charge le chargement d'un graphe de module ES synchrone dans require().

Voir Chargement des modules ECMAScript à l'aide de require().

--experimental-sea-config

Ajouté dans : v20.0.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Utilisez cet indicateur pour générer un blob qui peut être injecté dans le binaire Node.js pour produire une application exécutable unique. Consultez la documentation concernant cette configuration pour plus de détails.

--experimental-shadow-realm

Ajouté dans : v19.0.0, v18.13.0

Utilisez cet indicateur pour activer la prise en charge de ShadowRealm.

--experimental-strip-types

Ajouté dans : v22.6.0

[Stable : 1 - Expérimental]

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

Active le retrait expérimental des types pour les fichiers TypeScript. Pour plus d’informations, consultez la documentation sur le retrait des types TypeScript.

--experimental-test-coverage

[Historique]

Version	Modifications
v20.1.0, v18.17.0	Cette option peut être utilisée avec --test.
v19.7.0, v18.15.0	Ajouté dans : v19.7.0, v18.15.0

Lorsqu’il est utilisé conjointement avec le module node:test, un rapport de couverture de code est généré dans le cadre de la sortie du lanceur de tests. Si aucun test n’est exécuté, aucun rapport de couverture n’est généré. Consultez la documentation sur la collecte de la couverture de code à partir des tests pour plus de détails.

--experimental-test-isolation=mode

Ajouté dans : v22.8.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1.0 - Développement précoce

Configure le type d’isolation des tests utilisé dans le lanceur de tests. Lorsque mode est 'process', chaque fichier de test est exécuté dans un processus enfant distinct. Lorsque mode est 'none', tous les fichiers de test sont exécutés dans le même processus que le lanceur de tests. Le mode d’isolation par défaut est 'process'. Cet indicateur est ignoré si l’indicateur --test n’est pas présent. Consultez la section modèle d’exécution du lanceur de tests pour plus d’informations.

--experimental-test-module-mocks

Ajouté dans : v22.3.0, v20.18.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1.0 - Développement précoce

Active la simulation de modules dans le lanceur de tests.

--experimental-transform-types

Ajouté dans : v22.7.0

[Stable : 1 - Expérimental]

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

Active la transformation de la syntaxe TypeScript uniquement en code JavaScript. Implique --experimental-strip-types et --enable-source-maps.

--experimental-vm-modules

Ajouté dans : v9.6.0

Active la prise en charge expérimentale des modules ES dans le module node:vm.

--experimental-wasi-unstable-preview1

[Historique]

Version	Modifications
v20.0.0, v18.17.0	Cette option n'est plus requise car WASI est activé par défaut, mais peut toujours être passée.
v13.6.0	Modifié de --experimental-wasi-unstable-preview0 à --experimental-wasi-unstable-preview1.
v13.3.0, v12.16.0	Ajouté dans : v13.3.0, v12.16.0

Active la prise en charge expérimentale de l'interface système WebAssembly (WASI).

--experimental-wasm-modules

Ajouté dans : v12.3.0

Active la prise en charge expérimentale des modules WebAssembly.

--experimental-webstorage

Ajouté dans : v22.4.0

Active la prise en charge expérimentale de Web Storage.

--expose-gc

Ajouté dans : v22.3.0, v20.18.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental. Cet indicateur est hérité de V8 et est sujet à modification en amont.

Cet indicateur exposera l'extension gc de V8.

if (globalThis.gc) {
  globalThis.gc()
}

--force-context-aware

Ajouté dans : v12.12.0

Désactive le chargement des modules natifs qui ne sont pas context-aware.

--force-fips

Ajouté dans : v6.0.0

Force le chiffrement conforme à FIPS au démarrage. (Ne peut pas être désactivé à partir du code script.) (Mêmes exigences que --enable-fips.)

--force-node-api-uncaught-exceptions-policy

Ajouté dans : v18.3.0, v16.17.0

Applique l'événement uncaughtException sur les rappels asynchrones Node-API.

Pour éviter qu'un module existant ne fasse planter le processus, cet indicateur n'est pas activé par défaut. À l'avenir, cet indicateur sera activé par défaut pour appliquer le comportement correct.

--frozen-intrinsics

Ajouté dans : v11.12.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Active les intrinsèques figés expérimentaux comme Array et Object.

Seul le contexte racine est pris en charge. Il n’y a aucune garantie que globalThis.Array soit effectivement la référence intrinsèque par défaut. Le code peut ne plus fonctionner avec ce drapeau.

Pour permettre l’ajout de polyfills, --require et --import s’exécutent tous les deux avant le gel des intrinsèques.

--heap-prof

[Historique]

Version	Modifications
v22.4.0, v20.16.0	Les drapeaux --heap-prof sont maintenant stables.
v12.4.0	Ajouté dans : v12.4.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Démarre le profileur de tas V8 au démarrage et écrit le profil de tas sur le disque avant la sortie.

Si --heap-prof-dir n’est pas spécifié, le profil généré est placé dans le répertoire de travail actuel.

Si --heap-prof-name n’est pas spécifié, le profil généré est nommé Heap.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.heapprofile.

$ node --heap-prof index.js
$ ls *.heapprofile
Heap.20190409.202950.15293.0.001.heapprofile

--heap-prof-dir

[Historique]

Version	Modifications
v22.4.0, v20.16.0	Les drapeaux --heap-prof sont maintenant stables.
v12.4.0	Ajouté dans : v12.4.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Spécifie le répertoire où les profils de tas générés par --heap-prof seront placés.

La valeur par défaut est contrôlée par l’option de ligne de commande --diagnostic-dir.

--heap-prof-interval

[Historique]

Version	Modifications
v22.4.0, v20.16.0	Les drapeaux --heap-prof sont maintenant stables.
v12.4.0	Ajouté dans : v12.4.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Spécifie l’intervalle d’échantillonnage moyen en octets pour les profils de tas générés par --heap-prof. La valeur par défaut est de 512 * 1024 octets.

--heap-prof-name

[Historique]

Version	Modifications
v22.4.0, v20.16.0	Les indicateurs --heap-prof sont désormais stables.
v12.4.0	Ajouté dans : v12.4.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Spécifie le nom du fichier du profil de tas généré par --heap-prof.

--heapsnapshot-near-heap-limit=max_count

Ajouté dans : v15.1.0, v14.18.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Écrit un instantané du tas V8 sur le disque lorsque l’utilisation du tas V8 approche de la limite du tas. count doit être un entier non négatif (auquel cas Node.js n’écrira pas plus de max_count instantanés sur le disque).

Lors de la génération d’instantanés, un ramassage des ordures peut être déclenché et réduire l’utilisation du tas. Par conséquent, plusieurs instantanés peuvent être écrits sur le disque avant que l’instance Node.js ne soit finalement à court de mémoire. Ces instantanés du tas peuvent être comparés pour déterminer quels objets sont alloués pendant le temps où des instantanés consécutifs sont pris. Il n’est pas garanti que Node.js écrira exactement max_count instantanés sur le disque, mais il fera de son mieux pour générer au moins un et jusqu’à max_count instantanés avant que l’instance Node.js ne soit à court de mémoire lorsque max_count est supérieur à 0.

La génération d’instantanés V8 prend du temps et de la mémoire (à la fois la mémoire gérée par le tas V8 et la mémoire native en dehors du tas V8). Plus le tas est grand, plus il a besoin de ressources. Node.js ajustera le tas V8 pour tenir compte du surcroît de mémoire du tas V8, et fera de son mieux pour éviter d’utiliser toute la mémoire disponible pour le processus. Lorsque le processus utilise plus de mémoire que ce que le système juge approprié, le processus peut être terminé brutalement par le système, selon la configuration du système.

$ node --max-old-space-size=100 --heapsnapshot-near-heap-limit=3 index.js
Instantané écrit dans Heap.20200430.100036.49580.0.001.heapsnapshot
Instantané écrit dans Heap.20200430.100037.49580.0.002.heapsnapshot
Instantané écrit dans Heap.20200430.100038.49580.0.003.heapsnapshot

<--- Derniers GCs --->

[49580:0x110000000]     4826 ms: Mark-sweep 130.6 (147.8) -> 130.5 (147.8) Mo, 27.4 / 0.0 ms  (mu moyenne = 0.126, mu actuelle = 0.034) échec d’allocation, le ramassage des ordures risque de ne pas réussir
[49580:0x110000000]     4845 ms: Mark-sweep 130.6 (147.8) -> 130.6 (147.8) Mo, 18.8 / 0.0 ms  (mu moyenne = 0.088, mu actuelle = 0.031) échec d’allocation, le ramassage des ordures risque de ne pas réussir


<--- Trace de pile JS --->

ERREUR FATALE : compactages inefficaces proches de la limite du tas Échec d’allocation - Tas JavaScript hors mémoire
....

--heapsnapshot-signal=signal

Ajouté dans : v12.0.0

Active un gestionnaire de signal qui provoque l'écriture d'un vidage de tas par le processus Node.js lorsque le signal spécifié est reçu. signal doit être un nom de signal valide. Désactivé par défaut.

$ node --heapsnapshot-signal=SIGUSR2 index.js &
$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
node         1  5.5  6.1 787252 247004 ?       Ssl  16:43   0:02 node --heapsnapshot-signal=SIGUSR2 index.js
$ kill -USR2 1
$ ls
Heap.20190718.133405.15554.0.001.heapsnapshot

-h, --help

Ajouté dans : v0.1.3

Afficher les options de ligne de commande de node. La sortie de cette option est moins détaillée que ce document.

--icu-data-dir=file

Ajouté dans : v0.11.15

Spécifier le chemin de chargement des données ICU. (Remplace NODE_ICU_DATA.)

--import=module

Ajouté dans : v19.0.0, v18.18.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Précharger le module spécifié au démarrage. Si l'indicateur est fourni plusieurs fois, chaque module sera exécuté séquentiellement dans l'ordre où il apparaît, en commençant par ceux fournis dans NODE_OPTIONS.

Suit les règles de résolution des modules ECMAScript. Utilisez --require pour charger un module CommonJS. Les modules préchargés avec --require seront exécutés avant les modules préchargés avec --import.

Les modules sont préchargés dans le thread principal ainsi que dans tous les threads de travail, les processus bifurqués ou les processus clusterisés.

--input-type=type

Ajouté dans : v12.0.0

Cela configure Node.js pour interpréter les entrées --eval ou STDIN comme CommonJS ou comme un module ES. Les valeurs valides sont "commonjs" ou "module". La valeur par défaut est "commonjs".

L'interpréteur de commandes REPL ne prend pas en charge cette option. L'utilisation de --input-type=module avec --print entraînera une erreur, car --print ne prend pas en charge la syntaxe des modules ES.

--insecure-http-parser

Ajouté dans : v13.4.0, v12.15.0, v10.19.0

Active les indicateurs de tolérance sur l’analyseur HTTP. Cela peut permettre l’interopérabilité avec des implémentations HTTP non conformes.

Lorsqu’il est activé, l’analyseur acceptera :

• Des valeurs d’en-têtes HTTP invalides.
• Des versions HTTP invalides.
• Les messages contenant à la fois les en-têtes Transfer-Encoding et Content-Length.
• Les données supplémentaires après le message lorsque Connection: close est présent.
• Les encodages de transfert supplémentaires après que chunked a été fourni.
• L’utilisation de \n comme séparateur de jeton au lieu de \r\n.
• L’absence de \r\n après un bloc.
• La présence d’espaces après la taille d’un bloc et avant \r\n.

Tout ce qui précède exposera votre application à des attaques de contrebande ou d’empoisonnement des requêtes. Évitez d’utiliser cette option.

Avertissement : la liaison de l’inspecteur à une combinaison IP publique :port est non sécurisée

La liaison de l’inspecteur à une IP publique (y compris 0.0.0.0) avec un port ouvert est non sécurisée, car elle permet aux hôtes externes de se connecter à l’inspecteur et d’effectuer une attaque d’exécution de code à distance.

Si vous spécifiez un hôte, assurez-vous que :

• L’hôte n’est pas accessible depuis les réseaux publics.
• Un pare-feu interdit les connexions indésirables sur le port.

Plus précisément, --inspect=0.0.0.0 est non sécurisé si le port (9229 par défaut) n’est pas protégé par un pare-feu.

Consultez la section implications de sécurité du débogage pour plus d’informations.

--inspect-brk[=[host:]port]

Ajouté dans : v7.6.0

Active l’inspecteur sur host:port et interrompt au début du script utilisateur. Le host:port par défaut est 127.0.0.1:9229. Si le port 0 est spécifié, un port disponible aléatoire sera utilisé.

Consultez Intégration de l’inspecteur V8 pour Node.js pour une explication plus approfondie du débogueur Node.js.

--inspect-port=[host:]port

Ajouté dans : v7.6.0

Définit le host:port à utiliser lorsque l’inspecteur est activé. Utile lors de l’activation de l’inspecteur en envoyant le signal SIGUSR1.

L’hôte par défaut est 127.0.0.1. Si le port 0 est spécifié, un port disponible aléatoire sera utilisé.

Consultez l’avertissement de sécurité ci-dessous concernant l’utilisation du paramètre host.

--inspect-publish-uid=stderr,http

Spécifie les méthodes d'exposition de l'URL du socket web de l'inspecteur.

Par défaut, l'URL du websocket de l'inspecteur est disponible dans stderr et sous le point de terminaison /json/list sur http://host:port/json/list.

--inspect-wait[=[host:]port]

Ajouté dans : v22.2.0, v20.15.0

Active l'inspecteur sur host:port et attend la connexion du débogueur. host:port par défaut est 127.0.0.1:9229. Si le port 0 est spécifié, un port disponible aléatoire sera utilisé.

Voir Intégration de l'inspecteur V8 pour Node.js pour plus d'explications sur le débogueur Node.js.

--inspect[=[host:]port]

Ajouté dans : v6.3.0

Active l'inspecteur sur host:port. La valeur par défaut est 127.0.0.1:9229. Si le port 0 est spécifié, un port disponible aléatoire sera utilisé.

L'intégration de l'inspecteur V8 permet à des outils tels que Chrome DevTools et les IDE de déboguer et de profiler les instances Node.js. Les outils se connectent aux instances Node.js via un port TCP et communiquent à l'aide du protocole Chrome DevTools. Voir Intégration de l'inspecteur V8 pour Node.js pour plus d'explications sur le débogueur Node.js.

-i, --interactive

Ajouté dans : v0.7.7

Ouvre le REPL même si stdin ne semble pas être un terminal.

--jitless

Ajouté dans : v12.0.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental. Ce drapeau est hérité de V8 et est sujet à des modifications en amont.

Désactive l'allocation d'espace mémoire exécutable au moment de l'exécution. Cela peut être nécessaire sur certaines plateformes pour des raisons de sécurité. Cela peut également réduire la surface d'attaque sur d'autres plateformes, mais l'impact sur les performances peut être important.

--localstorage-file=file

Ajouté dans : v22.4.0

Le fichier utilisé pour stocker les données localStorage. Si le fichier n'existe pas, il est créé lors du premier accès à localStorage. Le même fichier peut être partagé entre plusieurs processus Node.js simultanément. Ce drapeau n'a aucun effet à moins que Node.js ne soit lancé avec le drapeau --experimental-webstorage.

--max-http-header-size=size

[Historique]

Version	Modifications
v13.13.0	Taille maximale par défaut des en-têtes HTTP modifiée de 8 Ko à 16 Ko.
v11.6.0, v10.15.0	Ajouté dans : v11.6.0, v10.15.0

Spécifie la taille maximale, en octets, des en-têtes HTTP. La valeur par défaut est 16 Ko.

--napi-modules

Ajouté dans : v7.10.0

Cette option est une opération sans effet. Elle est conservée pour des raisons de compatibilité.

--network-family-autoselection-attempt-timeout

Ajouté dans : v22.1.0, v20.13.0

Définit la valeur par défaut du délai d'expiration de la tentative de sélection automatique de la famille de réseaux. Pour plus d'informations, consultez net.getDefaultAutoSelectFamilyAttemptTimeout().

--no-addons

Ajouté dans : v16.10.0, v14.19.0

Désactive la condition d'exportation node-addons et le chargement des modules natifs. Lorsque --no-addons est spécifié, l'appel à process.dlopen ou l'inclusion d'un module natif C++ échouera et lèvera une exception.

--no-deprecation

Ajouté dans : v0.8.0

Supprime les avertissements d'obsolescence.

--no-experimental-detect-module

[Historique]

Version	Modifications
v22.7.0	La détection de la syntaxe est activée par défaut.
v21.1.0, v20.10.0	Ajouté dans : v21.1.0, v20.10.0

Désactive l'utilisation de la détection de la syntaxe pour déterminer le type de module.

--no-experimental-global-navigator

Ajouté dans : v21.2.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Désactive l'exposition de l'API Navigator sur la portée globale.

--no-experimental-repl-await

Ajouté dans : v16.6.0

Utilisez cet indicateur pour désactiver await de niveau supérieur dans REPL.

--no-experimental-require-module

[Historique]

Version	Modifications
v23.0.0	Ceci est maintenant faux par défaut.
v22.0.0, v20.17.0	Ajouté dans : v22.0.0, v20.17.0

[Stable : 1 - Expérimental]

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

Désactive la prise en charge du chargement d'un graphe de module ES synchrone dans require().

Voir Chargement des modules ECMAScript à l'aide de require().

--no-experimental-sqlite

[Historique]

Version	Modifications
v23.4.0	SQLite n'est plus marqué comme expérimental mais reste expérimental.
v22.5.0	Ajouté dans : v22.5.0

Désactive le module expérimental node:sqlite.

--no-experimental-websocket

Ajouté dans : v22.0.0

Désactive l'exposition de WebSocket sur la portée globale.

--no-extra-info-on-fatal-exception

Ajouté dans : v17.0.0

Masque les informations supplémentaires sur les exceptions fatales entraînant une sortie.

--no-force-async-hooks-checks

Ajouté dans : v9.0.0

Désactive les vérifications d'exécution pour async_hooks. Celles-ci resteront activées dynamiquement lorsque async_hooks est activé.

--no-global-search-paths

Ajouté dans : v16.10.0

Ne recherche pas les modules à partir des chemins globaux comme $HOME/.node_modules et $NODE_PATH.

--no-network-family-autoselection

[Historique]

Version	Modifications
v20.0.0	L'indicateur a été renommé de --no-enable-network-family-autoselection à --no-network-family-autoselection. L'ancien nom peut toujours fonctionner comme alias.
v19.4.0	Ajouté dans : v19.4.0

Désactive l'algorithme de sélection automatique de la famille sauf si les options de connexion l'activent explicitement.

--no-warnings

Ajouté dans : v6.0.0

Supprime tous les avertissements du processus (y compris les dépréciations).

--node-memory-debug

Ajouté dans : v15.0.0, v14.18.0

Active des vérifications de débogage supplémentaires pour les fuites de mémoire dans les composants internes de Node.js. Cela n'est généralement utile que pour les développeurs qui déboguent Node.js lui-même.

--openssl-config=file

Ajouté dans : v6.9.0

Charge un fichier de configuration OpenSSL au démarrage. Entre autres utilisations, cela peut servir à activer le chiffrement conforme à FIPS si Node.js est compilé avec OpenSSL compatible FIPS.

--openssl-legacy-provider

Ajouté dans : v17.0.0, v16.17.0

Active le fournisseur hérité OpenSSL 3.0. Pour plus d'informations, veuillez consulter OSSL_PROVIDER-legacy.

--openssl-shared-config

Ajouté dans : v18.5.0, v16.17.0, v14.21.0

Active la lecture de la section de configuration par défaut d'OpenSSL, openssl_conf, à partir du fichier de configuration OpenSSL. Le fichier de configuration par défaut est nommé openssl.cnf, mais cela peut être modifié à l'aide de la variable d'environnement OPENSSL_CONF ou de l'option de ligne de commande --openssl-config. L'emplacement du fichier de configuration OpenSSL par défaut dépend de la manière dont OpenSSL est lié à Node.js. Le partage de la configuration OpenSSL peut avoir des implications indésirables et il est recommandé d'utiliser une section de configuration spécifique à Node.js, qui est nodejs_conf et est la valeur par défaut lorsque cette option n'est pas utilisée.

--pending-deprecation

Ajouté dans : v8.0.0

Émet des avertissements d'obsolescence en attente.

Les obsolescences en attente sont généralement identiques à une obsolescence d'exécution, à l'exception notable qu'elles sont désactivées par défaut et ne seront pas émises à moins que l'indicateur de ligne de commande --pending-deprecation, ou la variable d'environnement NODE_PENDING_DEPRECATION=1, ne soit défini. Les obsolescences en attente sont utilisées pour fournir un mécanisme d'"alerte précoce" sélective que les développeurs peuvent exploiter pour détecter l'utilisation d'API obsolètes.

--permission

[Historique]

Version	Modifications
v23.5.0	Le modèle d'autorisation est désormais stable.
v20.0.0	Ajouté dans : v20.0.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable.

Active le modèle d'autorisation pour le processus actuel. Lorsqu'il est activé, les autorisations suivantes sont restreintes :

• Système de fichiers - gérable via les indicateurs --allow-fs-read, --allow-fs-write
• Processus enfant - gérable via l'indicateur --allow-child-process
• Threads worker - gérable via l'indicateur --allow-worker
• WASI - gérable via l'indicateur --allow-wasi
• Modules complémentaires - gérable via l'indicateur --allow-addons

--preserve-symlinks

Ajouté dans : v6.3.0

Indique au chargeur de modules de préserver les liens symboliques lors de la résolution et de la mise en cache des modules.

Par défaut, lorsque Node.js charge un module à partir d'un chemin qui est symboliquement lié à un autre emplacement sur le disque, Node.js supprime la référence du lien et utilise le « chemin réel » réel sur le disque du module à la fois comme identificateur et comme chemin racine pour localiser d'autres modules de dépendance. Dans la plupart des cas, ce comportement par défaut est acceptable. Cependant, lors de l'utilisation de dépendances pair à pair liées symboliquement, comme illustré dans l'exemple ci-dessous, le comportement par défaut provoque le lancement d'une exception si moduleA tente de demander moduleB comme dépendance pair :

{appDir}
 ├── app
 │   ├── index.js
 │   └── node_modules
 │       ├── moduleA -> {appDir}/moduleA
 │       └── moduleB
 │           ├── index.js
 │           └── package.json
 └── moduleA
     ├── index.js
     └── package.json

L'indicateur de ligne de commande --preserve-symlinks indique à Node.js d'utiliser le chemin de lien symbolique pour les modules au lieu du chemin réel, permettant de trouver des dépendances pair à pair liées symboliquement.

Notez toutefois que l'utilisation de --preserve-symlinks peut avoir d'autres effets secondaires. Plus précisément, les modules natif liés symboliquement peuvent ne pas se charger s'ils sont liés à partir de plusieurs emplacements dans l'arborescence des dépendances (Node.js les considérerait comme deux modules distincts et tenterait de charger le module plusieurs fois, ce qui entraînerait le lancement d'une exception).

L'indicateur --preserve-symlinks ne s'applique pas au module principal, ce qui permet à node --preserve-symlinks node_module/.bin/\<foo\> de fonctionner. Pour appliquer le même comportement au module principal, utilisez également --preserve-symlinks-main.

--preserve-symlinks-main

Ajouté dans : v10.2.0

Indique au chargeur de modules de préserver les liens symboliques lors de la résolution et de la mise en cache du module principal (require.main).

Ce drapeau existe afin que le module principal puisse bénéficier du même comportement que --preserve-symlinks offre à toutes les autres importations ; ce sont cependant des drapeaux distincts, pour des raisons de compatibilité descendante avec les anciennes versions de Node.js.

--preserve-symlinks-main n'implique pas --preserve-symlinks ; utilisez --preserve-symlinks-main en plus de --preserve-symlinks lorsqu'il n'est pas souhaitable de suivre les liens symboliques avant de résoudre les chemins relatifs.

Voir --preserve-symlinks pour plus d'informations.

-p, --print "script"

[Historique]

Version	Modifications
v5.11.0	Les bibliothèques intégrées sont désormais disponibles en tant que variables prédéfinies.
v0.6.4	Ajouté dans : v0.6.4

Identique à -e mais affiche le résultat.

--prof

Ajouté dans : v2.0.0

Génère une sortie du profileur V8.

--prof-process

Ajouté dans : v5.2.0

Traite la sortie du profileur V8 générée à l'aide de l'option V8 --prof.

--redirect-warnings=file

Ajouté dans : v8.0.0

Écrit les avertissements du processus dans le fichier donné au lieu de les afficher sur stderr. Le fichier sera créé s'il n'existe pas et sera mis à jour s'il existe déjà. Si une erreur se produit lors de la tentative d'écriture de l'avertissement dans le fichier, l'avertissement sera écrit sur stderr à la place.

Le nom du fichier peut être un chemin absolu. Sinon, le répertoire par défaut dans lequel il sera écrit est contrôlé par l'option de ligne de commande --diagnostic-dir.

--report-compact

Ajouté dans : v13.12.0, v12.17.0

Écrit les rapports dans un format compact, 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.

--report-dir=directory, report-directory=directory

[Historique]

Version	Modifications
v13.12.0, v12.17.0	Cette option n'est plus expérimentale.
v12.0.0	Changé de --diagnostic-report-directory à --report-directory.
v11.8.0	Ajouté dans : v11.8.0

Emplacement où le rapport sera généré.

--report-exclude-env

Ajouté dans : v23.3.0

Lorsque --report-exclude-env est passé, le rapport de diagnostic généré ne contiendra pas les données environmentVariables.

--report-exclude-network

Ajouté dans : v22.0.0, v20.13.0

Exclut header.networkInterfaces du rapport de diagnostic. Par défaut, cette option n'est pas définie et les interfaces réseau sont incluses.

--report-filename=filename

[Historique]

Version	Modifications
v13.12.0, v12.17.0	Cette option n'est plus expérimentale.
v12.0.0	renommé de --diagnostic-report-filename à --report-filename.
v11.8.0	Ajouté dans : v11.8.0

Nom du fichier dans lequel le rapport sera écrit.

Si le nom de fichier est défini sur 'stdout' ou 'stderr', le rapport est écrit respectivement sur la sortie standard ou la sortie d'erreur du processus.

--report-on-fatalerror

[Historique]

Version	Modifications
v14.0.0, v13.14.0, v12.17.0	Cette option n'est plus expérimentale.
v12.0.0	renommé de --diagnostic-report-on-fatalerror à --report-on-fatalerror.
v11.8.0	Ajouté dans : v11.8.0

Permet au rapport d'être déclenché sur les erreurs fatales (erreurs internes au sein de l'environnement d'exécution Node.js telles que l'épuisement de la mémoire) qui entraînent la terminaison de l'application. Utile pour inspecter divers éléments de données de diagnostic tels que le tas, la pile, l'état de la boucle d'événements, la consommation des ressources, etc., pour comprendre l'erreur fatale.

--report-on-signal

[Historique]

Version	Modifications
v13.12.0, v12.17.0	Cette option n'est plus expérimentale.
v12.0.0	renommé de --diagnostic-report-on-signal à --report-on-signal.
v11.8.0	Ajouté dans : v11.8.0

Permet de générer un rapport lors de la réception du signal spécifié (ou prédéfini) par le processus Node.js en cours d'exécution. Le signal pour déclencher le rapport est spécifié via --report-signal.

--report-signal=signal

[Historique]

Version	Modifications
v13.12.0, v12.17.0	Cette option n'est plus expérimentale.
v12.0.0	renommé de --diagnostic-report-signal à --report-signal.
v11.8.0	Ajouté dans : v11.8.0

Définit ou réinitialise le signal pour la génération de rapport (non pris en charge sous Windows). Le signal par défaut est SIGUSR2.

--report-uncaught-exception

[Historique]

Version	Modifications
v18.8.0, v16.18.0	Aucun rapport n'est généré si l'exception non interceptée est gérée.
v13.12.0, v12.17.0	Cette option n'est plus expérimentale.
v12.0.0	Renommée de --diagnostic-report-uncaught-exception à --report-uncaught-exception.
v11.8.0	Ajoutée dans la version : v11.8.0

Active la génération d'un rapport lorsque le processus se termine en raison d'une exception non interceptée. Utile pour inspecter la pile JavaScript conjointement avec la pile native et d'autres données de l'environnement d'exécution.

-r, --require module

Ajouté dans : v1.6.0

Précharge le module spécifié au démarrage.

Suit les règles de résolution de module de require(). module peut être soit un chemin d'accès à un fichier, soit le nom d'un module Node.

Seuls les modules CommonJS sont pris en charge. Utilisez --import pour précharger un module ECMAScript. Les modules préchargés avec --require seront exécutés avant les modules préchargés avec --import.

Les modules sont préchargés dans le thread principal ainsi que dans tous les threads de travail, les processus bifurqués ou les processus en cluster.

--run

[Historique]

Version	Modifications
v22.3.0	La variable d'environnement NODE_RUN_SCRIPT_NAME est ajoutée.
v22.3.0	La variable d'environnement NODE_RUN_PACKAGE_JSON_PATH est ajoutée.
v22.3.0	Parcourt le répertoire jusqu'à la racine et trouve un fichier package.json pour exécuter la commande à partir de celui-ci, et met à jour la variable d'environnement PATH en conséquence.
v22.0.0	Ajouté dans la version : v22.0.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Ceci exécute une commande spécifiée à partir de l'objet "scripts" d'un fichier package.json. Si une "command" manquante est fournie, elle répertorie les scripts disponibles.

--run parcourt le répertoire jusqu'à la racine et trouve un fichier package.json pour exécuter la commande à partir de celui-ci.

--run ajoute ./node_modules/.bin pour chaque ancêtre du répertoire courant, au PATH afin d'exécuter les binaires de différents dossiers où plusieurs répertoires node_modules sont présents, si ancestor-folder/node_modules/.bin est un répertoire.

--run exécute la commande dans le répertoire contenant le fichier package.json associé.

Par exemple, la commande suivante exécutera le script test du fichier package.json dans le dossier courant :

$ node --run test

Vous pouvez également passer des arguments à la commande. Tout argument après -- sera ajouté au script :

$ node --run test -- --verbose

Limitations intentionnelles

node --run n'est pas conçu pour correspondre au comportement de npm run ou des commandes run d'autres gestionnaires de paquets. L'implémentation Node.js est intentionnellement plus limitée, afin de se concentrer sur des performances optimales pour les cas d'utilisation les plus courants. Certaines fonctionnalités d'autres implémentations de run qui sont intentionnellement exclues sont :

• L'exécution de scripts pre ou post en plus du script spécifié.
• La définition de variables d'environnement spécifiques au gestionnaire de paquets.

Variables d'environnement

Les variables d'environnement suivantes sont définies lors de l'exécution d'un script avec --run :

• NODE_RUN_SCRIPT_NAME : Le nom du script en cours d'exécution. Par exemple, si --run est utilisé pour exécuter test, la valeur de cette variable sera test.
• NODE_RUN_PACKAGE_JSON_PATH : Le chemin d'accès au fichier package.json qui est en cours de traitement.

--secure-heap-min=n

Ajouté dans : v15.6.0

Lors de l'utilisation de --secure-heap, l'indicateur --secure-heap-min spécifie l'allocation minimale à partir du tas sécurisé. La valeur minimale est 2. La valeur maximale est la plus petite valeur entre --secure-heap et 2147483647. La valeur donnée doit être une puissance de deux.

--secure-heap=n

Ajouté dans : v15.6.0

Initialise un tas sécurisé OpenSSL de n octets. Une fois initialisé, le tas sécurisé est utilisé pour certains types d'allocations au sein d'OpenSSL lors de la génération de clés et d'autres opérations. Ceci est utile, par exemple, pour empêcher la fuite d'informations sensibles en raison de dépassements ou de sous-dépassements de pointeurs.

Le tas sécurisé est de taille fixe et ne peut pas être redimensionné à l'exécution, donc, s'il est utilisé, il est important de sélectionner un tas suffisamment grand pour couvrir toutes les utilisations de l'application.

La taille du tas donnée doit être une puissance de deux. Toute valeur inférieure à 2 désactivera le tas sécurisé.

Le tas sécurisé est désactivé par défaut.

Le tas sécurisé n'est pas disponible sous Windows.

Voir CRYPTO_secure_malloc_init pour plus de détails.

--snapshot-blob=path

Ajouté dans : v18.8.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Utilisé avec --build-snapshot, --snapshot-blob spécifie le chemin d'accès où le blob de snapshot généré est écrit. S'il n'est pas spécifié, le blob généré est écrit dans snapshot.blob dans le répertoire de travail courant.

Utilisé sans --build-snapshot, --snapshot-blob spécifie le chemin d'accès au blob utilisé pour restaurer l'état de l'application.

Lors du chargement d'un snapshot, Node.js vérifie que :

S'ils ne correspondent pas, Node.js refuse de charger le snapshot et se termine avec le code de statut 1.

--test

[Historique]

Version	Modifications
v20.0.0	Le lanceur de tests est désormais stable.
v19.2.0, v18.13.0	Le lanceur de tests prend maintenant en charge l'exécution en mode surveillance.
v18.1.0, v16.17.0	Ajouté dans : v18.1.0, v16.17.0

Démarre le lanceur de tests en ligne de commande Node.js. Cet indicateur ne peut pas être combiné avec --watch-path, --check, --eval, --interactive, ou l'inspecteur. Consultez la documentation sur l'exécution des tests à partir de la ligne de commande pour plus de détails.

--test-concurrency

Ajouté dans : v21.0.0, v20.10.0, v18.19.0

Le nombre maximal de fichiers de test que l'interface CLI du lanceur de tests exécutera simultanément. Si --experimental-test-isolation est défini sur 'none', cet indicateur est ignoré et la concurrence est de un. Sinon, la concurrence est par défaut os.availableParallelism() - 1.

--test-coverage-branches=threshold

Ajouté dans : v22.8.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Nécessite un pourcentage minimum de branches couvertes. Si la couverture du code n'atteint pas le seuil spécifié, le processus se terminera avec le code 1.

--test-coverage-exclude

Ajouté dans : v22.5.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Exclut des fichiers spécifiques de la couverture du code à l'aide d'un modèle glob, qui peut correspondre à des chemins de fichiers absolus et relatifs.

Cette option peut être spécifiée plusieurs fois pour exclure plusieurs modèles glob.

Si --test-coverage-exclude et --test-coverage-include sont fournis, les fichiers doivent répondre aux deux critères pour être inclus dans le rapport de couverture.

Par défaut, tous les fichiers de test correspondants sont exclus du rapport de couverture. La spécification de cette option remplacera le comportement par défaut.

--test-coverage-functions=threshold

Ajouté dans : v22.8.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Nécessite un pourcentage minimum de fonctions couvertes. Si la couverture du code n'atteint pas le seuil spécifié, le processus se terminera avec le code 1.

--test-coverage-include

Ajouté dans : v22.5.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Inclut des fichiers spécifiques dans la couverture de code à l’aide d’un motif glob, qui peut correspondre à des chemins de fichiers absolus et relatifs.

Cette option peut être spécifiée plusieurs fois pour inclure plusieurs motifs glob.

Si --test-coverage-exclude et --test-coverage-include sont tous deux fournis, les fichiers doivent répondre aux deux critères pour être inclus dans le rapport de couverture.

--test-coverage-lines=threshold

Ajouté dans : v22.8.0

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Nécessite un pourcentage minimum de lignes couvertes. Si la couverture de code n’atteint pas le seuil spécifié, le processus se termine avec le code 1.

--test-force-exit

Ajouté dans : v22.0.0, v20.14.0

Configure le lanceur de tests pour qu’il quitte le processus une fois que tous les tests connus ont terminé leur exécution, même si la boucle d’événements resterait autrement active.

--test-name-pattern

[Historique]

Version	Modifications
v20.0.0	Le lanceur de tests est désormais stable.
v18.11.0	Ajouté dans : v18.11.0

Une expression régulière qui configure le lanceur de tests pour qu’il n’exécute que les tests dont le nom correspond au motif fourni. Consultez la documentation sur le filtrage des tests par nom pour plus de détails.

Si --test-name-pattern et --test-skip-pattern sont tous deux fournis, les tests doivent satisfaire aux deux exigences pour être exécutés.

--test-only

[Historique]

Version	Modifications
v20.0.0	Le lanceur de tests est désormais stable.
v18.0.0, v16.17.0	Ajouté dans : v18.0.0, v16.17.0

Configure le lanceur de tests pour qu’il n’exécute que les tests de niveau supérieur qui ont l’option only définie. Cet indicateur n’est pas nécessaire lorsque l’isolation des tests est désactivée.

--test-reporter

[Historique]

Version	Modifications
v20.0.0	Le lanceur de tests est désormais stable.
v19.6.0, v18.15.0	Ajouté dans : v19.6.0, v18.15.0

Un générateur de rapports de tests à utiliser lors de l’exécution des tests. Consultez la documentation sur les générateurs de rapports de tests pour plus de détails.

--test-reporter-destination

[Historique]

Version	Modifications
v20.0.0	Le moteur de test est désormais stable.
v19.6.0, v18.15.0	Ajouté dans : v19.6.0, v18.15.0

La destination pour le reporter de test correspondant. Consultez la documentation sur les reporters de test pour plus de détails.

--test-shard

Ajouté dans : v20.5.0, v18.19.0

Fragment de suite de test à exécuter au format \<index\>/\<total\>, où

index est un entier positif, index des parties divisées total est un entier positif, total des parties divisées Cette commande divisera tous les fichiers de test en total parties égales et n'exécutera que ceux qui se trouvent dans une partie index.

Par exemple, pour diviser votre suite de tests en trois parties, utilisez ceci :

node --test --test-shard=1/3
node --test --test-shard=2/3
node --test --test-shard=3/3

--test-skip-pattern

Ajouté dans : v22.1.0

Une expression régulière qui configure le moteur de test pour ignorer les tests dont le nom correspond au motif fourni. Consultez la documentation sur le filtrage des tests par nom pour plus de détails.

Si --test-name-pattern et --test-skip-pattern sont tous deux fournis, les tests doivent satisfaire les deux exigences pour être exécutés.

--test-timeout

Ajouté dans : v21.2.0, v20.11.0

Un nombre de millisecondes après lequel l'exécution du test échouera. Si non spécifié, les sous-tests héritent de cette valeur de leur parent. La valeur par défaut est Infinity.

--test-update-snapshots

[Historique]

Version	Modifications
v23.4.0	Les tests Snapsnot ne sont plus expérimentaux.
v22.3.0	Ajouté dans : v22.3.0

Régénère les fichiers de snapshot utilisés par le moteur de test pour les tests de snapshot.

--throw-deprecation

Ajouté dans : v0.11.14

Lève des erreurs pour les dépréciations.

--title=title

Ajouté dans : v10.7.0

Définit process.title au démarrage.

--tls-cipher-list=list

Ajouté dans : v4.0.0

Spécifie une liste de chiffrements TLS alternative par défaut. Nécessite que Node.js soit compilé avec la prise en charge du chiffrement (par défaut).

--tls-keylog=file

Ajouté dans : v13.2.0, v12.16.0

Journalise les données clés TLS dans un fichier. Les données clés sont au format NSS SSLKEYLOGFILE et peuvent être utilisées par des logiciels (tels que Wireshark) pour décrypter le trafic TLS.

--tls-max-v1.2

Ajouté dans : v12.0.0, v10.20.0

Définit tls.DEFAULT_MAX_VERSION sur 'TLSv1.2'. À utiliser pour désactiver la prise en charge de TLSv1.3.

--tls-max-v1.3

Ajouté dans : v12.0.0

Définit la valeur par défaut de tls.DEFAULT_MAX_VERSION sur 'TLSv1.3'. À utiliser pour activer la prise en charge de TLSv1.3.

--tls-min-v1.0

Ajouté dans : v12.0.0, v10.20.0

Définit la valeur par défaut de tls.DEFAULT_MIN_VERSION sur 'TLSv1'. À utiliser pour la compatibilité avec les anciens clients ou serveurs TLS.

--tls-min-v1.1

Ajouté dans : v12.0.0, v10.20.0

Définit la valeur par défaut de tls.DEFAULT_MIN_VERSION sur 'TLSv1.1'. À utiliser pour la compatibilité avec les anciens clients ou serveurs TLS.

--tls-min-v1.2

Ajouté dans : v12.2.0, v10.20.0

Définit la valeur par défaut de tls.DEFAULT_MIN_VERSION sur 'TLSv1.2'. C'est la valeur par défaut pour les versions 12.x et supérieures, mais l'option est prise en charge pour la compatibilité avec les anciennes versions de Node.js.

--tls-min-v1.3

Ajouté dans : v12.0.0

Définit la valeur par défaut de tls.DEFAULT_MIN_VERSION sur 'TLSv1.3'. À utiliser pour désactiver la prise en charge de TLSv1.2, qui est moins sécurisé que TLSv1.3.

--trace-deprecation

Ajouté dans : v0.8.0

Affiche les traces de pile pour les dépréciations.

--trace-env

Ajouté dans : v23.4.0

Affiche sur stderr des informations sur tout accès aux variables d'environnement effectué dans l'instance Node.js actuelle, notamment :

• Les lectures de variables d'environnement effectuées en interne par Node.js.
• Les écritures sous la forme process.env.KEY = "SOME VALUE".
• Les lectures sous la forme process.env.KEY.
• Les définitions sous la forme Object.defineProperty(process.env, 'KEY', {...}).
• Les requêtes sous la forme Object.hasOwn(process.env, 'KEY'), process.env.hasOwnProperty('KEY') ou 'KEY' in process.env.
• Les suppressions sous la forme delete process.env.KEY.
• Les énumérations sous la forme ...process.env ou Object.keys(process.env).

Seuls les noms des variables d'environnement auxquelles on accède sont affichés. Les valeurs ne sont pas affichées.

Pour afficher la trace de pile de l'accès, utilisez --trace-env-js-stack et/ou --trace-env-native-stack.

--trace-env-js-stack

Ajouté dans : v23.4.0

En plus de ce que fait --trace-env, ceci imprime la trace de pile JavaScript de l'accès.

--trace-env-native-stack

Ajouté dans : v23.4.0

En plus de ce que fait --trace-env, ceci imprime la trace de pile native de l'accès.

--trace-event-categories

Ajouté dans : v7.7.0

Une liste séparée par des virgules des catégories qui doivent être tracées lorsque le traçage d'événements de trace est activé à l'aide de --trace-events-enabled.

--trace-event-file-pattern

Ajouté dans : v9.8.0

Chaîne de modèle spécifiant le chemin d'accès au fichier pour les données d'événements de trace, elle prend en charge ${rotation} et ${pid}.

--trace-events-enabled

Ajouté dans : v7.7.0

Active la collecte des informations de traçage des événements de trace.

--trace-exit

Ajouté dans : v13.5.0, v12.16.0

Imprime une trace de pile chaque fois qu'un environnement est quitté proactivement, c'est-à-dire en invoquant process.exit().

--trace-require-module=mode

Ajouté dans : v23.5.0

Imprime des informations sur l'utilisation de Chargement des modules ECMAScript à l'aide de require().

Lorsque mode est all, toute l'utilisation est imprimée. Lorsque mode est no-node-modules, l'utilisation du dossier node_modules est exclue.

--trace-sigint

Ajouté dans : v13.9.0, v12.17.0

Imprime une trace de pile sur SIGINT.

--trace-sync-io

Ajouté dans : v2.1.0

Imprime une trace de pile chaque fois qu'un E/S synchrone est détecté après le premier tour de la boucle d'événements.

--trace-tls

Ajouté dans : v12.2.0

Imprime les informations de trace des paquets TLS sur stderr. Ceci peut être utilisé pour déboguer les problèmes de connexion TLS.

--trace-uncaught

Ajouté dans : v13.1.0

Imprime les traces de pile pour les exceptions non interceptées ; généralement, la trace de pile associée à la création d'une erreur Error est imprimée, tandis que cela fait également imprimer à Node.js la trace de pile associée au lancement de la valeur (qui n'a pas besoin d'être une instance Error).

L'activation de cette option peut affecter négativement le comportement du ramasse-miettes.

--trace-warnings

Ajouté dans : v6.0.0

Imprime les traces de pile pour les avertissements de processus (y compris les dépréciations).

--track-heap-objects

Ajouté dans : v2.4.0

Suit les allocations d’objets heap pour les snapshots heap.

--unhandled-rejections=mode

[Historique]

Version	Modifications
v15.0.0	Mode par défaut changé en throw. Précédemment, un avertissement était émis.
v12.0.0, v10.17.0	Ajouté dans : v12.0.0, v10.17.0

L’utilisation de ce drapeau permet de modifier ce qui doit se produire lorsqu’un rejet non géré se produit. L’un des modes suivants peut être choisi :

• throw : Émet unhandledRejection. Si ce hook n’est pas défini, déclenche le rejet non géré comme une exception non interceptée. Ceci est la valeur par défaut.
• strict : Déclenche le rejet non géré comme une exception non interceptée. Si l’exception est gérée, unhandledRejection est émis.
• warn : Déclenche toujours un avertissement, que le hook unhandledRejection soit défini ou non, mais n’affiche pas l’avertissement d’obsolescence.
• warn-with-error-code : Émet unhandledRejection. Si ce hook n’est pas défini, déclenche un avertissement et définit le code de sortie du processus sur 1.
• none : Supprime tous les avertissements.

Si un rejet se produit pendant la phase de chargement statique du module ES du point d’entrée de la ligne de commande, il le déclenchera toujours comme une exception non interceptée.

--use-bundled-ca, --use-openssl-ca

Ajouté dans : v6.11.0

Utilise le magasin d’autorité de certification Mozilla fourni par la version actuelle de Node.js ou utilise le magasin d’autorité de certification par défaut d’OpenSSL. Le magasin par défaut est sélectionnable au moment de la compilation.

Le magasin d’autorité de certification fourni par Node.js est un instantané du magasin d’autorité de certification Mozilla qui est fixé au moment de la publication. Il est identique sur toutes les plates-formes prises en charge.

L’utilisation du magasin OpenSSL permet des modifications externes du magasin. Pour la plupart des distributions Linux et BSD, ce magasin est géré par les mainteneurs de distribution et les administrateurs système. L’emplacement du magasin d’autorité de certification OpenSSL dépend de la configuration de la bibliothèque OpenSSL, mais cela peut être modifié au moment de l’exécution à l’aide de variables d’environnement.

Voir SSL_CERT_DIR et SSL_CERT_FILE.

--use-largepages=mode

Ajouté dans : v13.6.0, v12.17.0

Remappe le code statique Node.js sur des pages mémoire de grande taille au démarrage. Si cela est pris en charge par le système cible, le code statique Node.js sera déplacé sur des pages de 2 Mio au lieu de pages de 4 Kio.

Les valeurs suivantes sont valides pour mode :

• off : Aucune tentative de mappage ne sera effectuée. Il s'agit de la valeur par défaut.
• on : Si le système d'exploitation le prend en charge, une tentative de mappage sera effectuée. L'échec du mappage sera ignoré et un message sera imprimé sur la sortie d'erreur standard.
• silent : Si le système d'exploitation le prend en charge, une tentative de mappage sera effectuée. L'échec du mappage sera ignoré et ne sera pas signalé.

--v8-options

Ajouté dans : v0.1.3

Affiche les options de ligne de commande de V8.

--v8-pool-size=num

Ajouté dans : v5.10.0

Définit la taille du pool de threads de V8 qui sera utilisée pour allouer des tâches en arrière-plan.

Si elle est définie sur 0, Node.js choisira une taille appropriée du pool de threads en fonction d'une estimation du niveau de parallélisme.

Le niveau de parallélisme fait référence au nombre de calculs qui peuvent être effectués simultanément sur une machine donnée. En général, il est identique au nombre de CPU, mais il peut diverger dans des environnements tels que les machines virtuelles ou les conteneurs.

-v, --version

Ajouté dans : v0.1.3

Affiche la version de Node.js.

--watch

[Historique]

Version	Modifications
v22.0.0, v20.13.0	Le mode surveillance est désormais stable.
v19.2.0, v18.13.0	L'exécuteur de tests prend désormais en charge l'exécution en mode surveillance.
v18.11.0, v16.19.0	Ajouté dans : v18.11.0, v16.19.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Démarre Node.js en mode surveillance. En mode surveillance, les modifications apportées aux fichiers surveillés entraînent le redémarrage du processus Node.js. Par défaut, le mode surveillance surveillera le point d'entrée et tout module requis ou importé. Utilisez --watch-path pour spécifier les chemins à surveiller.

Cet indicateur ne peut pas être combiné avec --check, --eval, --interactive ou l'interpréteur de commandes REPL.

node --watch index.js

--watch-path

[Historique]

Version	Modifications
v22.0.0, v20.13.0	Le mode surveillance est désormais stable.
v18.11.0, v16.19.0	Ajouté dans : v18.11.0, v16.19.0

[Stable : 2 - Stable]

Stable : 2 Stabilité : 2 - Stable

Démarre Node.js en mode surveillance et spécifie les chemins à surveiller. En mode surveillance, les modifications apportées aux chemins surveillés entraînent le redémarrage du processus Node.js. Cela désactivera la surveillance des modules requis ou importés, même lorsqu'il est utilisé en combinaison avec --watch.

Ce drapeau ne peut pas être combiné avec --check, --eval, --interactive, --test ou REPL.

node --watch-path=./src --watch-path=./tests index.js

Cette option est uniquement prise en charge sur macOS et Windows. Une exception ERR_FEATURE_UNAVAILABLE_ON_PLATFORM sera levée lorsque l'option est utilisée sur une plateforme qui ne la prend pas en charge.

--watch-preserve-output

Ajouté dans : v19.3.0, v18.13.0

Désactive la suppression de la console lorsque le mode surveillance redémarre le processus.

node --watch --watch-preserve-output test.js

--zero-fill-buffers

Ajouté dans : v6.0.0

Remplit automatiquement par des zéros toutes les instances nouvellement allouées de Buffer et SlowBuffer.

Variables d'environnement

FORCE_COLOR=[1, 2, 3]

La variable d'environnement FORCE_COLOR est utilisée pour activer la sortie colorisée ANSI. La valeur peut être :

• 1, true, ou la chaîne vide '' indiquent une prise en charge des 16 couleurs,
• 2 pour indiquer une prise en charge des 256 couleurs, ou
• 3 pour indiquer une prise en charge des 16 millions de couleurs.

Lorsque FORCE_COLOR est utilisé et défini sur une valeur prise en charge, les variables d'environnement NO_COLOR et NODE_DISABLE_COLORS sont ignorées.

Toute autre valeur entraînera la désactivation de la sortie colorisée.

NODE_COMPILE_CACHE=dir

Ajouté dans : v22.1.0

[Stable : 1 - Expérimental]

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

Active le cache de compilation de module pour l'instance Node.js. Consultez la documentation du cache de compilation de module pour plus de détails.

NODE_DEBUG=module[,…]

Ajouté dans : v0.1.32

Liste de modules principaux séparés par des virgules qui doivent afficher des informations de débogage.

NODE_DEBUG_NATIVE=module[,…]

Liste de modules C++ principaux séparés par des virgules qui doivent afficher des informations de débogage.

NODE_DISABLE_COLORS=1

Ajouté dans : v0.3.0

Lorsque cette variable est définie, les couleurs ne seront pas utilisées dans le REPL.

NODE_DISABLE_COMPILE_CACHE=1

Ajouté dans : v22.8.0

[Stable : 1 - Expérimental]

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

Désactive le cache de compilation des modules pour l’instance Node.js. Consultez la documentation du cache de compilation des modules pour plus de détails.

NODE_EXTRA_CA_CERTS=file

Ajouté dans : v7.3.0

Lorsque cette variable est définie, les autorités de certification « racine » connues (comme VeriSign) seront étendues avec les certificats supplémentaires du fichier file. Le fichier doit contenir un ou plusieurs certificats approuvés au format PEM. Un message sera émis (une seule fois) avec process.emitWarning() si le fichier est manquant ou mal formé, mais toutes les erreurs seront ignorées.

Ni les certificats connus ni les certificats supplémentaires ne sont utilisés lorsque la propriété ca des options est explicitement spécifiée pour un client ou un serveur TLS ou HTTPS.

Cette variable d’environnement est ignorée lorsque node s’exécute en tant que root setuid ou que des capacités de fichier Linux sont définies.

La variable d’environnement NODE_EXTRA_CA_CERTS est uniquement lue lors du premier lancement du processus Node.js. La modification de la valeur à l’exécution à l’aide de process.env.NODE_EXTRA_CA_CERTS n’a aucun effet sur le processus actuel.

NODE_ICU_DATA=file

Ajouté dans : v0.11.15

Chemin des données pour les données ICU (Intl object). Étend les données liées lors de la compilation avec la prise en charge de small-icu.

NODE_NO_WARNINGS=1

Ajouté dans : v6.11.0

Lorsque cette variable est définie sur 1, les avertissements du processus sont ignorés.

NODE_OPTIONS=options...

Ajouté dans : v8.0.0

Une liste d’options de ligne de commande séparées par des espaces. Les options... sont interprétées avant les options de ligne de commande, de sorte que les options de ligne de commande remplaceront ou composeront après tout ce qui se trouve dans options.... Node.js quittera avec une erreur si une option qui n’est pas autorisée dans l’environnement est utilisée, telle que -p ou un fichier de script.

Si une valeur d’option contient un espace, elle peut être échappée à l’aide de guillemets doubles :

NODE_OPTIONS='--require "./my path/file.js"'

Un indicateur singleton passé en tant qu’option de ligne de commande remplacera le même indicateur passé dans NODE_OPTIONS :

# L'inspecteur sera disponible sur le port 5555 {#node_options=options}
NODE_OPTIONS='--inspect=localhost:4444' node --inspect=localhost:5555

Un indicateur pouvant être passé plusieurs fois sera traité comme si ses instances NODE_OPTIONS étaient passées en premier, puis ses instances de ligne de commande par la suite :

NODE_OPTIONS='--require "./a.js"' node --require "./b.js"
# équivaut à : {#the-inspector-will-be-available-on-port-5555}
node --require "./a.js" --require "./b.js"

Les options Node.js autorisées figurent dans la liste suivante. Si une option prend en charge les variantes --XX et --no-XX, les deux sont prises en charge, mais une seule est incluse dans la liste ci-dessous.

• --allow-addons
• --allow-child-process
• --allow-fs-read
• --allow-fs-write
• --allow-wasi
• --allow-worker
• --conditions, -C
• --diagnostic-dir
• --disable-proto
• --disable-warning
• --disable-wasm-trap-handler
• --dns-result-order
• --enable-fips
• --enable-network-family-autoselection
• --enable-source-maps
• --entry-url
• --experimental-abortcontroller
• --experimental-async-context-frame
• --experimental-detect-module
• --experimental-eventsource
• --experimental-import-meta-resolve
• --experimental-json-modules
• --experimental-loader
• --experimental-modules
• --experimental-permission
• --experimental-print-required-tla
• --experimental-require-module
• --experimental-shadow-realm
• --experimental-specifier-resolution
• --experimental-strip-types
• --experimental-top-level-await
• --experimental-transform-types
• --experimental-vm-modules
• --experimental-wasi-unstable-preview1
• --experimental-wasm-modules
• --experimental-webstorage
• --force-context-aware
• --force-fips
• --force-node-api-uncaught-exceptions-policy
• --frozen-intrinsics
• --heap-prof-dir
• --heap-prof-interval
• --heap-prof-name
• --heap-prof
• --heapsnapshot-near-heap-limit
• --heapsnapshot-signal
• --http-parser
• --icu-data-dir
• --import
• --input-type
• --insecure-http-parser
• --inspect-brk
• --inspect-port, --debug-port
• --inspect-publish-uid
• --inspect-wait
• --inspect
• --localstorage-file
• --max-http-header-size
• --napi-modules
• --network-family-autoselection-attempt-timeout
• --no-addons
• --no-deprecation
• --no-experimental-global-navigator
• --no-experimental-repl-await
• --no-experimental-sqlite
• --no-experimental-websocket
• --no-extra-info-on-fatal-exception
• --no-force-async-hooks-checks
• --no-global-search-paths
• --no-network-family-autoselection
• --no-warnings
• --node-memory-debug
• --openssl-config
• --openssl-legacy-provider
• --openssl-shared-config
• --pending-deprecation
• --permission
• --preserve-symlinks-main
• --preserve-symlinks
• --prof-process
• --redirect-warnings
• --report-compact
• --report-dir, --report-directory
• --report-exclude-env
• --report-exclude-network
• --report-filename
• --report-on-fatalerror
• --report-on-signal
• --report-signal
• --report-uncaught-exception
• --require, -r
• --secure-heap-min
• --secure-heap
• --snapshot-blob
• --test-coverage-branches
• --test-coverage-exclude
• --test-coverage-functions
• --test-coverage-include
• --test-coverage-lines
• --test-name-pattern
• --test-only
• --test-reporter-destination
• --test-reporter
• --test-shard
• --test-skip-pattern
• --throw-deprecation
• --title
• --tls-cipher-list
• --tls-keylog
• --tls-max-v1.2
• --tls-max-v1.3
• --tls-min-v1.0
• --tls-min-v1.1
• --tls-min-v1.2
• --tls-min-v1.3
• --trace-deprecation
• --trace-env-js-stack
• --trace-env-native-stack
• --trace-env
• --trace-event-categories
• --trace-event-file-pattern
• --trace-events-enabled
• --trace-exit
• --trace-require-module
• --trace-sigint
• --trace-sync-io
• --trace-tls
• --trace-uncaught
• --trace-warnings
• --track-heap-objects
• --unhandled-rejections
• --use-bundled-ca
• --use-largepages
• --use-openssl-ca
• --v8-pool-size
• --watch-path
• --watch-preserve-output
• --watch
• --zero-fill-buffers

Options V8 autorisées :

• --abort-on-uncaught-exception
• --disallow-code-generation-from-strings
• --enable-etw-stack-walking
• --expose-gc
• --interpreted-frames-native-stack
• --jitless
• --max-old-space-size
• --max-semi-space-size
• --perf-basic-prof-only-functions
• --perf-basic-prof
• --perf-prof-unwinding-info
• --perf-prof
• --stack-trace-limit

--perf-basic-prof-only-functions, --perf-basic-prof, --perf-prof-unwinding-info et --perf-prof ne sont disponibles que sous Linux.

--enable-etw-stack-walking n’est disponible que sous Windows.

NODE_PATH=path[:…]

Ajouté dans : v0.1.32

Liste de répertoires séparés par des ':', préfixée au chemin de recherche des modules.

Sous Windows, il s’agit plutôt d’une liste séparée par des ;.

NODE_PENDING_DEPRECATION=1

Ajouté dans : v8.0.0

Lorsqu’il est défini sur 1, émet des avertissements d’obsolescence en attente.

Les obsolescences en attente sont généralement identiques à une obsolescence d’exécution, à l’exception notable qu’elles sont désactivées par défaut et ne seront pas émises à moins que l’indicateur de ligne de commande --pending-deprecation ou la variable d’environnement NODE_PENDING_DEPRECATION=1 ne soit définie. Les obsolescences en attente servent à fournir un mécanisme d’« alerte précoce » sélectif que les développeurs peuvent utiliser pour détecter l’utilisation d’API obsolètes.

NODE_PENDING_PIPE_INSTANCES=instances

Définit le nombre de handles d’instance de pipe en attente lorsque le serveur de pipe attend des connexions. Ce paramètre s’applique uniquement à Windows.

NODE_PRESERVE_SYMLINKS=1

Ajouté dans : v7.1.0

Lorsqu’il est défini sur 1, indique au chargeur de modules de préserver les liens symboliques lors de la résolution et de la mise en cache des modules.

NODE_REDIRECT_WARNINGS=file

Ajouté dans : v8.0.0

Lorsqu’il est défini, les avertissements de processus seront émis dans le fichier spécifié au lieu d’être imprimés sur stderr. Le fichier sera créé s’il n’existe pas et sera mis à jour s’il existe déjà. Si une erreur se produit lors de la tentative d’écriture de l’avertissement dans le fichier, l’avertissement sera écrit sur stderr à la place. Cela équivaut à utiliser l’indicateur de ligne de commande --redirect-warnings=file.

NODE_REPL_EXTERNAL_MODULE=file

[Historique]

Version	Modifications
v22.3.0, v20.16.0	Suppression de la possibilité d’utiliser cette variable d’environnement avec kDisableNodeOptionsEnv pour les intégrateurs.
v13.0.0, v12.16.0	Ajouté dans : v13.0.0, v12.16.0

Chemin d’accès vers un module Node.js qui sera chargé à la place du REPL intégré. La substitution de cette valeur par une chaîne vide ('') utilisera le REPL intégré.

NODE_REPL_HISTORY=file

Ajouté dans : v3.0.0

Chemin d’accès vers le fichier utilisé pour stocker l’historique persistant du REPL. Le chemin par défaut est ~/.node_repl_history, qui est remplacé par cette variable. La définition de la valeur sur une chaîne vide ('' ou ' ') désactive l’historique persistant du REPL.

NODE_SKIP_PLATFORM_CHECK=value

Ajouté dans : v14.5.0

Si value est égal à '1', la vérification d'une plateforme prise en charge est ignorée lors du démarrage de Node.js. Node.js pourrait ne pas s'exécuter correctement. Tout problème rencontré sur des plateformes non prises en charge ne sera pas corrigé.

NODE_TEST_CONTEXT=value

Si value est égal à 'child', les options du rapporteur de test seront ignorées et la sortie du test sera envoyée à stdout au format TAP. Si une autre valeur est fournie, Node.js ne garantit rien concernant le format du rapporteur utilisé ou sa stabilité.

NODE_TLS_REJECT_UNAUTHORIZED=value

Si value est égal à '0', la validation du certificat est désactivée pour les connexions TLS. Cela rend TLS, et HTTPS par extension, non sécurisé. L'utilisation de cette variable d'environnement est fortement déconseillée.

NODE_V8_COVERAGE=dir

Lorsqu'il est défini, Node.js commence à générer des données de couverture de code JavaScript V8 et de Source Map vers le répertoire fourni en argument (les informations de couverture sont écrites au format JSON dans des fichiers avec un préfixe coverage).

NODE_V8_COVERAGE se propage automatiquement aux sous-processus, ce qui simplifie l'instrumentation des applications qui appellent la famille de fonctions child_process.spawn(). NODE_V8_COVERAGE peut être défini sur une chaîne vide pour empêcher la propagation.

NO_COLOR=<any>

NO_COLOR est un alias pour NODE_DISABLE_COLORS. La valeur de la variable d'environnement est arbitraire.

Sortie de couverture {#no_color=<any>}

La couverture est générée sous forme d'un tableau d'objets ScriptCoverage sur la clé de niveau supérieur result :

{
  "result": [
    {
      "scriptId": "67",
      "url": "internal/tty.js",
      "functions": []
    }
  ]
}

Cache de la source map

[Stable : 1 - Expérimental]

Stable : 1 Stabilité : 1 - Expérimental

Si trouvées, les données de la source map sont ajoutées à la clé de niveau supérieur source-map-cache sur l'objet de couverture JSON.

source-map-cache est un objet dont les clés représentent les fichiers à partir desquels les source maps ont été extraites, et les valeurs incluent l'URL de la source map brute (dans la clé url), les informations Source Map v3 analysées (dans la clé data), et les longueurs de ligne du fichier source (dans la clé lineLengths).

{
  "result": [
    {
      "scriptId": "68",
      "url": "file:///absolute/path/to/source.js",
      "functions": []
    }
  ],
  "source-map-cache": {
    "file:///absolute/path/to/source.js": {
      "url": "./path-to-map.json",
      "data": {
        "version": 3,
        "sources": ["file:///absolute/path/to/original.js"],
        "names": ["Foo", "console", "info"],
        "mappings": "MAAMA,IACJC,YAAaC",
        "sourceRoot": "./"
      },
      "lineLengths": [13, 62, 38, 27]
    }
  }
}

OPENSSL_CONF=fichier

Ajouté dans : v6.11.0

Charge un fichier de configuration OpenSSL au démarrage. Entre autres utilisations, cela peut servir à activer le chiffrement conforme à FIPS si Node.js est compilé avec ./configure --openssl-fips.

Si l'option de ligne de commande --openssl-config est utilisée, la variable d'environnement est ignorée.

SSL_CERT_DIR=répertoire

Ajouté dans : v7.7.0

Si --use-openssl-ca est activé, cela remplace et définit le répertoire OpenSSL contenant les certificats approuvés.

Notez que, à moins que l'environnement enfant ne soit explicitement défini, cette variable d'environnement sera héritée par tous les processus enfants, et si ceux-ci utilisent OpenSSL, cela peut les amener à approuver les mêmes autorités de certification que Node.

SSL_CERT_FILE=fichier

Ajouté dans : v7.7.0

Si --use-openssl-ca est activé, cela remplace et définit le fichier OpenSSL contenant les certificats approuvés.

Notez que, à moins que l'environnement enfant ne soit explicitement défini, cette variable d'environnement sera héritée par tous les processus enfants, et si ceux-ci utilisent OpenSSL, cela peut les amener à approuver les mêmes autorités de certification que Node.

TZ

[Historique]

Version	Modifications
v16.2.0	Modifier la variable TZ à l'aide de process.env.TZ = modifie également le fuseau horaire sous Windows.
v13.0.0	Modifier la variable TZ à l'aide de process.env.TZ = modifie le fuseau horaire sous les systèmes POSIX.
v0.0.1	Ajouté dans : v0.0.1

La variable d'environnement TZ est utilisée pour spécifier la configuration du fuseau horaire.

Bien que Node.js ne prenne pas en charge toutes les manières dont TZ est géré dans d'autres environnements, il prend en charge les ID de fuseau horaire de base (tels que 'Etc/UTC', 'Europe/Paris', ou 'America/New_York'). Il peut prendre en charge quelques autres abréviations ou alias, mais ceux-ci sont fortement déconseillés et non garantis.

$ TZ=Europe/Dublin node -pe "new Date().toString()"
Wed May 12 2021 20:30:48 GMT+0100 (Irish Standard Time)

UV_THREADPOOL_SIZE=taille

Définir le nombre de threads utilisés dans le threadpool de libuv à taille threads.

Node.js utilise des API système asynchrones autant que possible, mais lorsqu'elles n'existent pas, le threadpool de libuv est utilisé pour créer des API Node asynchrones basées sur des API système synchrones. Les API Node.js qui utilisent le threadpool sont :

• toutes les API fs, autres que les API de surveillance de fichiers et celles qui sont explicitement synchrones
• les API cryptographiques asynchrones telles que crypto.pbkdf2(), crypto.scrypt(), crypto.randomBytes(), crypto.randomFill(), crypto.generateKeyPair()
• dns.lookup()
• toutes les API zlib, autres que celles qui sont explicitement synchrones

Comme le threadpool de libuv a une taille fixe, cela signifie que si, pour une raison quelconque, l'une de ces API prend beaucoup de temps, d'autres API (apparemment sans rapport) qui s'exécutent dans le threadpool de libuv connaîtront une dégradation des performances. Afin d'atténuer ce problème, une solution potentielle consiste à augmenter la taille du threadpool de libuv en définissant la variable d'environnement 'UV_THREADPOOL_SIZE' sur une valeur supérieure à 4 (sa valeur par défaut actuelle). Cependant, la définition de cela depuis le processus à l'aide de process.env.UV_THREADPOOL_SIZE=taille n'est pas garantie de fonctionner car le threadpool aurait été créé dans le cadre de l'initialisation de l'exécution bien avant l'exécution du code utilisateur. Pour plus d'informations, consultez la documentation du threadpool libuv.

Options V8 utiles

V8 possède son propre ensemble d'options CLI. Toute option CLI V8 fournie à node sera transmise à V8 pour la gérer. Les options de V8 n'ont aucune garantie de stabilité. L'équipe V8 elle-même ne les considère pas comme faisant partie de son API formelle et se réserve le droit de les modifier à tout moment. De même, elles ne sont pas couvertes par les garanties de stabilité de Node.js. Bon nombre des options V8 ne présentent d'intérêt que pour les développeurs V8. Malgré cela, il existe un petit ensemble d'options V8 largement applicables à Node.js, et elles sont documentées ici :

--abort-on-uncaught-exception

--disallow-code-generation-from-strings

--enable-etw-stack-walking

--expose-gc

--harmony-shadow-realm

--interpreted-frames-native-stack

--jitless

--max-old-space-size=TAILLE (en Mio)

Définit la taille maximale de la section mémoire ancienne de V8. À mesure que la consommation de mémoire approche de la limite, V8 consacrera plus de temps au ramassage des ordures afin de libérer de la mémoire inutilisée.

Sur une machine disposant de 2 Gio de mémoire, envisagez de définir cette valeur sur 1536 (1,5 Gio) pour laisser de la mémoire pour d'autres utilisations et éviter les échanges de mémoire.

node --max-old-space-size=1536 index.js

--max-semi-space-size=TAILLE (en Mio)

Définit la taille maximale de l'espace semi-séparé pour le ramasse-miettes de récupération de V8 en Mio (mébioctets). L'augmentation de la taille maximale d'un espace semi-séparé peut améliorer le débit de Node.js au prix d'une consommation de mémoire accrue.

Étant donné que la taille de la jeune génération du tas V8 est trois fois supérieure (voir YoungGenerationSizeFromSemiSpaceSize dans V8) à la taille de l'espace semi-séparé, une augmentation de 1 Mio de l'espace semi-séparé s'applique à chacun des trois espaces semi-séparés individuels et provoque une augmentation de la taille du tas de 3 Mio. L'amélioration du débit dépend de votre charge de travail (voir #42511).

La valeur par défaut dépend de la limite de mémoire. Par exemple, sur les systèmes 64 bits avec une limite de mémoire de 512 Mio, la taille maximale d'un espace semi-séparé est par défaut de 1 Mio. Pour les limites de mémoire allant jusqu'à 2 Gio inclus, la taille maximale par défaut d'un espace semi-séparé sera inférieure à 16 Mio sur les systèmes 64 bits.

Pour obtenir la meilleure configuration pour votre application, vous devez essayer différentes valeurs de max-semi-space-size lors de l'exécution de tests de performance pour votre application.

Par exemple, test de performance sur des systèmes 64 bits :

for MiB in 16 32 64 128; do
    node --max-semi-space-size=$MiB index.js
done

--perf-basic-prof

--perf-basic-prof-only-functions

--perf-prof

--perf-prof-unwinding-info

--prof

--security-revert

--stack-trace-limit=limit

Le nombre maximal de frames de pile à collecter dans la trace de pile d'une erreur. Le définir à 0 désactive la collecte de la trace de pile. La valeur par défaut est 10.

node --stack-trace-limit=12 -p -e "Error.stackTraceLimit" # affiche 12