Befehlszeilen-API

Node.js bietet eine Vielzahl von Befehlszeilenoptionen. Diese Optionen ermöglichen integriertes Debugging, mehrere Möglichkeiten zur Ausführung von Skripten und andere hilfreiche Laufzeitoptionen.

Um diese Dokumentation als Handbuchseite in einem Terminal anzuzeigen, führen Sie man node aus.

Synopsis

node [options] [V8 options] [\<program-entry-point\> | -e "script" | -] [--] [arguments]

node inspect [\<program-entry-point\> | -e "script" | \<host\>:\<port\>] …

node --v8-options

Führen Sie das Programm ohne Argumente aus, um die REPL zu starten.

Weitere Informationen zu node inspect finden Sie in der Dokumentation zum Debugger.

Programmeinstiegspunkt

Der Programmeinstiegspunkt ist eine spezifiziererähnliche Zeichenkette. Wenn die Zeichenkette kein absoluter Pfad ist, wird sie als relativer Pfad aus dem aktuellen Arbeitsverzeichnis aufgelöst. Dieser Pfad wird dann vom CommonJS-Modul-Loader aufgelöst. Wenn keine entsprechende Datei gefunden wird, wird ein Fehler ausgegeben.

Wenn eine Datei gefunden wird, wird ihr Pfad unter den folgenden Bedingungen an den ES-Modul-Loader übergeben:

• Das Programm wurde mit einer Befehlszeilenoption gestartet, die erzwingt, dass der Einstiegspunkt mit dem ECMAScript-Modul-Loader geladen wird, z. B. --import.
• Die Datei hat die Erweiterung .mjs.
• Die Datei hat keine Erweiterung .cjs, und die nächste übergeordnete package.json-Datei enthält ein oberstes Feld "type" mit dem Wert "module".

Andernfalls wird die Datei mit dem CommonJS-Modul-Loader geladen. Weitere Informationen finden Sie unter Modul-Loader.

Einschränkung des ECMAScript-Modul-Loaders beim Einstiegspunkt

Beim Laden lädt der ES-Modul-Loader den Programmeinstiegspunkt. Der node-Befehl akzeptiert als Eingabe nur Dateien mit den Erweiterungen .js, .mjs oder .cjs; und mit .wasm-Erweiterungen, wenn --experimental-wasm-modules aktiviert ist.

Optionen

[Verlauf]

Version	Änderungen
v10.12.0	Unterstriche anstelle von Bindestrichen sind jetzt neben V8-Optionen auch für Node.js-Optionen zulässig.

Alle Optionen, einschließlich V8-Optionen, erlauben die Trennung von Wörtern durch Bindestriche (-) oder Unterstriche (_). Beispielsweise ist --pending-deprecation äquivalent zu --pending_deprecation.

Wenn eine Option, die einen einzelnen Wert benötigt (z. B. --max-http-header-size), mehr als einmal übergeben wird, wird der zuletzt übergebene Wert verwendet. Optionen aus der Befehlszeile haben Vorrang vor Optionen, die über die Umgebungsvariable NODE_OPTIONS übergeben werden.

-

Hinzugefügt in: v8.0.0

Alias für stdin. Analog zur Verwendung von - in anderen Befehlszeilen-Dienstprogrammen, d.h. das Skript wird von stdin gelesen und die restlichen Optionen werden an dieses Skript übergeben.

--

Hinzugefügt in: v6.11.0

Gibt das Ende der Node-Optionen an. Die restlichen Argumente werden an das Skript übergeben. Wenn vorher kein Skript-Dateiname oder eval/print-Skript angegeben wurde, wird das nächste Argument als Skript-Dateiname verwendet.

--abort-on-uncaught-exception

Hinzugefügt in: v0.10.8

Abbruch statt Beenden führt dazu, dass eine Core-Datei für die Post-Mortem-Analyse mit einem Debugger (wie lldb, gdb und mdb) generiert wird.

Wenn diese Flagge übergeben wird, kann das Verhalten dennoch so eingestellt werden, dass kein Abbruch erfolgt, und zwar durch process.setUncaughtExceptionCaptureCallback() (und durch die Verwendung des node:domain-Moduls, das dies verwendet).

--allow-addons

Hinzugefügt in: v21.6.0, v20.12.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Bei Verwendung des Berechtigungsmodells kann der Prozess standardmäßig keine nativen Addons verwenden. Versuche, dies zu tun, lösen einen ERR_DLOPEN_DISABLED aus, es sei denn, der Benutzer übergibt explizit die Flagge --allow-addons, wenn Node.js gestartet wird.

Beispiel:

// Versuch, ein natives Addon zu requiren
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

Hinzugefügt in: v20.0.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Bei Verwendung des Berechtigungsmodells kann der Prozess standardmäßig keine untergeordneten Prozesse erzeugen. Versuche, dies zu tun, lösen einen ERR_ACCESS_DENIED aus, es sei denn, der Benutzer übergibt explizit das Flag --allow-child-process, wenn Node.js gestartet wird.

Beispiel:

const childProcess = require('node:child_process')
// Versuch, die Berechtigung zu umgehen
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

[Verlauf]

Version	Änderungen
v23.5.0	Berechtigungsmodell und --allow-fs-Flags sind stabil.
v20.7.0	Durch Kommata (,) getrennte Pfade sind nicht mehr zulässig.
v20.0.0	Hinzugefügt in: v20.0.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil.

Dieses Flag konfiguriert die Dateisystem-Lese-Berechtigungen unter Verwendung des Berechtigungsmodells.

Die gültigen Argumente für das Flag --allow-fs-read sind:

• * - Um alle FileSystemRead-Operationen zuzulassen.
• Mehrere Pfade können mit mehreren --allow-fs-read-Flags zugelassen werden. Beispiel --allow-fs-read=/folder1/ --allow-fs-read=/folder1/

Beispiele finden Sie in der Dokumentation zu Dateisystemberechtigungen.

Das Initialisierungsmodul muss ebenfalls zugelassen werden. Betrachten Sie das folgende Beispiel:

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

Der Prozess muss Zugriff auf das Modul index.js haben:

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

--allow-fs-write

[Verlauf]

Version	Änderungen
v23.5.0	Berechtigungmodell und --allow-fs-Flags sind stabil.
v20.7.0	Durch Kommata (,) getrennte Pfade sind nicht mehr zulässig.
v20.0.0	Hinzugefügt in: v20.0.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil.

Dieses Flag konfiguriert die Dateisystem-Schreibberechtigungen mithilfe des Berechtigungsmusters.

Die gültigen Argumente für das Flag --allow-fs-write sind:

• * - Um alle FileSystemWrite-Operationen zuzulassen.
• Mehrere Pfade können mit mehreren --allow-fs-write-Flags zugelassen werden. Beispiel --allow-fs-write=/folder1/ --allow-fs-write=/folder1/

Durch Kommata (,) getrennte Pfade sind nicht mehr zulässig. Bei der Übergabe eines einzelnen Flags mit einem Komma wird eine Warnung angezeigt.

Beispiele finden Sie in der Dokumentation zu Dateisystemberechtigungen.

--allow-wasi

Hinzugefügt in: v22.3.0, v20.16.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Bei Verwendung des Berechtigungsmusters kann der Prozess standardmäßig keine WASI-Instanzen erstellen. Aus Sicherheitsgründen löst der Aufruf einen ERR_ACCESS_DENIED aus, es sei denn, der Benutzer übergibt explizit das Flag --allow-wasi im Haupt-Node.js-Prozess.

Beispiel:

const { WASI } = require('node:wasi')
// Versuch, die Berechtigung zu umgehen
new WASI({
  version: 'preview1',
  // Versuch, das gesamte Dateisystem zu mounten
  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

Hinzugefügt in: v20.0.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Bei Verwendung des Berechtigungsmusters kann der Prozess standardmäßig keine Worker-Threads erstellen. Aus Sicherheitsgründen löst der Aufruf einen ERR_ACCESS_DENIED aus, es sei denn, der Benutzer übergibt explizit das Flag --allow-worker im Haupt-Node.js-Prozess.

Beispiel:

const { Worker } = require('node:worker_threads')
// Versuch, die Berechtigung zu umgehen
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

Hinzugefügt in: v18.8.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Generiert beim Beenden des Prozesses einen Snapshot-Blob und schreibt ihn auf die Festplatte. Dieser kann später mit --snapshot-blob geladen werden.

Wenn der Snapshot erstellt wird und --snapshot-blob nicht angegeben ist, wird der generierte Blob standardmäßig in snapshot.blob im aktuellen Arbeitsverzeichnis geschrieben. Andernfalls wird er an den von --snapshot-blob angegebenen Pfad geschrieben.

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

# Führt snapshot.js aus, um die Anwendung zu initialisieren und den {#run-snapshotjs-to-initialize-the-application-and-snapshot-the}
# Zustand in snapshot.blob zu speichern.
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js

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

# Lädt den generierten Snapshot und startet die Anwendung von index.js. {#state-of-it-into-snapshotblob}
$ node --snapshot-blob snapshot.blob index.js
I am from the snapshot

Die v8.startupSnapshot API kann verwendet werden, um einen Einstiegspunkt bei der Snapshot-Erstellung anzugeben und so ein zusätzliches Einstiegsskript bei der Deserialisierung zu vermeiden:

$ 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

Weitere Informationen finden Sie in der Dokumentation zur v8.startupSnapshot API.

Derzeit ist die Unterstützung für Laufzeit-Snapshots experimentell, da:

--build-snapshot-config

Hinzugefügt in: v21.6.0, v20.12.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Gibt den Pfad zu einer JSON-Konfigurationsdatei an, die das Verhalten der Snapshot-Erstellung konfiguriert.

Die folgenden Optionen werden derzeit unterstützt:

• builder <string> Erforderlich. Stellt den Namen des Skripts bereit, das vor dem Erstellen des Snapshots ausgeführt wird, als ob --build-snapshot mit builder als Haupt skriptnamen übergeben worden wäre.
• withoutCodeCache <boolean> Optional. Das Einschließen des Code-Caches verkürzt die Zeit für das Kompilieren von Funktionen, die im Snapshot enthalten sind, auf Kosten einer größeren Snapshot-Größe und einer möglicherweise eingeschränkten Portabilität des Snapshots.

Bei Verwendung dieses Flags werden zusätzliche Skriptdateien, die in der Befehlszeile angegeben sind, nicht ausgeführt und stattdessen als reguläre Befehlszeilenargumente interpretiert.

-c, --check

[Historie]

Version	Änderungen
v10.0.0	Die Option --require wird jetzt beim Überprüfen einer Datei unterstützt.
v5.0.0, v4.2.0	Hinzugefügt in: v5.0.0, v4.2.0

Syntaxprüfung des Skripts ohne Ausführung.

--completion-bash

Hinzugefügt in: v10.12.0

Gibt ein ausführbares Bash-Completion-Skript für Node.js aus.

node --completion-bash > node_bash_completion
source node_bash_completion

-C condition, --conditions=condition

[Historie]

Version	Änderungen
v22.9.0, v20.18.0	Das Flag ist nicht mehr experimentell.
v14.9.0, v12.19.0	Hinzugefügt in: v14.9.0, v12.19.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Stellt benutzerdefinierte Bedingungen für die Auflösung von bedingten Exporten bereit.

Beliebig viele benutzerdefinierte Zeichenfolgenbedingungsnamen sind zulässig.

Die Standardbedingungen von Node.js, "node", "default", "import" und "require", werden immer wie definiert angewendet.

Um beispielsweise ein Modul mit "development"-Auflösungen auszuführen:

node -C development app.js

--cpu-prof

[Historie]

Version	Änderungen
v22.4.0, v20.16.0	Die Flags --cpu-prof sind jetzt stabil.
v12.0.0	Hinzugefügt in: v12.0.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Startet den V8 CPU-Profiler beim Start und schreibt das CPU-Profil vor dem Beenden auf die Festplatte.

Wenn --cpu-prof-dir nicht angegeben ist, wird das generierte Profil im aktuellen Arbeitsverzeichnis abgelegt.

Wenn --cpu-prof-name nicht angegeben ist, wird das generierte Profil mit CPU.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.cpuprofile benannt.

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

--cpu-prof-dir

[Historie]

Version	Änderungen
v22.4.0, v20.16.0	Die Flags --cpu-prof sind jetzt stabil.
v12.0.0	Hinzugefügt in: v12.0.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Gibt das Verzeichnis an, in dem die von --cpu-prof generierten CPU-Profile abgelegt werden.

Der Standardwert wird durch die Befehlszeilenoption --diagnostic-dir gesteuert.

--cpu-prof-interval

[Historie]

Version	Änderungen
v22.4.0, v20.16.0	Die --cpu-prof Flags sind nun stabil.
v12.2.0	Hinzugefügt in: v12.2.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Gibt das Abtastintervall in Mikrosekunden für die von --cpu-prof generierten CPU-Profile an. Der Standardwert ist 1000 Mikrosekunden.

--cpu-prof-name

[Historie]

Version	Änderungen
v22.4.0, v20.16.0	Die --cpu-prof Flags sind nun stabil.
v12.0.0	Hinzugefügt in: v12.0.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Gibt den Dateinamen des von --cpu-prof generierten CPU-Profils an.

--diagnostic-dir=verzeichnis

Legt das Verzeichnis fest, in das alle Diagnosedateien geschrieben werden. Standardmäßig ist dies das aktuelle Arbeitsverzeichnis.

Betrifft das Standardausgabeverzeichnis von:

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

--disable-proto=modus

Hinzugefügt in: v13.12.0, v12.17.0

Deaktiviert die Eigenschaft Object.prototype.__proto__. Wenn modus delete ist, wird die Eigenschaft vollständig entfernt. Wenn modus throw ist, lösen Zugriffe auf die Eigenschaft eine Ausnahme mit dem Code ERR_PROTO_ACCESS aus.

--disable-warning=code-oder-typ

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Hinzugefügt in: v21.3.0, v20.11.0

Deaktiviert spezifische Prozesswarnungen nach code oder type.

Warnungen, die von process.emitWarning() ausgegeben werden, können einen code und einen type enthalten. Diese Option gibt keine Warnungen aus, die einen übereinstimmenden code oder type haben.

Liste der Veraltungswarnungen.

Die Node.js Core-Warnungstypen sind: DeprecationWarning und ExperimentalWarning

Beispielsweise gibt das folgende Skript DEP0025 require('node:sys') nicht aus, wenn es mit node --disable-warning=DEP0025 ausgeführt wird:

ESM

import sys from 'node:sys'

CJS

const sys = require('node:sys')

Beispielsweise gibt das folgende Skript DEP0025 require('node:sys') aus, aber keine experimentellen Warnungen (wie z. B. ExperimentalWarning: vm.measureMemory ist eine experimentelle Funktion in <=v21), wenn es mit node --disable-warning=ExperimentalWarning ausgeführt wird:

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

Hinzugefügt in: v22.2.0, v20.15.0

Standardmäßig aktiviert Node.js trap-handler-basierte WebAssembly-Grenzenprüfungen. Dadurch muss V8 keine Inline-Grenzenprüfungen in den aus WebAssembly kompilierten Code einfügen, was die WebAssembly-Ausführung deutlich beschleunigen kann. Diese Optimierung erfordert jedoch die Zuweisung eines großen virtuellen Speicherbereichs (derzeit 10 GB). Wenn der Node.js-Prozess aufgrund von Systemkonfigurationen oder Hardwarebeschränkungen keinen Zugriff auf einen ausreichend großen virtuellen Adressraum hat, können Benutzer kein WebAssembly ausführen, das Zuweisungen in diesem virtuellen Speicherbereich beinhaltet, und erhalten eine Out-of-Memory-Fehlermeldung.

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

RangeError: WebAssembly.Memory(): could not allocate memory
    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 deaktiviert diese Optimierung, sodass Benutzer WebAssembly zumindest (mit geringerer Leistung) ausführen können, wenn der dem Node.js-Prozess zur Verfügung stehende virtuelle Adressraum kleiner ist als der vom V8 WebAssembly-Speicherbereich benötigte.

--disallow-code-generation-from-strings

Hinzugefügt in: v9.8.0

Verursacht, dass integrierte Sprachfunktionen wie eval und new Function, die Code aus Strings generieren, stattdessen eine Ausnahme auslösen. Dies betrifft nicht das Node.js node:vm Modul.

--dns-result-order=order

[Historie]

Version	Änderungen
v22.1.0, v20.13.0	ipv6first wird jetzt unterstützt.
v17.0.0	Standardwert auf verbatim geändert.
v16.4.0, v14.18.0	Hinzugefügt in: v16.4.0, v14.18.0

Legt den Standardwert von order in dns.lookup() und dnsPromises.lookup() fest. Der Wert kann sein:

• ipv4first: setzt den Standardwert von order auf ipv4first.
• ipv6first: setzt den Standardwert von order auf ipv6first.
• verbatim: setzt den Standardwert von order auf verbatim.

Der Standardwert ist verbatim und dns.setDefaultResultOrder() hat eine höhere Priorität als --dns-result-order.

--enable-fips

Hinzugefügt in: v6.0.0

Aktiviert FIPS-konforme Kryptografie beim Start. (Erfordert, dass Node.js gegen ein FIPS-kompatibles OpenSSL gebaut wurde.)

--enable-network-family-autoselection

Hinzugefügt in: v18.18.0

Aktiviert den Algorithmus zur automatischen Familienauswahl, es sei denn, Verbindungsoptionen deaktivieren ihn explizit.

--enable-source-maps

[Verlauf]

Version	Änderungen
v15.11.0, v14.18.0	Diese API ist nicht mehr experimentell.
v12.12.0	Hinzugefügt in: v12.12.0

Aktiviert die Unterstützung für Source Map v3 für Stack Traces.

Bei Verwendung eines Transpilers wie TypeScript verweisen Stack Traces, die von einer Anwendung ausgelöst werden, auf den transpilieren Code und nicht auf die ursprüngliche Quellposition. --enable-source-maps aktiviert das Caching von Source Maps und unternimmt einen bestmöglichen Versuch, Stack Traces relativ zur ursprünglichen Quelldatei zu melden.

Das Überschreiben von Error.prepareStackTrace kann verhindern, dass --enable-source-maps den Stack Trace modifiziert. Rufen Sie die Ergebnisse des ursprünglichen Error.prepareStackTrace in der überschreibenden Funktion auf und geben Sie sie zurück, um den Stack Trace mit Source Maps zu modifizieren.

const originalPrepareStackTrace = Error.prepareStackTrace
Error.prepareStackTrace = (error, trace) => {
  // Fehler und Trace modifizieren und Stack Trace mit
  // original Error.prepareStackTrace formatieren.
  return originalPrepareStackTrace(error, trace)
}

Beachten Sie, dass das Aktivieren von Source Maps zu Latenz in Ihrer Anwendung führen kann, wenn auf Error.stack zugegriffen wird. Wenn Sie häufig auf Error.stack in Ihrer Anwendung zugreifen, berücksichtigen Sie die Performance-Auswirkungen von --enable-source-maps.

--entry-url

Hinzugefügt in: v23.0.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Wenn vorhanden, interpretiert Node.js den Einstiegspunkt als URL und nicht als Pfad.

Befolgt die Auflösungsregeln für ECMAScript-Module.

Jeder Query-Parameter oder Hash in der URL ist über import.meta.url zugänglich.

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

Hinzugefügt in: v22.9.0

Das Verhalten ist identisch mit --env-file, aber es wird kein Fehler ausgegeben, wenn die Datei nicht existiert.

--env-file=config

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

[Verlauf]

Version	Änderungen
v21.7.0, v20.12.0	Unterstützung für mehrzeilige Werte hinzugefügt.
v20.6.0	Hinzugefügt in: v20.6.0

Lädt Umgebungsvariablen aus einer Datei relativ zum aktuellen Verzeichnis und stellt sie Anwendungen in process.env zur Verfügung. Die Umgebungsvariablen, die Node.js konfigurieren, wie z. B. NODE_OPTIONS, werden analysiert und angewendet. Wenn dieselbe Variable sowohl in der Umgebung als auch in der Datei definiert ist, hat der Wert aus der Umgebung Vorrang.

Sie können mehrere --env-file-Argumente übergeben. Nachfolgende Dateien überschreiben bereits vorhandene Variablen, die in vorherigen Dateien definiert wurden.

Es wird ein Fehler ausgegeben, wenn die Datei nicht existiert.

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

Das Format der Datei sollte eine Zeile pro Schlüssel-Wert-Paar aus Umgebungsvariablennamen und Wert sein, getrennt durch =:

PORT=3000

Jeder Text nach einem # wird als Kommentar behandelt:

# Dies ist ein Kommentar {#--env-file=config}
PORT=3000 # Dies ist auch ein Kommentar

Werte können mit folgenden Anführungszeichen beginnen und enden: ```, "oder'. Sie werden aus den Werten entfernt.

USERNAME="nodejs" # ergibt `nodejs` als Wert.

Mehrzeilige Werte werden unterstützt:

MULTI_LINE="DAS IST
EIN MEHRZEILER"
# ergibt `DAS IST\nEIN MEHRZEILER` als Wert. {#this-is-a-comment}

Das Schlüsselwort export vor einem Schlüssel wird ignoriert:

export USERNAME="nodejs" # ergibt `nodejs` als Wert.

Wenn Sie Umgebungsvariablen aus einer Datei laden möchten, die möglicherweise nicht existiert, können Sie stattdessen das Flag --env-file-if-exists verwenden.

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

[Verlauf]

Version	Änderungen
v22.6.0	Eval unterstützt jetzt experimentelles Typreduzieren.
v5.11.0	Eingebaute Bibliotheken sind jetzt als vordefinierte Variablen verfügbar.
v0.5.2	Hinzugefügt in: v0.5.2

Wertet das folgende Argument als JavaScript aus. Die im REPL vordefinierten Module können auch in script verwendet werden.

Unter Windows funktioniert die Verwendung von cmd.exe mit einem einfachen Anführungszeichen nicht korrekt, da es nur doppelte Anführungszeichen " zum Zitieren erkennt. In Powershell oder Git Bash sind sowohl ' als auch " verwendbar.

Es ist möglich, Code mit Inline-Typen auszuführen, indem --experimental-strip-types übergeben wird.

--experimental-async-context-frame

Hinzugefügt in: v22.7.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Aktiviert die Verwendung von AsyncLocalStorage, das auf AsyncContextFrame basiert, anstatt der Standardimplementierung, die auf async_hooks basiert. Dieses neue Modell ist sehr unterschiedlich implementiert und kann daher Unterschiede in der Art und Weise aufweisen, wie Kontextdaten innerhalb der Anwendung fließen. Daher wird derzeit empfohlen, sicherzustellen, dass das Verhalten Ihrer Anwendung durch diese Änderung nicht beeinträchtigt wird, bevor Sie sie in der Produktion verwenden.

--experimental-eventsource

Hinzugefügt in: v22.3.0, v20.18.0

Aktiviert die Darstellung der EventSource Web API im globalen Scope.

--experimental-import-meta-resolve

[Verlauf]

Version	Änderungen
v20.6.0, v18.19.0	synchrones import.meta.resolve standardmäßig verfügbar, wobei das Flag beibehalten wird, um das experimentelle zweite Argument wie zuvor unterstützt zu aktivieren.
v13.9.0, v12.16.2	Hinzugefügt in: v13.9.0, v12.16.2

Aktiviert die experimentelle Unterstützung für import.meta.resolve()-Parent-URL, die das Übergeben eines zweiten parentURL-Arguments für die kontextbezogene Auflösung ermöglicht.

Zuvor wurde die gesamte import.meta.resolve-Funktion eingeschränkt.

--experimental-loader=module

[Historie]

Version	Änderungen
v12.11.1	Dieses Flag wurde von --loader in --experimental-loader umbenannt.
v8.8.0	Hinzugefügt in: v8.8.0

Gibt das module an, das exportierte Module-Anpassungshooks enthält. module kann eine beliebige Zeichenkette sein, die als import-Spezifizierer akzeptiert wird.

--experimental-network-inspection

Hinzugefügt in: v22.6.0, v20.18.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Aktiviert experimentelle Unterstützung für die Netzwerkprüfung mit Chrome DevTools.

--experimental-print-required-tla

Hinzugefügt in: v22.0.0, v20.17.0

Wenn das require()-te ES-Modul Top-Level await enthält, ermöglicht dieses Flag Node.js, das Modul auszuwerten, zu versuchen, die Top-Level-Awaits zu finden und deren Position zu drucken, um Benutzern bei der Suche zu helfen.

--experimental-require-module

[Historie]

Version	Änderungen
v23.0.0	Dies ist jetzt standardmäßig aktiviert.
v22.0.0, v20.17.0	Hinzugefügt in: v22.0.0, v20.17.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Unterstützt das Laden eines synchronen ES-Modul-Graphen in require().

Siehe Laden von ECMAScript-Modulen mit require().

--experimental-sea-config

Hinzugefügt in: v20.0.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Verwenden Sie dieses Flag, um einen Blob zu generieren, der in die Node.js-Binärdatei injiziert werden kann, um eine Single Executable Application zu erstellen. Einzelheiten finden Sie in der Dokumentation zu dieser Konfiguration.

--experimental-shadow-realm

Hinzugefügt in: v19.0.0, v18.13.0

Verwenden Sie dieses Flag, um die Unterstützung von ShadowRealm zu aktivieren.

--experimental-strip-types

Hinzugefügt in: v22.6.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Aktiviert das experimentelle Typ-Stripping für TypeScript-Dateien. Weitere Informationen finden Sie in der Dokumentation zum TypeScript Typ-Stripping.

--experimental-test-coverage

[Verlauf]

Version	Änderungen
v20.1.0, v18.17.0	Diese Option kann mit --test verwendet werden.
v19.7.0, v18.15.0	Hinzugefügt in: v19.7.0, v18.15.0

Wird in Verbindung mit dem Modul node:test verwendet, wird ein Code-Coverage-Bericht als Teil der Ausgabe des Testlaufs generiert. Wenn keine Tests ausgeführt werden, wird kein Coverage-Bericht generiert. Weitere Informationen finden Sie in der Dokumentation zum Sammeln von Code-Coverage aus Tests.

--experimental-test-isolation=mode

Hinzugefügt in: v22.8.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.0 - Frühe Entwicklung

Konfiguriert den Typ der Test-Isolation, die im Testläufer verwendet wird. Wenn mode 'process' ist, wird jede Testdatei in einem separaten Child-Prozess ausgeführt. Wenn mode 'none' ist, werden alle Testdateien im selben Prozess wie der Testläufer ausgeführt. Der Standard-Isolationsmodus ist 'process'. Dieses Flag wird ignoriert, wenn das Flag --test nicht vorhanden ist. Weitere Informationen finden Sie im Abschnitt Ausführungsmodell des Testläufers.

--experimental-test-module-mocks

Hinzugefügt in: v22.3.0, v20.18.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.0 - Frühe Entwicklung

Aktiviert das Modul-Mocking im Testläufer.

--experimental-transform-types

Hinzugefügt in: v22.7.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Aktiviert die Transformation von rein TypeScript-Syntax in JavaScript-Code. Impliziert --experimental-strip-types und --enable-source-maps.

--experimental-vm-modules

Hinzugefügt in: v9.6.0

Aktiviert experimentelle ES-Modul-Unterstützung im node:vm-Modul.

--experimental-wasi-unstable-preview1

[Verlauf]

Version	Änderungen
v20.0.0, v18.17.0	Diese Option ist nicht mehr erforderlich, da WASI standardmäßig aktiviert ist, kann aber dennoch übergeben werden.
v13.6.0	geändert von --experimental-wasi-unstable-preview0 zu --experimental-wasi-unstable-preview1.
v13.3.0, v12.16.0	Hinzugefügt in: v13.3.0, v12.16.0

Aktiviert experimentelle Unterstützung für die WebAssembly System Interface (WASI).

--experimental-wasm-modules

Hinzugefügt in: v12.3.0

Aktiviert experimentelle Unterstützung für WebAssembly-Module.

--experimental-webstorage

Hinzugefügt in: v22.4.0

Aktiviert experimentelle Unterstützung für Web Storage.

--expose-gc

Hinzugefügt in: v22.3.0, v20.18.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell. Dieses Flag wird von V8 geerbt und kann sich upstream ändern.

Dieses Flag macht die gc-Erweiterung von V8 verfügbar.

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

--force-context-aware

Hinzugefügt in: v12.12.0

Deaktiviert das Laden von nativen Addons, die nicht kontextbewusst sind.

--force-fips

Hinzugefügt in: v6.0.0

Erzwingt FIPS-konforme Kryptografie beim Start. (Kann nicht über Skriptcode deaktiviert werden.) (Gleiche Anforderungen wie --enable-fips.)

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

Hinzugefügt in: v18.3.0, v16.17.0

Erzwingt das uncaughtException-Ereignis bei asynchronen Node-API-Callbacks.

Um zu verhindern, dass ein bestehendes Add-on den Prozess zum Absturz bringt, ist dieses Flag standardmäßig nicht aktiviert. In Zukunft wird dieses Flag standardmäßig aktiviert, um das korrekte Verhalten zu erzwingen.

--frozen-intrinsics

Hinzugefügt in: v11.12.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Aktiviert experimentelle gefrorene Intrinsics wie Array und Object.

Nur der Root-Kontext wird unterstützt. Es gibt keine Garantie dafür, dass globalThis.Array tatsächlich die Standard-Intrinsic-Referenz ist. Der Code kann unter diesem Flag fehlerhaft sein.

Um das Hinzufügen von Polyfills zu ermöglichen, werden --require und --import beide vor dem Einfrieren von Intrinsics ausgeführt.

--heap-prof

[Verlauf]

Version	Änderungen
v22.4.0, v20.16.0	Die --heap-prof Flags sind jetzt stabil.
v12.4.0	Hinzugefügt in: v12.4.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Startet den V8-Heap-Profiler beim Start und schreibt das Heap-Profil vor dem Beenden auf die Festplatte.

Wenn --heap-prof-dir nicht angegeben ist, wird das generierte Profil im aktuellen Arbeitsverzeichnis abgelegt.

Wenn --heap-prof-name nicht angegeben ist, wird das generierte Profil mit Heap.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.heapprofile benannt.

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

--heap-prof-dir

[Verlauf]

Version	Änderungen
v22.4.0, v20.16.0	Die --heap-prof Flags sind jetzt stabil.
v12.4.0	Hinzugefügt in: v12.4.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Gibt das Verzeichnis an, in dem die von --heap-prof generierten Heap-Profile abgelegt werden.

Der Standardwert wird durch die Befehlszeilenoption --diagnostic-dir gesteuert.

--heap-prof-interval

[Verlauf]

Version	Änderungen
v22.4.0, v20.16.0	Die --heap-prof Flags sind jetzt stabil.
v12.4.0	Hinzugefügt in: v12.4.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Gibt das durchschnittliche Stichprobenintervall in Bytes für die von --heap-prof generierten Heap-Profile an. Der Standardwert beträgt 512 * 1024 Bytes.

--heap-prof-name

[Historie]

Version	Änderungen
v22.4.0, v20.16.0	Die --heap-prof Flags sind nun stabil.
v12.4.0	Hinzugefügt in: v12.4.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Gibt den Dateinamen des von --heap-prof generierten Heapprofils an.

--heapsnapshot-near-heap-limit=max_count

Hinzugefügt in: v15.1.0, v14.18.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Schreibt eine V8-Heapsnapshot auf die Festplatte, wenn die V8-Heap-Auslastung sich dem Heap-Limit nähert. count sollte eine nicht-negative ganze Zahl sein (in diesem Fall schreibt Node.js nicht mehr als max_count Snapshots auf die Festplatte).

Bei der Generierung von Snapshots kann eine Garbage Collection ausgelöst werden und die Heapauslastung senken. Daher können mehrere Snapshots auf die Festplatte geschrieben werden, bevor die Node.js-Instanz schließlich den Speicherplatz aufbraucht. Diese Heapsnapshots können verglichen werden, um zu bestimmen, welche Objekte während der Zeit, in der aufeinanderfolgende Snapshots aufgenommen werden, zugeordnet werden. Es ist nicht garantiert, dass Node.js genau max_count Snapshots auf die Festplatte schreibt, aber es wird sein Bestes tun, um mindestens einen und bis zu max_count Snapshots zu generieren, bevor die Node.js-Instanz den Speicherplatz aufbraucht, wenn max_count größer als 0 ist.

Das Generieren von V8-Snapshots benötigt Zeit und Speicher (sowohl Speicher, der vom V8-Heap verwaltet wird, als auch nativer Speicher außerhalb des V8-Heaps). Je größer der Heap ist, desto mehr Ressourcen benötigt er. Node.js passt den V8-Heap an, um den zusätzlichen V8-Heap-Speicheraufwand zu berücksichtigen, und versucht sein Bestes, um zu vermeiden, dass der gesamte dem Prozess zur Verfügung stehende Speicher verbraucht wird. Wenn der Prozess mehr Speicher verwendet, als das System für angemessen hält, kann der Prozess je nach Systemkonfiguration abrupt vom System beendet werden.

$ node --max-old-space-size=100 --heapsnapshot-near-heap-limit=3 index.js
Wrote snapshot to Heap.20200430.100036.49580.0.001.heapsnapshot
Wrote snapshot to Heap.20200430.100037.49580.0.002.heapsnapshot
Wrote snapshot to Heap.20200430.100038.49580.0.003.heapsnapshot

<--- Last few GCs --->

[49580:0x110000000]     4826 ms: Mark-sweep 130.6 (147.8) -> 130.5 (147.8) MB, 27.4 / 0.0 ms  (average mu = 0.126, current mu = 0.034) allocation failure scavenge might not succeed
[49580:0x110000000]     4845 ms: Mark-sweep 130.6 (147.8) -> 130.6 (147.8) MB, 18.8 / 0.0 ms  (average mu = 0.088, current mu = 0.031) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
....

--heapsnapshot-signal=signal

Hinzugefügt in: v12.0.0

Aktiviert einen Signalhandler, der den Node.js-Prozess dazu bringt, einen Heapdump zu schreiben, wenn das angegebene Signal empfangen wird. signal muss ein gültiger Signalname sein. Standardmäßig deaktiviert.

$ 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

Hinzugefügt in: v0.1.3

Gibt Node-Befehlszeilenoptionen aus. Die Ausgabe dieser Option ist weniger detailliert als dieses Dokument.

--icu-data-dir=file

Hinzugefügt in: v0.11.15

Gibt den Ladepfad für ICU-Daten an. (Überschreibt NODE_ICU_DATA.)

--import=module

Hinzugefügt in: v19.0.0, v18.18.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Lädt das angegebene Modul beim Start vor. Wenn das Flag mehrmals angegeben wird, wird jedes Modul sequenziell in der Reihenfolge ihrer Angabe ausgeführt, beginnend mit den in NODE_OPTIONS angegebenen.

Befolgt die Auflösungsregeln für ECMAScript-Module. Verwenden Sie --require, um ein CommonJS-Modul zu laden. Module, die mit --require geladen werden, werden vor Modulen ausgeführt, die mit --import geladen werden.

Module werden sowohl in den Hauptthread als auch in alle Worker-Threads, geforkten Prozesse oder geclusterten Prozesse geladen.

--input-type=type

Hinzugefügt in: v12.0.0

Dies konfiguriert Node.js, um --eval- oder STDIN-Eingaben als CommonJS oder als ES-Modul zu interpretieren. Gültige Werte sind "commonjs" oder "module". Der Standardwert ist "commonjs".

Die REPL unterstützt diese Option nicht. Die Verwendung von --input-type=module mit --print löst einen Fehler aus, da --print die ES-Modulsyntax nicht unterstützt.

--insecure-http-parser

Hinzugefügt in: v13.4.0, v12.15.0, v10.19.0

Aktiviert Nachsichtigkeitsflags im HTTP-Parser. Dies kann die Interoperabilität mit nicht-konformen HTTP-Implementierungen ermöglichen.

Bei Aktivierung akzeptiert der Parser Folgendes:

• Ungültige HTTP-Header-Werte.
• Ungültige HTTP-Versionen.
• Zulassen von Nachrichten, die sowohl Transfer-Encoding als auch Content-Length-Header enthalten.
• Zulassen zusätzlicher Daten nach der Nachricht, wenn Connection: close vorhanden ist.
• Zulassen zusätzlicher Transfer-Codierungen, nachdem chunked bereitgestellt wurde.
• Zulassen von \n als Token-Trennzeichen anstelle von \r\n.
• Zulassen, dass \r\n nach einem Chunk nicht bereitgestellt wird.
• Zulassen von Leerzeichen nach einer Chunk-Größe und vor \r\n.

All dies setzt Ihre Anwendung Angriffen durch Request Smuggling oder Poisoning aus. Vermeiden Sie die Verwendung dieser Option.

Warnung: Das Binden des Inspectors an eine öffentliche IP:Port-Kombination ist unsicher

Das Binden des Inspectors an eine öffentliche IP (einschließlich 0.0.0.0) mit einem offenen Port ist unsicher, da es externen Hosts ermöglicht, sich mit dem Inspector zu verbinden und einen Remote Code Execution-Angriff durchzuführen.

Wenn Sie einen Host angeben, stellen Sie sicher, dass entweder:

• Der Host nicht von öffentlichen Netzwerken erreichbar ist.
• Eine Firewall unerwünschte Verbindungen an dem Port verbietet.

Genauer gesagt, ist --inspect=0.0.0.0 unsicher, wenn der Port (standardmäßig 9229) nicht durch eine Firewall geschützt ist.

Weitere Informationen finden Sie im Abschnitt Sicherheitsaspekte des Debuggens.

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

Hinzugefügt in: v7.6.0

Aktiviert den Inspector auf host:port und unterbricht beim Start des Benutzerskripts. Standardmäßig ist host:port 127.0.0.1:9229. Wenn Port 0 angegeben ist, wird ein zufälliger verfügbarer Port verwendet.

Weitere Erklärungen zum Node.js-Debugger finden Sie unter V8 Inspector-Integration für Node.js.

--inspect-port=[host:]port

Hinzugefügt in: v7.6.0

Legt den host:port fest, der verwendet werden soll, wenn der Inspector aktiviert ist. Nützlich, wenn der Inspector durch Senden des SIGUSR1-Signals aktiviert wird.

Der Standardhost ist 127.0.0.1. Wenn Port 0 angegeben ist, wird ein zufälliger verfügbarer Port verwendet.

Siehe die Sicherheitswarnung unten bezüglich der Verwendung des host-Parameters.

--inspect-publish-uid=stderr,http

Gibt die Methoden zur Offenlegung der URL des Inspector-Websockets an.

Standardmäßig ist die Inspector-Websocket-URL in stderr und unter dem Endpunkt /json/list unter http://host:port/json/list verfügbar.

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

Hinzugefügt in: v22.2.0, v20.15.0

Aktiviert den Inspector auf host:port und wartet darauf, dass der Debugger angehängt wird. Standardmäßig ist host:port 127.0.0.1:9229. Wenn Port 0 angegeben ist, wird ein zufälliger verfügbarer Port verwendet.

Siehe V8 Inspector-Integration für Node.js für weitere Erklärungen zum Node.js-Debugger.

--inspect[=[host:]port]

Hinzugefügt in: v6.3.0

Aktiviert den Inspector auf host:port. Standardmäßig ist 127.0.0.1:9229. Wenn Port 0 angegeben ist, wird ein zufälliger verfügbarer Port verwendet.

Die V8-Inspector-Integration ermöglicht es Tools wie Chrome DevTools und IDEs, Node.js-Instanzen zu debuggen und zu profilieren. Die Tools hängen sich über einen TCP-Port an Node.js-Instanzen an und kommunizieren über das Chrome DevTools Protocol. Siehe V8 Inspector-Integration für Node.js für weitere Erklärungen zum Node.js-Debugger.

-i, --interactive

Hinzugefügt in: v0.7.7

Öffnet die REPL, auch wenn stdin nicht als Terminal erscheint.

--jitless

Hinzugefügt in: v12.0.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell. Dieses Flag wird von V8 geerbt und kann sich Upstream ändern.

Deaktiviert die Laufzeitzuweisung von ausführbarem Speicher. Dies kann auf einigen Plattformen aus Sicherheitsgründen erforderlich sein. Es kann auch die Angriffsfläche auf anderen Plattformen reduzieren, aber die Auswirkungen auf die Leistung können erheblich sein.

--localstorage-file=file

Hinzugefügt in: v22.4.0

Die Datei, in der localStorage-Daten gespeichert werden. Wenn die Datei nicht existiert, wird sie beim ersten Zugriff auf localStorage erstellt. Dieselbe Datei kann von mehreren Node.js-Prozessen gleichzeitig gemeinsam genutzt werden. Dieses Flag ist ein No-Op, es sei denn, Node.js wird mit dem Flag --experimental-webstorage gestartet.

--max-http-header-size=size

[Verlauf]

Version	Änderungen
v13.13.0	Maximale Standardgröße von HTTP-Headern von 8 KiB auf 16 KiB geändert.
v11.6.0, v10.15.0	Hinzugefügt in: v11.6.0, v10.15.0

Gibt die maximale Größe von HTTP-Headern in Bytes an. Standardwert ist 16 KiB.

--napi-modules

Hinzugefügt in: v7.10.0

Diese Option ist ein No-Op. Sie wird aus Kompatibilitätsgründen beibehalten.

--network-family-autoselection-attempt-timeout

Hinzugefügt in: v22.1.0, v20.13.0

Legt den Standardwert für das Timeout beim automatischen Auswählen der Netzwerkfamilie fest. Weitere Informationen finden Sie unter net.getDefaultAutoSelectFamilyAttemptTimeout().

--no-addons

Hinzugefügt in: v16.10.0, v14.19.0

Deaktiviert die node-addons-Exportbedingung und das Laden nativer Add-ons. Wenn --no-addons angegeben ist, schlägt der Aufruf von process.dlopen oder das Anfordern eines nativen C++-Add-ons fehl und löst eine Ausnahme aus.

--no-deprecation

Hinzugefügt in: v0.8.0

Unterdrückt Deprecation-Warnungen.

--no-experimental-detect-module

[Verlauf]

Version	Änderungen
v22.7.0	Syntaxerkennung ist standardmäßig aktiviert.
v21.1.0, v20.10.0	Hinzugefügt in: v21.1.0, v20.10.0

Deaktiviert die Verwendung der Syntaxerkennung zur Bestimmung des Modultyps.

--no-experimental-global-navigator

Hinzugefügt in: v21.2.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Deaktiviert die Bereitstellung der Navigator-API im globalen Scope.

--no-experimental-repl-await

Hinzugefügt in: v16.6.0

Verwenden Sie dieses Flag, um Top-Level-await in REPL zu deaktivieren.

--no-experimental-require-module

[Verlauf]

Version	Änderungen
v23.0.0	Dies ist jetzt standardmäßig falsch.
v22.0.0, v20.17.0	Hinzugefügt in: v22.0.0, v20.17.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Deaktiviert die Unterstützung für das Laden eines synchronen ES-Modulgraphen in require().

Siehe Laden von ECMAScript-Modulen mit require().

--no-experimental-sqlite

[Historie]

Version	Änderungen
v23.4.0	SQLite ist nicht mehr gekennzeichnet, aber immer noch experimentell.
v22.5.0	Hinzugefügt in: v22.5.0

Deaktiviert das experimentelle Modul node:sqlite.

--no-experimental-websocket

Hinzugefügt in: v22.0.0

Deaktiviert die Bereitstellung von WebSocket im globalen Scope.

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

Hinzugefügt in: v17.0.0

Versteckt zusätzliche Informationen bei schwerwiegenden Ausnahmen, die zum Beenden führen.

--no-force-async-hooks-checks

Hinzugefügt in: v9.0.0

Deaktiviert Laufzeitprüfungen für async_hooks. Diese werden weiterhin dynamisch aktiviert, wenn async_hooks aktiviert ist.

--no-global-search-paths

Hinzugefügt in: v16.10.0

Sucht keine Module in globalen Pfaden wie $HOME/.node_modules und $NODE_PATH.

--no-network-family-autoselection

[Historie]

Version	Änderungen
v20.0.0	Das Flag wurde von --no-enable-network-family-autoselection in --no-network-family-autoselection umbenannt. Der alte Name funktioniert weiterhin als Alias.
v19.4.0	Hinzugefügt in: v19.4.0

Deaktiviert den Algorithmus zur automatischen Familienauswahl, es sei denn, die Verbindungsoptionen aktivieren ihn explizit.

--no-warnings

Hinzugefügt in: v6.0.0

Unterdrückt alle Prozesswarnungen (einschließlich Veralterungen).

--node-memory-debug

Hinzugefügt in: v15.0.0, v14.18.0

Aktiviert zusätzliche Debug-Prüfungen für Speicherlecks in Node.js-internen Komponenten. Dies ist normalerweise nur für Entwickler nützlich, die Node.js selbst debuggen.

--openssl-config=file

Hinzugefügt in: v6.9.0

Lädt beim Start eine OpenSSL-Konfigurationsdatei. Unter anderem kann dies verwendet werden, um FIPS-konforme Kryptografie zu aktivieren, wenn Node.js gegen ein FIPS-fähiges OpenSSL erstellt wurde.

--openssl-legacy-provider

Hinzugefügt in: v17.0.0, v16.17.0

Aktiviert den OpenSSL 3.0 Legacy-Provider. Weitere Informationen finden Sie unter OSSL_PROVIDER-legacy.

--openssl-shared-config

Hinzugefügt in: v18.5.0, v16.17.0, v14.21.0

Ermöglicht das Lesen des OpenSSL-Standardkonfigurationsabschnitts openssl_conf aus der OpenSSL-Konfigurationsdatei. Die Standardkonfigurationsdatei heißt openssl.cnf, dies kann jedoch mit der Umgebungsvariablen OPENSSL_CONF oder mit der Befehlszeilenoption --openssl-config geändert werden. Der Speicherort der Standard-OpenSSL-Konfigurationsdatei hängt davon ab, wie OpenSSL mit Node.js verknüpft wird. Das Teilen der OpenSSL-Konfiguration kann unerwünschte Auswirkungen haben. Es wird empfohlen, einen spezifischen Konfigurationsabschnitt für Node.js zu verwenden, nämlich nodejs_conf, der standardmäßig verwendet wird, wenn diese Option nicht verwendet wird.

--pending-deprecation

Hinzugefügt in: v8.0.0

Gibt Warnungen über ausstehende Deprecations aus.

Ausstehende Deprecations sind im Allgemeinen identisch mit einer Deprecation zur Laufzeit, mit der bemerkenswerten Ausnahme, dass sie standardmäßig deaktiviert sind und nicht ausgegeben werden, es sei denn, entweder die Befehlszeilenoption --pending-deprecation oder die Umgebungsvariable NODE_PENDING_DEPRECATION=1 ist gesetzt. Ausstehende Deprecations werden verwendet, um einen selektiven "Frühwarnmechanismus" bereitzustellen, den Entwickler nutzen können, um veraltete API-Verwendungen zu erkennen.

--permission

[Historie]

Version	Änderungen
v23.5.0	Das Berechtigungssystem ist nun stabil.
v20.0.0	Hinzugefügt in: v20.0.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil.

Aktiviert das Berechtigungssystem für den aktuellen Prozess. Wenn aktiviert, sind die folgenden Berechtigungen eingeschränkt:

• Dateisystem - verwaltungsbar über die Flags --allow-fs-read und --allow-fs-write
• Child-Prozesse - verwaltungsbar über das Flag --allow-child-process
• Worker-Threads - verwaltungsbar über das Flag --allow-worker
• WASI - verwaltungsbar über das Flag --allow-wasi
• Addons - verwaltungsbar über das Flag --allow-addons

--preserve-symlinks

Hinzugefügt in: v6.3.0

Weist den Modul-Loader an, symbolische Links bei der Auflösung und dem Cachen von Modulen zu erhalten.

Standardmäßig, wenn Node.js ein Modul von einem Pfad lädt, der symbolisch auf einen anderen Speicherort auf der Festplatte verweist, wird Node.js den Link auflösen und den tatsächlichen Speicherort ("real path") des Moduls sowohl als Bezeichner als auch als Root-Pfad zum Auffinden anderer abhängiger Module verwenden. In den meisten Fällen ist dieses Standardverhalten akzeptabel. Bei der Verwendung symbolisch verlinkter Peer-Abhängigkeiten, wie im folgenden Beispiel dargestellt, führt das Standardverhalten jedoch dazu, dass eine Ausnahme ausgelöst wird, wenn moduleA versucht, moduleB als Peer-Abhängigkeit zu benötigen:

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

Die Befehlszeilenoption --preserve-symlinks weist Node.js an, den Symlink-Pfad für Module anstelle des tatsächlichen Pfads zu verwenden, sodass symbolisch verlinkte Peer-Abhängigkeiten gefunden werden können.

Beachten Sie jedoch, dass die Verwendung von --preserve-symlinks andere Nebeneffekte haben kann. Insbesondere können symbolisch verlinkte native Module fehlschlagen, wenn diese von mehr als einem Ort in der Abhängigkeitsstruktur verlinkt werden (Node.js würde diese als zwei separate Module ansehen und versuchen, das Modul mehrmals zu laden, was zu einer Ausnahme führt).

Die Option --preserve-symlinks gilt nicht für das Hauptmodul, wodurch node --preserve-symlinks node_module/.bin/\<foo\> funktioniert. Um dasselbe Verhalten für das Hauptmodul anzuwenden, verwenden Sie auch --preserve-symlinks-main.

--preserve-symlinks-main

Hinzugefügt in: v10.2.0

Weist den Modul-Loader an, symbolische Links bei der Auflösung und dem Caching des Hauptmoduls (require.main) beizubehalten.

Dieses Flag existiert, damit das Hauptmodul das gleiche Verhalten wie --preserve-symlinks für alle anderen Importe erhalten kann; es sind jedoch separate Flags aus Gründen der Abwärtskompatibilität mit älteren Node.js-Versionen.

--preserve-symlinks-main impliziert nicht --preserve-symlinks; verwenden Sie --preserve-symlinks-main zusätzlich zu --preserve-symlinks, wenn es nicht erwünscht ist, symbolische Links zu verfolgen, bevor relative Pfade aufgelöst werden.

Siehe --preserve-symlinks für weitere Informationen.

-p, --print "script"

[Verlauf]

Version	Änderungen
v5.11.0	Eingebaute Bibliotheken sind jetzt als vordefinierte Variablen verfügbar.
v0.6.4	Hinzugefügt in: v0.6.4

Identisch mit -e, gibt aber das Ergebnis aus.

--prof

Hinzugefügt in: v2.0.0

Generiert V8-Profiler-Ausgabe.

--prof-process

Hinzugefügt in: v5.2.0

Verarbeitet V8-Profiler-Ausgabe, die mit der V8-Option --prof generiert wurde.

--redirect-warnings=file

Hinzugefügt in: v8.0.0

Schreibt Prozesswarnungen in die angegebene Datei, anstatt sie auf stderr auszugeben. Die Datei wird erstellt, wenn sie nicht existiert, und an sie wird angehängt, wenn sie existiert. Wenn beim Versuch, die Warnung in die Datei zu schreiben, ein Fehler auftritt, wird die Warnung stattdessen auf stderr geschrieben.

Der Dateiname kann ein absoluter Pfad sein. Wenn dies nicht der Fall ist, wird das Standardverzeichnis, in das geschrieben wird, durch die Befehlszeilenoption --diagnostic-dir gesteuert.

--report-compact

Hinzugefügt in: v13.12.0, v12.17.0

Schreibt Berichte in einem kompakten Format, als einzeiliges JSON, das von Log-Verarbeitungssystemen leichter genutzt werden kann als das standardmäßige mehrzeilige Format, das für die menschliche Lesbarkeit entwickelt wurde.

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

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese Option ist nicht mehr experimentell.
v12.0.0	Von --diagnostic-report-directory zu --report-directory geändert.
v11.8.0	Hinzugefügt in: v11.8.0

Ort, an dem der Bericht generiert wird.

--report-exclude-env

Hinzugefügt in: v23.3.0

Wenn --report-exclude-env übergeben wird, enthält der generierte Diagnosebericht keine environmentVariables-Daten.

--report-exclude-network

Hinzugefügt in: v22.0.0, v20.13.0

Schließt header.networkInterfaces aus dem Diagnosebericht aus. Standardmäßig ist diese Option nicht gesetzt und die Netzwerk-Schnittstellen werden eingeschlossen.

--report-filename=filename

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese Option ist nicht mehr experimentell.
v12.0.0	Umbenannt von --diagnostic-report-filename zu --report-filename.
v11.8.0	Hinzugefügt in: v11.8.0

Name der Datei, in die der Bericht geschrieben wird.

Wenn der Dateiname auf 'stdout' oder 'stderr' gesetzt ist, wird der Bericht entsprechend auf die stdout bzw. stderr des Prozesses geschrieben.

--report-on-fatalerror

[Verlauf]

Version	Änderungen
v14.0.0, v13.14.0, v12.17.0	Diese Option ist nicht mehr experimentell.
v12.0.0	Umbenannt von --diagnostic-report-on-fatalerror zu --report-on-fatalerror.
v11.8.0	Hinzugefügt in: v11.8.0

Aktiviert die Berichterstellung bei fatalen Fehlern (interne Fehler innerhalb der Node.js-Laufzeit, z. B. Speichermangel), die zur Beendigung der Anwendung führen. Nützlich, um verschiedene diagnostische Datenelemente wie Heap, Stack, Event-Loop-Zustand, Ressourcenverbrauch usw. zu untersuchen, um den fatalen Fehler zu analysieren.

--report-on-signal

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese Option ist nicht mehr experimentell.
v12.0.0	Umbenannt von --diagnostic-report-on-signal zu --report-on-signal.
v11.8.0	Hinzugefügt in: v11.8.0

Ermöglicht die Generierung eines Berichts nach Empfang des angegebenen (oder vordefinierten) Signals an den laufenden Node.js-Prozess. Das Signal zum Auslösen des Berichts wird über --report-signal angegeben.

--report-signal=signal

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese Option ist nicht mehr experimentell.
v12.0.0	Umbenannt von --diagnostic-report-signal zu --report-signal.
v11.8.0	Hinzugefügt in: v11.8.0

Legt das Signal für die Berichterstellung fest oder setzt es zurück (wird unter Windows nicht unterstützt). Standardsignal ist SIGUSR2.

--report-uncaught-exception

[Verlauf]

Version	Änderungen
v18.8.0, v16.18.0	Bericht wird nicht generiert, wenn die nicht abgefangene Ausnahme behandelt wird.
v13.12.0, v12.17.0	Diese Option ist nicht mehr experimentell.
v12.0.0	Umbenannt von --diagnostic-report-uncaught-exception zu --report-uncaught-exception.
v11.8.0	Hinzugefügt in: v11.8.0

Aktiviert die Generierung eines Berichts, wenn der Prozess aufgrund einer nicht abgefangenen Ausnahme beendet wird. Nützlich bei der Inspektion des JavaScript-Stacks in Verbindung mit dem nativen Stack und anderen Laufzeitumgebungsdaten.

-r, --require Modul

Hinzugefügt in: v1.6.0

Lädt das angegebene Modul beim Start vor.

Befolgt die Modul-Auflösungsregeln von require(). Modul kann entweder ein Pfad zu einer Datei oder ein Node-Modulname sein.

Nur CommonJS-Module werden unterstützt. Verwenden Sie --import, um ein ECMAScript-Modul vorzuladen. Module, die mit --require vor geladen werden, werden vor Modulen ausgeführt, die mit --import vor geladen werden.

Module werden sowohl in den Hauptthread als auch in alle Worker-Threads, geforkten Prozesse oder Cluster-Prozesse vorgeladen.

--run

[Verlauf]

Version	Änderungen
v22.3.0	Umgebungsvariable NODE_RUN_SCRIPT_NAME hinzugefügt.
v22.3.0	Umgebungsvariable NODE_RUN_PACKAGE_JSON_PATH hinzugefügt.
v22.3.0	Durchläuft das Wurzelverzeichnis nach oben und findet eine package.json-Datei, um den Befehl von dort auszuführen, und aktualisiert die Umgebungsvariable PATH entsprechend.
v22.0.0	Hinzugefügt in: v22.0.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Führt einen angegebenen Befehl aus dem "scripts"-Objekt einer package.json aus. Wenn ein fehlender "Befehl" angegeben wird, werden die verfügbaren Skripte aufgelistet.

--run durchläuft das Wurzelverzeichnis nach oben und findet eine package.json-Datei, um den Befehl von dort auszuführen.

--run hängt für jeden Vorfahren des aktuellen Verzeichnisses ./node_modules/.bin an den PATH an, um die Binärdateien aus verschiedenen Ordnern auszuführen, in denen sich mehrere node_modules-Verzeichnisse befinden, wenn ancestor-folder/node_modules/.bin ein Verzeichnis ist.

--run führt den Befehl in dem Verzeichnis aus, das die zugehörige package.json enthält.

Beispielsweise führt der folgende Befehl das test-Skript der package.json im aktuellen Ordner aus:

$ node --run test

Sie können dem Befehl auch Argumente übergeben. Jedes Argument nach -- wird an das Skript angehängt:

$ node --run test -- --verbose

Absichtliche Einschränkungen

node --run soll nicht das Verhalten von npm run oder den run-Befehlen anderer Paketmanager entsprechen. Die Node.js-Implementierung ist absichtlich eingeschränkter, um sich auf höchste Leistung bei den häufigsten Anwendungsfällen zu konzentrieren. Einige Funktionen anderer run-Implementierungen, die absichtlich ausgeschlossen sind, sind:

• Ausführen von pre- oder post-Skripten zusätzlich zu dem angegebenen Skript.
• Definieren von paketmanager-spezifischen Umgebungsvariablen.

Umgebungsvariablen

Die folgenden Umgebungsvariablen werden beim Ausführen eines Skripts mit --run gesetzt:

• NODE_RUN_SCRIPT_NAME: Der Name des ausgeführten Skripts. Wenn beispielsweise --run zum Ausführen von test verwendet wird, lautet der Wert dieser Variablen test.
• NODE_RUN_PACKAGE_JSON_PATH: Der Pfad zur package.json, die verarbeitet wird.

--secure-heap-min=n

Hinzugefügt in: v15.6.0

Bei Verwendung von --secure-heap gibt der Flag --secure-heap-min die minimale Zuweisung vom sicheren Heap an. Der Minimalwert ist 2. Der Maximalwert ist der kleinere Wert von --secure-heap oder 2147483647. Der angegebene Wert muss eine Zweierpotenz sein.

--secure-heap=n

Hinzugefügt in: v15.6.0

Initialisiert einen OpenSSL-sicheren Heap von n Bytes. Nach der Initialisierung wird der sichere Heap für ausgewählte Arten von Zuweisungen innerhalb von OpenSSL während der Schlüsselgenerierung und anderer Vorgänge verwendet. Dies ist beispielsweise nützlich, um zu verhindern, dass sensible Informationen aufgrund von Zeigerüberläufen oder -unterschreitungen durchsickern.

Der sichere Heap hat eine feste Größe und kann zur Laufzeit nicht geändert werden. Wenn er verwendet wird, ist es daher wichtig, einen ausreichend großen Heap auszuwählen, um alle Anwendungszwecke abzudecken.

Die angegebene Heap-Größe muss eine Zweierpotenz sein. Jeder Wert kleiner als 2 deaktiviert den sicheren Heap.

Der sichere Heap ist standardmäßig deaktiviert.

Der sichere Heap ist unter Windows nicht verfügbar.

Siehe CRYPTO_secure_malloc_init für weitere Details.

--snapshot-blob=path

Hinzugefügt in: v18.8.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Bei Verwendung mit --build-snapshot gibt --snapshot-blob den Pfad an, an dem der generierte Snapshot-Blob geschrieben wird. Wenn nicht angegeben, wird der generierte Blob in snapshot.blob im aktuellen Arbeitsverzeichnis geschrieben.

Ohne --build-snapshot verwendet, gibt --snapshot-blob den Pfad zu dem Blob an, der zum Wiederherstellen des Anwendungszustands verwendet wird.

Beim Laden eines Snapshots überprüft Node.js, ob:

Wenn sie nicht übereinstimmen, verweigert Node.js das Laden des Snapshots und beendet sich mit dem Statuscode 1.

--test

[Verlauf]

Version	Änderungen
v20.0.0	Der Test-Runner ist jetzt stabil.
v19.2.0, v18.13.0	Der Test-Runner unterstützt jetzt den Modus "Watch".
v18.1.0, v16.17.0	Hinzugefügt in: v18.1.0, v16.17.0

Startet den Node.js Kommandozeilen-Test-Runner. Dieses Flag kann nicht mit --watch-path, --check, --eval, --interactive oder dem Inspector kombiniert werden. Weitere Details finden Sie in der Dokumentation unter Ausführen von Tests über die Kommandozeile.

--test-concurrency

Hinzugefügt in: v21.0.0, v20.10.0, v18.19.0

Die maximale Anzahl an Testdateien, die die Test-Runner-CLI gleichzeitig ausführt. Wenn --experimental-test-isolation auf 'none' gesetzt ist, wird dieses Flag ignoriert und die Parallelität ist eins. Andernfalls ist die Parallelität standardmäßig os.availableParallelism() - 1.

--test-coverage-branches=threshold

Hinzugefügt in: v22.8.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Fordert einen minimalen Prozentsatz abgedeckter Branches. Wenn die Codeabdeckung den angegebenen Schwellenwert nicht erreicht, beendet der Prozess mit dem Code 1.

--test-coverage-exclude

Hinzugefügt in: v22.5.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Schließt bestimmte Dateien von der Codeabdeckung aus, indem ein Glob-Muster verwendet wird, das sowohl absolute als auch relative Dateipfade abgleichen kann.

Diese Option kann mehrmals angegeben werden, um mehrere Glob-Muster auszuschließen.

Wenn sowohl --test-coverage-exclude als auch --test-coverage-include angegeben sind, müssen Dateien beide Kriterien erfüllen, um in den Coverage-Bericht aufgenommen zu werden.

Standardmäßig werden alle übereinstimmenden Testdateien aus dem Coverage-Bericht ausgeschlossen. Die Angabe dieser Option überschreibt das Standardverhalten.

--test-coverage-functions=threshold

Hinzugefügt in: v22.8.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Fordert einen minimalen Prozentsatz abgedeckter Funktionen. Wenn die Codeabdeckung den angegebenen Schwellenwert nicht erreicht, beendet der Prozess mit dem Code 1.

--test-coverage-include

Hinzugefügt in: v22.5.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Schließt spezifische Dateien in der Codeabdeckung unter Verwendung eines Glob-Musters ein, das sowohl absolute als auch relative Dateipfade abgleichen kann.

Diese Option kann mehrmals angegeben werden, um mehrere Glob-Muster einzuschließen.

Wenn sowohl --test-coverage-exclude als auch --test-coverage-include angegeben sind, müssen Dateien beide Kriterien erfüllen, um in den Coverage-Bericht aufgenommen zu werden.

--test-coverage-lines=threshold

Hinzugefügt in: v22.8.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Erfordert einen minimalen Prozentsatz abgedeckter Zeilen. Wenn die Codeabdeckung den angegebenen Schwellenwert nicht erreicht, beendet der Prozess mit dem Code 1.

--test-force-exit

Hinzugefügt in: v22.0.0, v20.14.0

Konfiguriert den Testläufer, den Prozess zu beenden, sobald alle bekannten Tests abgeschlossen sind, auch wenn die Ereignisschleife sonst aktiv bleiben würde.

--test-name-pattern

[Verlauf]

Version	Änderungen
v20.0.0	Der Testläufer ist jetzt stabil.
v18.11.0	Hinzugefügt in: v18.11.0

Ein regulärer Ausdruck, der den Testläufer so konfiguriert, dass er nur Tests ausführt, deren Name mit dem angegebenen Muster übereinstimmt. Weitere Informationen finden Sie in der Dokumentation zum Filtern von Tests nach Namen.

Wenn sowohl --test-name-pattern als auch --test-skip-pattern angegeben sind, müssen Tests beide Anforderungen erfüllen, um ausgeführt zu werden.

--test-only

[Verlauf]

Version	Änderungen
v20.0.0	Der Testläufer ist jetzt stabil.
v18.0.0, v16.17.0	Hinzugefügt in: v18.0.0, v16.17.0

Konfiguriert den Testläufer so, dass er nur Tests der obersten Ebene ausführt, für die die Option only gesetzt ist. Dieses Flag ist nicht notwendig, wenn die Testisolation deaktiviert ist.

--test-reporter

[Verlauf]

Version	Änderungen
v20.0.0	Der Testläufer ist jetzt stabil.
v19.6.0, v18.15.0	Hinzugefügt in: v19.6.0, v18.15.0

Ein Testreporter, der beim Ausführen von Tests verwendet werden soll. Weitere Informationen finden Sie in der Dokumentation zu Testreportern.

--test-reporter-destination

[Historie]

Version	Änderungen
v20.0.0	Der Test-Runner ist jetzt stabil.
v19.6.0, v18.15.0	Hinzugefügt in: v19.6.0, v18.15.0

Das Ziel für den entsprechenden Test-Reporter. Weitere Details finden Sie in der Dokumentation zu Test-Reporter.

--test-shard

Hinzugefügt in: v20.5.0, v18.19.0

Testsuite-Shard zur Ausführung im Format \<index\>/\<total\>, wobei

index eine positive ganze Zahl ist, Index der geteilten Teile total eine positive ganze Zahl ist, Gesamtzahl der geteilten Teile. Dieser Befehl teilt alle Testdateien in total gleiche Teile auf und führt nur diejenigen aus, die sich in einem index-Teil befinden.

Beispiel: Um Ihre Testsuite in drei Teile zu teilen, verwenden Sie dies:

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

--test-skip-pattern

Hinzugefügt in: v22.1.0

Ein regulärer Ausdruck, der den Test-Runner so konfiguriert, dass Tests übersprungen werden, deren Name mit dem angegebenen Muster übereinstimmt. Weitere Details finden Sie in der Dokumentation zum Filtern von Tests nach Namen.

Wenn sowohl --test-name-pattern als auch --test-skip-pattern angegeben sind, müssen Tests beide Anforderungen erfüllen, um ausgeführt zu werden.

--test-timeout

Hinzugefügt in: v21.2.0, v20.11.0

Eine Anzahl Millisekunden, nach denen die Testausführung fehlschlägt. Wenn nicht angegeben, erben Untertests diesen Wert von ihrem übergeordneten Element. Der Standardwert ist Infinity.

--test-update-snapshots

[Historie]

Version	Änderungen
v23.4.0	Snapshot-Tests sind nicht mehr experimentell.
v22.3.0	Hinzugefügt in: v22.3.0

Generiert die Snapshot-Dateien neu, die vom Test-Runner für Snapshot-Tests verwendet werden.

--throw-deprecation

Hinzugefügt in: v0.11.14

Fehler für veraltete Funktionen auslösen.

--title=title

Hinzugefügt in: v10.7.0

process.title beim Start festlegen.

--tls-cipher-list=list

Hinzugefügt in: v4.0.0

Gibt eine alternative Standard-TLS-Cipher-Liste an. Erfordert, dass Node.js mit Krypto-Unterstützung erstellt wurde (Standard).

--tls-keylog=file

Hinzugefügt in: v13.2.0, v12.16.0

Protokolliert TLS-Schlüsselmaterial in einer Datei. Das Schlüsselmaterial liegt im NSS SSLKEYLOGFILE-Format vor und kann von Software (wie Wireshark) zum Entschlüsseln des TLS-Verkehrs verwendet werden.

--tls-max-v1.2

Hinzugefügt in: v12.0.0, v10.20.0

Setzt tls.DEFAULT_MAX_VERSION auf 'TLSv1.2'. Wird verwendet, um die Unterstützung für TLSv1.3 zu deaktivieren.

--tls-max-v1.3

Hinzugefügt in: v12.0.0

Setzt das standardmäßige tls.DEFAULT_MAX_VERSION auf 'TLSv1.3'. Wird verwendet, um die Unterstützung für TLSv1.3 zu aktivieren.

--tls-min-v1.0

Hinzugefügt in: v12.0.0, v10.20.0

Setzt das standardmäßige tls.DEFAULT_MIN_VERSION auf 'TLSv1'. Wird für die Kompatibilität mit alten TLS-Clients oder -Servern verwendet.

--tls-min-v1.1

Hinzugefügt in: v12.0.0, v10.20.0

Setzt das standardmäßige tls.DEFAULT_MIN_VERSION auf 'TLSv1.1'. Wird für die Kompatibilität mit alten TLS-Clients oder -Servern verwendet.

--tls-min-v1.2

Hinzugefügt in: v12.2.0, v10.20.0

Setzt das standardmäßige tls.DEFAULT_MIN_VERSION auf 'TLSv1.2'. Dies ist die Standardeinstellung für 12.x und höher, aber die Option wird aus Kompatibilitätsgründen mit älteren Node.js-Versionen unterstützt.

--tls-min-v1.3

Hinzugefügt in: v12.0.0

Setzt das standardmäßige tls.DEFAULT_MIN_VERSION auf 'TLSv1.3'. Wird verwendet, um die Unterstützung für TLSv1.2 zu deaktivieren, da TLSv1.3 sicherer ist.

--trace-deprecation

Hinzugefügt in: v0.8.0

Gibt Stack-Traces für veraltete Funktionen aus.

--trace-env

Hinzugefügt in: v23.4.0

Gibt Informationen über jeden Zugriff auf Umgebungsvariablen in der aktuellen Node.js-Instanz an stderr aus, einschließlich:

• Der internen Lesevorgänge von Umgebungsvariablen durch Node.js.
• Schreibvorgänge in der Form process.env.KEY = "SOME VALUE".
• Lesevorgänge in der Form process.env.KEY.
• Definitionen in der Form Object.defineProperty(process.env, 'KEY', {...}).
• Abfragen in der Form Object.hasOwn(process.env, 'KEY'), process.env.hasOwnProperty('KEY') oder 'KEY' in process.env.
• Löschvorgänge in der Form delete process.env.KEY.
• Auflistungen in der Form ...process.env oder Object.keys(process.env).

Es werden nur die Namen der abgerufenen Umgebungsvariablen ausgegeben. Die Werte werden nicht ausgegeben.

Um den Stack-Trace des Zugriffs auszugeben, verwenden Sie --trace-env-js-stack und/oder --trace-env-native-stack.

--trace-env-js-stack

Hinzugefügt in: v23.4.0

Zusätzlich zu den Funktionen von --trace-env wird der JavaScript-Stacktrace des Zugriffs ausgegeben.

--trace-env-native-stack

Hinzugefügt in: v23.4.0

Zusätzlich zu den Funktionen von --trace-env wird der native Stacktrace des Zugriffs ausgegeben.

--trace-event-categories

Hinzugefügt in: v7.7.0

Eine kommaseparierte Liste von Kategorien, die verfolgt werden sollen, wenn die Trace-Event-Verfolgung mit --trace-events-enabled aktiviert ist.

--trace-event-file-pattern

Hinzugefügt in: v9.8.0

Templatestring, der den Dateipfad für die Trace-Event-Daten angibt. Er unterstützt ${rotation} und ${pid}.

--trace-events-enabled

Hinzugefügt in: v7.7.0

Aktiviert die Erfassung von Trace-Event-Verfolgungsinformationen.

--trace-exit

Hinzugefügt in: v13.5.0, v12.16.0

Gibt einen Stacktrace aus, wenn eine Umgebung proaktiv beendet wird, d. h. process.exit() aufgerufen wird.

--trace-require-module=mode

Hinzugefügt in: v23.5.0

Gibt Informationen über die Verwendung von Laden von ECMAScript-Modulen mit require() aus.

Wenn mode auf all gesetzt ist, wird die gesamte Verwendung ausgegeben. Wenn mode auf no-node-modules gesetzt ist, wird die Verwendung aus dem Ordner node_modules ausgeschlossen.

--trace-sigint

Hinzugefügt in: v13.9.0, v12.17.0

Gibt einen Stacktrace bei SIGINT aus.

--trace-sync-io

Hinzugefügt in: v2.1.0

Gibt einen Stacktrace aus, wenn synchroner I/O nach der ersten Runde des Event-Loops erkannt wird.

--trace-tls

Hinzugefügt in: v12.2.0

Gibt TLS-Paket-Trace-Informationen an stderr aus. Dies kann verwendet werden, um Probleme mit der TLS-Verbindung zu debuggen.

--trace-uncaught

Hinzugefügt in: v13.1.0

Gibt Stacktraces für nicht abgefangene Ausnahmen aus; normalerweise wird der Stacktrace ausgegeben, der mit der Erstellung eines Error-Objekts verbunden ist, während dies Node.js dazu bringt, auch den Stacktrace auszugeben, der mit dem Auslösen des Werts verbunden ist (der keine Error-Instanz sein muss).

Das Aktivieren dieser Option kann sich negativ auf das Garbage-Collection-Verhalten auswirken.

--trace-warnings

Hinzugefügt in: v6.0.0

Gibt Stacktraces für Prozesswarnungen (einschließlich Veralterungen) aus.

--track-heap-objects

Hinzugefügt in: v2.4.0

Verfolgt Heap-Objektzuweisungen für Heap-Snapshots.

--unhandled-rejections=modus

[Verlauf]

Version	Änderungen
v15.0.0	Standardmodus auf throw geändert. Zuvor wurde eine Warnung ausgegeben.
v12.0.0, v10.17.0	Hinzugefügt in: v12.0.0, v10.17.0

Mit diesem Flag kann geändert werden, was bei einer nicht behandelten Ablehnung geschehen soll. Einer der folgenden Modi kann gewählt werden:

• throw: Gibt unhandledRejection aus. Wenn dieser Hook nicht gesetzt ist, wird die nicht behandelte Ablehnung als nicht abgefangene Ausnahme ausgelöst. Dies ist der Standardwert.
• strict: Löst die nicht behandelte Ablehnung als nicht abgefangene Ausnahme aus. Wenn die Ausnahme behandelt wird, wird unhandledRejection ausgegeben.
• warn: Löst immer eine Warnung aus, unabhängig davon, ob der unhandledRejection-Hook gesetzt ist oder nicht, gibt aber die Verwendungsabkündigungswarnung nicht aus.
• warn-with-error-code: Gibt unhandledRejection aus. Wenn dieser Hook nicht gesetzt ist, wird eine Warnung ausgelöst und der Prozess-Exit-Code auf 1 gesetzt.
• none: Unterdrückt alle Warnungen.

Wenn eine Ablehnung während der statischen Ladephase des ES-Modul-Eingangs des Befehlszeilenprogramms auftritt, wird sie immer als nicht abgefangene Ausnahme ausgelöst.

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

Hinzugefügt in: v6.11.0

Verwendet den mitgelieferten Mozilla CA-Speicher der aktuellen Node.js-Version oder den Standard-CA-Speicher von OpenSSL. Der Standardspeicher ist zur Buildzeit auswählbar.

Der mitgelieferte CA-Speicher von Node.js ist ein Snapshot des Mozilla CA-Speichers, der zum Zeitpunkt der Veröffentlichung festgelegt wird. Er ist auf allen unterstützten Plattformen identisch.

Die Verwendung des OpenSSL-Speichers ermöglicht externe Änderungen des Speichers. Bei den meisten Linux- und BSD-Distributionen wird dieser Speicher von den Distributionsbetreuern und Systemadministratoren verwaltet. Der Speicherort des OpenSSL CA-Speichers hängt von der Konfiguration der OpenSSL-Bibliothek ab, kann aber zur Laufzeit mit Umgebungsvariablen geändert werden.

Siehe SSL_CERT_DIR und SSL_CERT_FILE.

--use-largepages=mode

Hinzugefügt in: v13.6.0, v12.17.0

Ordnet den statischen Node.js-Code beim Start auf großen Speicherseiten neu zu. Wenn dies auf dem Zielsystem unterstützt wird, wird der statische Node.js-Code auf 2-MiB-Seiten anstatt auf 4-KiB-Seiten verschoben.

Die folgenden Werte sind für mode gültig:

• off: Es wird kein Mapping versucht. Dies ist die Standardeinstellung.
• on: Wenn vom Betriebssystem unterstützt, wird ein Mapping versucht. Ein Mapping-Fehler wird ignoriert und eine Meldung wird an die Standardfehlerausgabe ausgegeben.
• silent: Wenn vom Betriebssystem unterstützt, wird ein Mapping versucht. Ein Mapping-Fehler wird ignoriert und nicht gemeldet.

--v8-options

Hinzugefügt in: v0.1.3

Gibt V8-Befehlszeilenoptionen aus.

--v8-pool-size=num

Hinzugefügt in: v5.10.0

Legt die Größe des V8-Thread-Pools fest, der zum Zuweisen von Hintergrundjobs verwendet wird.

Wenn auf 0 gesetzt, wählt Node.js eine geeignete Größe des Thread-Pools basierend auf einer Schätzung des Parallelitätsgrads.

Der Parallelitätsgrad bezieht sich auf die Anzahl der Berechnungen, die gleichzeitig auf einem gegebenen Rechner durchgeführt werden können. Im Allgemeinen entspricht er der Anzahl der CPUs, kann aber in Umgebungen wie VMs oder Containern abweichen.

-v, --version

Hinzugefügt in: v0.1.3

Gibt die Node-Version aus.

--watch

[Verlauf]

Version	Änderungen
v22.0.0, v20.13.0	Der Überwachungsmodus ist jetzt stabil.
v19.2.0, v18.13.0	Der Test-Runner unterstützt jetzt die Ausführung im Überwachungsmodus.
v18.11.0, v16.19.0	Hinzugefügt in: v18.11.0, v16.19.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Startet Node.js im Überwachungsmodus. Im Überwachungsmodus führen Änderungen in den beobachteten Dateien zum Neustart des Node.js-Prozesses. Im Überwachungsmodus wird standardmäßig der Einstiegspunkt und jedes benötigte oder importierte Modul überwacht. Verwenden Sie --watch-path, um anzugeben, welche Pfade überwacht werden sollen.

Dieses Flag kann nicht mit --check, --eval, --interactive oder dem REPL kombiniert werden.

node --watch index.js

--watch-path

[Verlauf]

Version	Änderungen
v22.0.0, v20.13.0	Überwachungsmodus ist jetzt stabil.
v18.11.0, v16.19.0	Hinzugefügt in: v18.11.0, v16.19.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Startet Node.js im Überwachungsmodus und gibt an, welche Pfade überwacht werden sollen. Im Überwachungsmodus führen Änderungen in den beobachteten Pfaden zum Neustart des Node.js-Prozesses. Dies deaktiviert die Überwachung von benötigten oder importierten Modulen, auch in Kombination mit --watch.

Dieses Flag kann nicht mit --check, --eval, --interactive, --test oder der REPL kombiniert werden.

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

Diese Option wird nur unter macOS und Windows unterstützt. Eine ERR_FEATURE_UNAVAILABLE_ON_PLATFORM Ausnahme wird ausgelöst, wenn die Option auf einer Plattform verwendet wird, die sie nicht unterstützt.

--watch-preserve-output

Hinzugefügt in: v19.3.0, v18.13.0

Deaktiviert das Löschen der Konsole, wenn der Überwachungsmodus den Prozess neu startet.

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

--zero-fill-buffers

Hinzugefügt in: v6.0.0

Füllt alle neu zugeordneten Buffer und SlowBuffer Instanzen automatisch mit Nullen.

Umgebungsvariablen

FORCE_COLOR=[1, 2, 3]

Die Umgebungsvariable FORCE_COLOR wird verwendet, um die farbige ANSI-Ausgabe zu aktivieren. Der Wert kann sein:

• 1, true, oder die leere Zeichenkette '' für 16-Farben-Unterstützung,
• 2 für 256-Farben-Unterstützung, oder
• 3 für 16 Millionen Farben Unterstützung.

Wenn FORCE_COLOR verwendet und auf einen unterstützten Wert gesetzt wird, werden sowohl die Umgebungsvariablen NO_COLOR als auch NODE_DISABLE_COLORS ignoriert.

Jeder andere Wert führt dazu, dass die farbige Ausgabe deaktiviert wird.

NODE_COMPILE_CACHE=dir

Hinzugefügt in: v22.1.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Aktiviert den Modul-Kompilierungs-Cache für die Node.js-Instanz. Siehe die Dokumentation des Modul-Kompilierungs-Caches für Details.

NODE_DEBUG=module[,…]

Hinzugefügt in: v0.1.32

Kommaseparierte Liste von Kernmodulen, die Debug-Informationen ausgeben sollen.

NODE_DEBUG_NATIVE=module[,…]

Kommaseparierte Liste von Core-C++-Modulen, die Debug-Informationen ausgeben sollen.

NODE_DISABLE_COLORS=1

Hinzugefügt in: v0.3.0

Wenn gesetzt, werden im REPL keine Farben verwendet.

NODE_DISABLE_COMPILE_CACHE=1

Hinzugefügt in: v22.8.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

Deaktiviert den Modul-Kompilier-Cache für die Node.js-Instanz. Details finden Sie in der Dokumentation des Modul-Kompilier-Caches.

NODE_EXTRA_CA_CERTS=file

Hinzugefügt in: v7.3.0

Wenn gesetzt, werden die bekannten "Root"-CAs (wie VeriSign) um die zusätzlichen Zertifikate in file erweitert. Die Datei sollte aus einem oder mehreren vertrauenswürdigen Zertifikaten im PEM-Format bestehen. Eine Meldung wird (einmalig) mit process.emitWarning() ausgegeben, wenn die Datei fehlt oder fehlerhaft ist, ansonsten werden alle Fehler ignoriert.

Weder die bekannten noch die zusätzlichen Zertifikate werden verwendet, wenn die Eigenschaft ca der Optionen explizit für einen TLS- oder HTTPS-Client oder -Server angegeben ist.

Diese Umgebungsvariable wird ignoriert, wenn node als setuid root ausgeführt wird oder Linux-Dateifähigkeiten gesetzt sind.

Die Umgebungsvariable NODE_EXTRA_CA_CERTS wird nur beim ersten Start des Node.js-Prozesses gelesen. Das Ändern des Werts zur Laufzeit mit process.env.NODE_EXTRA_CA_CERTS hat keine Auswirkung auf den aktuellen Prozess.

NODE_ICU_DATA=file

Hinzugefügt in: v0.11.15

Datenpfad für ICU (Intl Objekt)-Daten. Erweitert die eingebundenen Daten, wenn mit small-icu-Unterstützung kompiliert wurde.

NODE_NO_WARNINGS=1

Hinzugefügt in: v6.11.0

Wenn auf 1 gesetzt, werden Prozesswarnungen unterdrückt.

NODE_OPTIONS=options...

Hinzugefügt in: v8.0.0

Eine durch Leerzeichen getrennte Liste von Befehlszeilenoptionen. options... werden vor den Befehlszeilenoptionen interpretiert, daher überschreiben oder ergänzen Befehlszeilenoptionen alles in options.... Node.js beendet sich mit einem Fehler, wenn eine Option verwendet wird, die in der Umgebung nicht zulässig ist, z. B. -p oder eine Skriptdatei.

Wenn ein Optionswert ein Leerzeichen enthält, kann er mit doppelten Anführungszeichen escaped werden:

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

Ein Singleton-Flag, das als Befehlszeilenoption übergeben wird, überschreibt dasselbe Flag, das an NODE_OPTIONS übergeben wird:

# Der Inspector wird auf Port 5555 verfügbar sein {#node_options=options}
NODE_OPTIONS='--inspect=localhost:4444' node --inspect=localhost:5555

Ein Flag, das mehrmals übergeben werden kann, wird so behandelt, als ob seine NODE_OPTIONS-Instanzen zuerst und dann seine Befehlszeilen-Instanzen danach übergeben würden:

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

Zulässige Node.js-Optionen befinden sich in der folgenden Liste. Wenn eine Option sowohl --XX als auch --no-XX-Varianten unterstützt, werden beide unterstützt, aber nur eine ist in der folgenden Liste enthalten.

• --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

Zulässige V8-Optionen sind:

• --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 und --perf-prof sind nur unter Linux verfügbar.

--enable-etw-stack-walking ist nur unter Windows verfügbar.

NODE_PATH=Pfad[:…]

Hinzugefügt in: v0.1.32

Durch Doppelpunkte ':' getrennte Liste von Verzeichnissen, die dem Modulsuchpfad vorangestellt werden.

Unter Windows ist dies stattdessen eine durch Semikolons ; getrennte Liste.

NODE_PENDING_DEPRECATION=1

Hinzugefügt in: v8.0.0

Wenn auf 1 gesetzt, werden Warnungen vor auslaufenden Funktionen ausgegeben.

Auslaufende Funktionen sind im Allgemeinen identisch mit einer Laufzeit-Veralterung, mit der bemerkenswerten Ausnahme, dass sie standardmäßig deaktiviert sind und nicht ausgegeben werden, es sei denn, entweder das Befehlszeilenflag --pending-deprecation oder die Umgebungsvariable NODE_PENDING_DEPRECATION=1 ist gesetzt. Auslaufende Funktionen werden verwendet, um einen selektiven "Frühwarnungs"-Mechanismus bereitzustellen, den Entwickler nutzen können, um die Verwendung veralteter APIs zu erkennen.

NODE_PENDING_PIPE_INSTANCES=Instanzen

Legt die Anzahl der ausstehenden Pipe-Instanz-Handles fest, wenn der Pipe-Server auf Verbindungen wartet. Diese Einstellung gilt nur für Windows.

NODE_PRESERVE_SYMLINKS=1

Hinzugefügt in: v7.1.0

Wenn auf 1 gesetzt, weist der Modul-Loader an, symbolische Links bei der Auflösung und Zwischenspeicherung von Modulen beizubehalten.

NODE_REDIRECT_WARNINGS=Datei

Hinzugefügt in: v8.0.0

Wenn gesetzt, werden Prozesswarnungen an die angegebene Datei ausgegeben, anstatt auf stderr auszugeben. Die Datei wird erstellt, wenn sie nicht existiert, und wird angehängt, wenn sie existiert. Wenn beim Versuch, die Warnung in die Datei zu schreiben, ein Fehler auftritt, wird die Warnung stattdessen auf stderr geschrieben. Dies entspricht der Verwendung des Befehlszeilenflags --redirect-warnings=Datei.

NODE_REPL_EXTERNAL_MODULE=Datei

[Verlauf]

Version	Änderungen
v22.3.0, v20.16.0	Entfernt die Möglichkeit, diese Umgebungsvariable mit kDisableNodeOptionsEnv für Einbetter zu verwenden.
v13.0.0, v12.16.0	Hinzugefügt in: v13.0.0, v12.16.0

Pfad zu einem Node.js-Modul, das anstelle der integrierten REPL geladen wird. Durch Überschreiben dieses Werts mit einer leeren Zeichenkette ('') wird die integrierte REPL verwendet.

NODE_REPL_HISTORY=Datei

Hinzugefügt in: v3.0.0

Pfad zu der Datei, die zum Speichern des persistenten REPL-Verlaufs verwendet wird. Der Standardpfad ist ~/.node_repl_history, der durch diese Variable überschrieben wird. Wenn der Wert auf eine leere Zeichenkette ('' oder ' ') gesetzt wird, wird der persistente REPL-Verlauf deaktiviert.

NODE_SKIP_PLATFORM_CHECK=value

Hinzugefügt in: v14.5.0

Wenn value gleich '1' ist, wird die Prüfung auf eine unterstützte Plattform während des Node.js-Starts übersprungen. Node.js funktioniert möglicherweise nicht korrekt. Alle auf nicht unterstützten Plattformen auftretenden Probleme werden nicht behoben.

NODE_TEST_CONTEXT=value

Wenn value gleich 'child' ist, werden die Optionen des Testreporters überschrieben und die Testergebnisse werden im TAP-Format an stdout gesendet. Wenn ein anderer Wert angegeben wird, gibt Node.js keine Garantie für das verwendete Reporterformat oder dessen Stabilität.

NODE_TLS_REJECT_UNAUTHORIZED=value

Wenn value gleich '0' ist, wird die Zertifikatsprüfung für TLS-Verbindungen deaktiviert. Dies macht TLS und damit auch HTTPS unsicher. Die Verwendung dieser Umgebungsvariablen wird dringend abgeraten.

NODE_V8_COVERAGE=dir

Wenn gesetzt, beginnt Node.js mit der Ausgabe von V8 JavaScript Code Coverage und Source Map Daten in das als Argument angegebene Verzeichnis (Coverage-Informationen werden als JSON in Dateien mit dem Präfix coverage geschrieben).

NODE_V8_COVERAGE wird automatisch an Unterprozesse weitergegeben, wodurch die Instrumentierung von Anwendungen, die die child_process.spawn()-Funktionenfamilie aufrufen, vereinfacht wird. NODE_V8_COVERAGE kann auf eine leere Zeichenkette gesetzt werden, um die Weitergabe zu verhindern.

NO_COLOR=<any>

NO_COLOR ist ein Alias für NODE_DISABLE_COLORS. Der Wert der Umgebungsvariablen ist beliebig.

Coverage-Ausgabe {#no_color=<any>}

Coverage wird als Array von ScriptCoverage Objekten unter dem Top-Level-Schlüssel result ausgegeben:

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

Source Map Cache

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Wenn gefunden, werden Source Map Daten an den Top-Level-Schlüssel source-map-cache im JSON Coverage Objekt angehängt.

source-map-cache ist ein Objekt mit Schlüsseln, die die Dateien repräsentieren, aus denen Source Maps extrahiert wurden, und Werten, die die rohe Source-Map-URL (im Schlüssel url), die geparsten Source Map v3 Informationen (im Schlüssel data) und die Zeilengrößen der Quelldatei (im Schlüssel lineLengths) enthalten.

{
  "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=file

Hinzugefügt in: v6.11.0

Lädt beim Start eine OpenSSL-Konfigurationsdatei. Unter anderem kann dies verwendet werden, um FIPS-konforme Kryptografie zu aktivieren, wenn Node.js mit ./configure --openssl-fips gebaut wurde.

Wenn die Kommandozeilenoption --openssl-config verwendet wird, wird die Umgebungsvariable ignoriert.

SSL_CERT_DIR=dir

Hinzugefügt in: v7.7.0

Wenn --use-openssl-ca aktiviert ist, überschreibt und setzt dies das OpenSSL-Verzeichnis, das vertrauenswürdige Zertifikate enthält.

Beachten Sie, dass diese Umgebungsvariable, sofern die untergeordnete Umgebung nicht explizit gesetzt wird, von allen untergeordneten Prozessen geerbt wird und diese, falls sie OpenSSL verwenden, möglicherweise dazu führt, dass sie denselben CAs vertrauen wie Node.

SSL_CERT_FILE=file

Hinzugefügt in: v7.7.0

Wenn --use-openssl-ca aktiviert ist, überschreibt und setzt dies die OpenSSL-Datei, die vertrauenswürdige Zertifikate enthält.

Beachten Sie, dass diese Umgebungsvariable, sofern die untergeordnete Umgebung nicht explizit gesetzt wird, von allen untergeordneten Prozessen geerbt wird und diese, falls sie OpenSSL verwenden, möglicherweise dazu führt, dass sie denselben CAs vertrauen wie Node.

TZ

[Verlauf]

Version	Änderungen
v16.2.0	Das Ändern der TZ-Variablen mit process.env.TZ = ändert die Zeitzone auch unter Windows.
v13.0.0	Das Ändern der TZ-Variablen mit process.env.TZ = ändert die Zeitzone unter POSIX-Systemen.
v0.0.1	Hinzugefügt in: v0.0.1

Die Umgebungsvariable TZ wird verwendet, um die Zeitzonenkonfiguration anzugeben.

Node.js unterstützt zwar nicht alle verschiedenen Arten der Behandlung von TZ in anderen Umgebungen, aber es unterstützt grundlegende Zeitzonen-IDs (wie 'Etc/UTC', 'Europe/Paris' oder 'America/New_York'). Es unterstützt möglicherweise einige andere Abkürzungen oder Aliase, diese werden jedoch dringend abgeraten und sind nicht garantiert.

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

UV_THREADPOOL_SIZE=größe

Legt die Anzahl der Threads im Threadpool von libuv auf größe Threads fest.

Node.js verwendet nach Möglichkeit asynchrone System-APIs. Sind diese nicht verfügbar, wird der Threadpool von libuv verwendet, um asynchrone Node-APIs auf Basis synchroner System-APIs zu erstellen. Node.js-APIs, die den Threadpool verwenden, sind:

• alle fs-APIs, außer den File-Watcher-APIs und den explizit synchronen APIs
• asynchrone Krypto-APIs wie crypto.pbkdf2(), crypto.scrypt(), crypto.randomBytes(), crypto.randomFill(), crypto.generateKeyPair()
• dns.lookup()
• alle zlib-APIs, außer den explizit synchronen APIs

Da der Threadpool von libuv eine feste Größe hat, bedeutet dies, dass, wenn eine dieser APIs aus irgendeinem Grund lange dauert, andere (scheinbar nicht verwandte) APIs, die im Threadpool von libuv laufen, eine Leistungseinbuße erfahren. Um dieses Problem zu mindern, besteht eine mögliche Lösung darin, die Größe des Threadpools von libuv zu erhöhen, indem die Umgebungsvariable 'UV_THREADPOOL_SIZE' auf einen Wert größer als 4 (der aktuelle Standardwert) gesetzt wird. Das Setzen dieser Variable innerhalb des Prozesses mittels process.env.UV_THREADPOOL_SIZE=größe ist jedoch nicht garantiert zu funktionieren, da der Threadpool als Teil der Laufzeitinitialisierung erstellt wird, lange bevor der Benutzercode ausgeführt wird. Weitere Informationen finden Sie in der libuv Threadpool-Dokumentation.

Nützliche V8-Optionen

V8 verfügt über einen eigenen Satz von CLI-Optionen. Jede V8 CLI-Option, die an node übergeben wird, wird an V8 zur Verarbeitung weitergegeben. V8-Optionen haben keine Stabilitätsgarantie. Das V8-Team selbst betrachtet sie nicht als Teil seiner formalen API und behält sich das Recht vor, sie jederzeit zu ändern. Ebenso fallen sie nicht unter die Stabilitätsgarantien von Node.js. Viele der V8-Optionen sind nur für V8-Entwickler von Interesse. Trotzdem gibt es eine kleine Gruppe von V8-Optionen, die für Node.js weit verbreitet sind, und diese werden hier dokumentiert:

--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=GRÖSSE (in MiB)

Legt die maximale Speichergröße des alten Speicherbereichs von V8 fest. Wenn der Speicherverbrauch sich dem Limit nähert, wird V8 mehr Zeit für die Garbage Collection aufwenden, um nicht verwendeten Speicher freizugeben.

Auf einem Rechner mit 2 GiB Arbeitsspeicher sollten Sie diesen Wert auf 1536 (1,5 GiB) setzen, um etwas Speicher für andere Anwendungen freizuhalten und Swapping zu vermeiden.

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

--max-semi-space-size=GRÖSSE (in MiB)

Legt die maximale Größe des Halbraums für den Scavenge-Garbage-Collector von V8 in MiB (Mebibyte) fest. Eine Erhöhung der maximalen Größe eines Halbraums kann den Durchsatz von Node.js auf Kosten eines höheren Speicherverbrauchs verbessern.

Da die Größe der jungen Generation des V8-Heaps das Dreifache (siehe YoungGenerationSizeFromSemiSpaceSize in V8) der Größe des Halbraums beträgt, wirkt sich eine Erhöhung um 1 MiB auf den Halbraum auf jeden der drei einzelnen Halbräume aus und führt zu einer Erhöhung der Heap-Größe um 3 MiB. Die Verbesserung des Durchsatzes hängt von Ihrer Arbeitslast ab (siehe #42511).

Der Standardwert hängt vom Speicherlimit ab. Beispielsweise beträgt die maximale Größe eines Halbraums auf 64-Bit-Systemen mit einem Speicherlimit von 512 MiB standardmäßig 1 MiB. Bei Speicherlimits bis einschließlich 2 GiB beträgt die standardmäßige maximale Größe eines Halbraums auf 64-Bit-Systemen weniger als 16 MiB.

Um die beste Konfiguration für Ihre Anwendung zu erhalten, sollten Sie verschiedene max-semi-space-size-Werte ausprobieren, wenn Sie Benchmarks für Ihre Anwendung ausführen.

Beispiel für einen Benchmark auf 64-Bit-Systemen:

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

Die maximale Anzahl an Stack-Frames, die in der Stack-Trace einer Fehlers gesammelt werden. Eine Einstellung auf 0 deaktiviert die Stack-Trace-Sammlung. Der Standardwert ist 10.

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