API della riga di comando

Node.js è dotato di una varietà di opzioni CLI. Queste opzioni espongono il debug integrato, diversi modi per eseguire script e altre utili opzioni di runtime.

Per visualizzare questa documentazione come una pagina di manuale in un terminale, eseguire man node.

Sinossi

node [opzioni] [opzioni V8] [\<punto-di-ingresso-programma\> | -e "script" | -] [--] [argomenti]

node inspect [\<punto-di-ingresso-programma\> | -e "script" | \<host\>:\<porta\>] …

node --v8-options

Eseguire senza argomenti per avviare il REPL.

Per maggiori informazioni su node inspect, consultare la documentazione del debugger.

Punto di ingresso del programma

Il punto di ingresso del programma è una stringa simile a uno specificatore. Se la stringa non è un percorso assoluto, viene risolta come un percorso relativo dalla directory di lavoro corrente. Tale percorso viene quindi risolto dal caricatore di moduli CommonJS. Se non viene trovato alcun file corrispondente, viene generato un errore.

Se viene trovato un file, il suo percorso verrà passato al caricatore di moduli ES in una delle seguenti condizioni:

• Il programma è stato avviato con un flag della riga di comando che forza il caricamento del punto di ingresso con il caricatore di moduli ECMAScript, come --import.
• Il file ha un'estensione .mjs.
• Il file non ha un'estensione .cjs e il file package.json genitore più vicino contiene un campo di primo livello "type" con un valore di "module".

In caso contrario, il file viene caricato utilizzando il caricatore di moduli CommonJS. Vedere Caricatori di moduli per maggiori dettagli.

Avvertenza sul punto di ingresso del caricatore di moduli ECMAScript

Durante il caricamento, il caricatore di moduli ES carica il punto di ingresso del programma, il comando node accetterà come input solo file con estensioni .js, .mjs o .cjs; e con estensioni .wasm quando --experimental-wasm-modules è abilitato.

Opzioni

[Cronologia]

Versione	Cambiamenti
v10.12.0	I trattini bassi invece dei trattini sono ora consentiti anche per le opzioni Node.js, oltre che per le opzioni V8.

Tutte le opzioni, incluse le opzioni V8, consentono di separare le parole con trattini (-) o trattini bassi (_). Ad esempio, --pending-deprecation è equivalente a --pending_deprecation.

Se un'opzione che accetta un singolo valore (come --max-http-header-size) viene passata più di una volta, viene utilizzato l'ultimo valore passato. Le opzioni dalla riga di comando hanno la precedenza sulle opzioni passate tramite la variabile d'ambiente NODE_OPTIONS.

-

Aggiunto in: v8.0.0

Alias per stdin. Analogo all'uso di - in altre utility a riga di comando, il che significa che lo script viene letto da stdin e il resto delle opzioni viene passato a tale script.

--

Aggiunto in: v6.11.0

Indica la fine delle opzioni di node. Passa il resto degli argomenti allo script. Se prima di questo non viene fornito alcun nome file di script o script eval/print, allora l'argomento successivo viene utilizzato come nome file di script.

--abort-on-uncaught-exception

Aggiunto in: v0.10.8

L'interruzione anziché l'uscita causa la generazione di un file core per l'analisi post-mortem utilizzando un debugger (come lldb, gdb e mdb).

Se questo flag viene passato, il comportamento può essere comunque impostato in modo da non interrompersi tramite process.setUncaughtExceptionCaptureCallback() (e tramite l'uso del modulo node:domain che lo utilizza).

--allow-addons

Aggiunto in: v21.6.0, v20.12.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

Quando si utilizza il Modello di Permessi, il processo non sarà in grado di utilizzare gli addon nativi di default. I tentativi di farlo lanceranno un ERR_DLOPEN_DISABLED a meno che l'utente non passi esplicitamente il flag --allow-addons all'avvio di Node.js.

Esempio:

// Tentativo di richiedere un addon nativo
require('nodejs-addon-example')

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

Errore: Impossibile caricare l'addon nativo perché il caricamento degli addon è disabilitato.
    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

Aggiunto in: v20.0.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

Quando si utilizza il Modello di autorizzazioni, il processo non sarà in grado di generare alcun processo figlio per impostazione predefinita. I tentativi di farlo genereranno un errore ERR_ACCESS_DENIED a meno che l'utente non passi esplicitamente il flag --allow-child-process all'avvio di Node.js.

Esempio:

const childProcess = require('node:child_process')
// Tentativo di bypassare l'autorizzazione
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: Accesso a questa API è stato limitato
    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

[Cronologia]

Versione	Modifiche
v23.5.0	Il modello di autorizzazioni e i flag --allow-fs sono stabili.
v20.7.0	I percorsi delimitati da virgola (,) non sono più consentiti.
v20.0.0	Aggiunto in: v20.0.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile.

Questo flag configura le autorizzazioni di lettura del file system utilizzando il Modello di autorizzazioni.

Gli argomenti validi per il flag --allow-fs-read sono:

• * - Per consentire tutte le operazioni FileSystemRead.
• È possibile consentire più percorsi utilizzando più flag --allow-fs-read. Esempio --allow-fs-read=/cartella1/ --allow-fs-read=/cartella1/

Esempi possono essere trovati nella documentazione Autorizzazioni del file system.

È necessario consentire anche il modulo inizializzatore. Si consideri il seguente esempio:

$ node --permission index.js

Error: Accesso a questa API è stato limitato
    at node:internal/main/run_main_module:23:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'FileSystemRead',
  resource: '/Users/rafaelgss/repos/os/node/index.js'
}

Il processo deve avere accesso al modulo index.js:

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

--allow-fs-write

[Storia]

Versione	Cambiamenti
v23.5.0	Il Modello di Permessi e i flag --allow-fs sono stabili.
v20.7.0	I percorsi delimitati da virgola (,) non sono più consentiti.
v20.0.0	Aggiunto in: v20.0.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile.

Questo flag configura le autorizzazioni di scrittura del file system utilizzando il Modello di Permessi.

Gli argomenti validi per il flag --allow-fs-write sono:

• * - Per consentire tutte le operazioni FileSystemWrite.
• È possibile consentire più percorsi utilizzando più flag --allow-fs-write. Esempio --allow-fs-write=/cartella1/ --allow-fs-write=/cartella1/

I percorsi delimitati da virgola (,) non sono più consentiti. Quando si passa un singolo flag con una virgola, verrà visualizzato un avviso.

Esempi sono disponibili nella documentazione Permessi del File System.

--allow-wasi

Aggiunto in: v22.3.0, v20.16.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

Quando si utilizza il Modello di Permessi, il processo non sarà in grado di creare istanze WASI per impostazione predefinita. Per motivi di sicurezza, la chiamata genererà un ERR_ACCESS_DENIED a meno che l'utente non passi esplicitamente il flag --allow-wasi nel processo principale di Node.js.

Esempio:

const { WASI } = require('node:wasi')
// Tentativo di bypassare l'autorizzazione
new WASI({
  version: 'preview1',
  // Tentativo di montare l'intero file system
  preopens: {
    '/': '/',
  },
})

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

Error: Accesso a questa API è stato limitato
    at node:internal/main/run_main_module:30:49 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'WASI',
}

--allow-worker

Aggiunto in: v20.0.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

Quando si utilizza il Modello di Permessi, il processo non sarà in grado di creare thread worker per impostazione predefinita. Per motivi di sicurezza, la chiamata genererà un ERR_ACCESS_DENIED a meno che l'utente non passi esplicitamente il flag --allow-worker nel processo principale di Node.js.

Esempio:

const { Worker } = require('node:worker_threads')
// Tentativo di bypassare l'autorizzazione
new Worker(__filename)

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

Error: Accesso a questa API è stato limitato
    at node:internal/main/run_main_module:17:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'WorkerThreads'
}

--build-snapshot

Aggiunto in: v18.8.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Genera un blob snapshot quando il processo termina e lo scrive su disco, che può essere caricato successivamente con --snapshot-blob.

Quando si crea lo snapshot, se --snapshot-blob non è specificato, il blob generato verrà scritto, per impostazione predefinita, in snapshot.blob nella directory di lavoro corrente. Altrimenti verrà scritto nel percorso specificato da --snapshot-blob.

$ echo "globalThis.foo = 'Vengo dallo snapshot'" > snapshot.js

# Esegui snapshot.js per inizializzare l'applicazione e fare lo snapshot {#run-snapshotjs-to-initialize-the-application-and-snapshot-the}
# del suo stato in snapshot.blob.
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js

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

# Carica lo snapshot generato e avvia l'applicazione da index.js. {#state-of-it-into-snapshotblob}
$ node --snapshot-blob snapshot.blob index.js
Vengo dallo snapshot

L'API v8.startupSnapshot può essere utilizzata per specificare un punto di ingresso al momento della creazione dello snapshot, evitando così la necessità di uno script di ingresso aggiuntivo al momento della deserializzazione:

$ echo "require('v8').startupSnapshot.setDeserializeMainFunction(() => console.log('Vengo dallo snapshot'))" > snapshot.js
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js
$ node --snapshot-blob snapshot.blob
Vengo dallo snapshot

Per ulteriori informazioni, consulta la documentazione dell'API v8.startupSnapshot.

Attualmente, il supporto per lo snapshot in fase di esecuzione è sperimentale in quanto:

--build-snapshot-config

Aggiunto in: v21.6.0, v20.12.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Specifica il percorso di un file di configurazione JSON che configura il comportamento di creazione dello snapshot.

Le seguenti opzioni sono attualmente supportate:

• builder <stringa> Obbligatorio. Fornisce il nome dello script che viene eseguito prima della creazione dello snapshot, come se fosse stato passato --build-snapshot con builder come nome dello script principale.
• withoutCodeCache <booleano> Opzionale. Includere la cache del codice riduce il tempo impiegato per compilare le funzioni incluse nello snapshot a scapito di una dimensione dello snapshot maggiore e potenzialmente interrompendo la portabilità dello snapshot.

Quando si utilizza questo flag, i file di script aggiuntivi forniti sulla riga di comando non verranno eseguiti e saranno invece interpretati come normali argomenti della riga di comando.

-c, --check

[Cronologia]

Versione	Modifiche
v10.0.0	L'opzione --require è ora supportata quando si controlla un file.
v5.0.0, v4.2.0	Aggiunto in: v5.0.0, v4.2.0

Controlla la sintassi dello script senza eseguirlo.

--completion-bash

Aggiunto in: v10.12.0

Stampa lo script di completamento bash sorgente per Node.js.

node --completion-bash > node_bash_completion
source node_bash_completion

-C condition, --conditions=condition

[Cronologia]

Versione	Modifiche
v22.9.0, v20.18.0	Il flag non è più sperimentale.
v14.9.0, v12.19.0	Aggiunto in: v14.9.0, v12.19.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Fornisci condizioni di risoluzione esportazioni condizionali personalizzate.

È consentito qualsiasi numero di nomi di condizioni di stringa personalizzati.

Le condizioni predefinite di Node.js di "node", "default", "import" e "require" verranno sempre applicate come definito.

Ad esempio, per eseguire un modulo con risoluzioni "development":

node -C development app.js

--cpu-prof

[Cronologia]

Versione	Modifiche
v22.4.0, v20.16.0	I flag --cpu-prof sono ora stabili.
v12.0.0	Aggiunto in: v12.0.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Avvia il profiler CPU V8 all'avvio e scrive il profilo CPU su disco prima dell'uscita.

Se --cpu-prof-dir non è specificato, il profilo generato viene inserito nella directory di lavoro corrente.

Se --cpu-prof-name non è specificato, il profilo generato viene denominato CPU.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.cpuprofile.

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

--cpu-prof-dir

[Cronologia]

Versione	Modifiche
v22.4.0, v20.16.0	I flag --cpu-prof sono ora stabili.
v12.0.0	Aggiunto in: v12.0.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Specifica la directory in cui verranno inseriti i profili CPU generati da --cpu-prof.

Il valore predefinito è controllato dall'opzione della riga di comando --diagnostic-dir.

--cpu-prof-interval

[Cronologia]

Versione	Cambiamenti
v22.4.0, v20.16.0	I flag --cpu-prof sono ora stabili.
v12.2.0	Aggiunto in: v12.2.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Specifica l'intervallo di campionamento in microsecondi per i profili CPU generati da --cpu-prof. Il valore predefinito è 1000 microsecondi.

--cpu-prof-name

[Cronologia]

Versione	Cambiamenti
v22.4.0, v20.16.0	I flag --cpu-prof sono ora stabili.
v12.0.0	Aggiunto in: v12.0.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Specifica il nome del file del profilo CPU generato da --cpu-prof.

--diagnostic-dir=directory

Imposta la directory in cui vengono scritti tutti i file di output diagnostici. Il valore predefinito è la directory di lavoro corrente.

Influenza la directory di output predefinita di:

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

--disable-proto=mode

Aggiunto in: v13.12.0, v12.17.0

Disabilita la proprietà Object.prototype.__proto__. Se mode è delete, la proprietà viene rimossa completamente. Se mode è throw, gli accessi alla proprietà lanciano un'eccezione con il codice ERR_PROTO_ACCESS.

--disable-warning=code-or-type

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sviluppo attivo

Aggiunto in: v21.3.0, v20.11.0

Disabilita avvisi di processo specifici per code o type.

Gli avvisi emessi da process.emitWarning() possono contenere un code e un type. Questa opzione non emetterà avvisi che hanno un code o un type corrispondente.

Elenco degli avvisi di deprecazione.

I tipi di avviso principali di Node.js sono: DeprecationWarning e ExperimentalWarning

Ad esempio, lo script seguente non emetterà DEP0025 require('node:sys') quando eseguito con node --disable-warning=DEP0025:

ESM

import sys from 'node:sys'

CJS

const sys = require('node:sys')

Ad esempio, lo script seguente emetterà DEP0025 require('node:sys'), ma non gli avvisi sperimentali (come ExperimentalWarning: vm.measureMemory è una funzionalità sperimentale in <=v21) quando eseguito con node --disable-warning=ExperimentalWarning:

ESM

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

vm.measureMemory()

CJS

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

vm.measureMemory()

--disable-wasm-trap-handler

Aggiunto in: v22.2.0, v20.15.0

Per impostazione predefinita, Node.js abilita i controlli di limiti di WebAssembly basati su trap handler. Di conseguenza, V8 non ha bisogno di inserire controlli di limiti in linea nel codice compilato da WebAssembly, il che può accelerare significativamente l'esecuzione di WebAssembly, ma questa ottimizzazione richiede l'allocazione di una grande area di memoria virtuale (attualmente 10 GB). Se il processo Node.js non ha accesso a uno spazio di indirizzamento di memoria virtuale sufficientemente grande a causa di configurazioni di sistema o limitazioni hardware, gli utenti non saranno in grado di eseguire alcun WebAssembly che comporti l'allocazione in questa area di memoria virtuale e visualizzeranno un errore di memoria insufficiente.

$ 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 disabilita questa ottimizzazione in modo che gli utenti possano almeno eseguire WebAssembly (con prestazioni meno ottimali) quando lo spazio di indirizzamento della memoria virtuale disponibile per il loro processo Node.js è inferiore a quello necessario per l'area di memoria WebAssembly V8.

--disallow-code-generation-from-strings

Aggiunto in: v9.8.0

Fa sì che le funzionalità linguistiche integrate come eval e new Function che generano codice da stringhe lancino un'eccezione. Ciò non influisce sul modulo Node.js node:vm.

--dns-result-order=order

[Cronologia]

Versione	Modifiche
v22.1.0, v20.13.0	Ora è supportato ipv6first.
v17.0.0	Il valore predefinito è stato modificato in verbatim.
v16.4.0, v14.18.0	Aggiunto in: v16.4.0, v14.18.0

Imposta il valore predefinito di order in dns.lookup() e dnsPromises.lookup(). Il valore può essere:

• ipv4first: imposta order predefinito su ipv4first.
• ipv6first: imposta order predefinito su ipv6first.
• verbatim: imposta order predefinito su verbatim.

Il valore predefinito è verbatim e dns.setDefaultResultOrder() ha una priorità maggiore rispetto a --dns-result-order.

--enable-fips

Aggiunto in: v6.0.0

Abilita la crittografia conforme a FIPS all'avvio. (Richiede che Node.js sia compilato con una libreria OpenSSL compatibile con FIPS.)

--enable-network-family-autoselection

Aggiunto in: v18.18.0

Abilita l'algoritmo di selezione automatica della famiglia a meno che le opzioni di connessione non lo disabilitino esplicitamente.

--enable-source-maps

[Cronologia]

Versione	Modifiche
v15.11.0, v14.18.0	Questa API non è più sperimentale.
v12.12.0	Aggiunto in: v12.12.0

Abilita il supporto per Source Map v3 per le tracce di stack.

Quando si utilizza un transpilatore, come TypeScript, le tracce di stack generate da un'applicazione fanno riferimento al codice transpilato, non alla posizione originale del codice sorgente. --enable-source-maps abilita la memorizzazione nella cache delle Source Map e fa del suo meglio per riportare le tracce di stack relative al file sorgente originale.

La sovrascrittura di Error.prepareStackTrace potrebbe impedire a --enable-source-maps di modificare la traccia di stack. Chiama e restituisci i risultati dell'originale Error.prepareStackTrace nella funzione di sovrascrittura per modificare la traccia di stack con le source map.

const originalPrepareStackTrace = Error.prepareStackTrace
Error.prepareStackTrace = (error, trace) => {
  // Modifica error e trace e formatta la traccia di stack con
  // l'originale Error.prepareStackTrace.
  return originalPrepareStackTrace(error, trace)
}

Nota, l'abilitazione delle source map può introdurre latenza nella tua applicazione quando si accede a Error.stack. Se accedi frequentemente a Error.stack nella tua applicazione, prendi in considerazione le implicazioni sulle prestazioni di --enable-source-maps.

--entry-url

Aggiunto in: v23.0.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Quando presente, Node.js interpreterà il punto di ingresso come un URL, piuttosto che un percorso.

Segue le regole di risoluzione dei moduli ECMAScript.

Qualsiasi parametro di query o hash nell'URL sarà accessibile tramite import.meta.url.

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

--env-file-if-exists=config

Aggiunto in: v22.9.0

Il comportamento è lo stesso di --env-file, ma non viene generato un errore se il file non esiste.

--env-file=config

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

[Cronologia]

Versione	Modifiche
v21.7.0, v20.12.0	Aggiunto il supporto per valori multilinea.
v20.6.0	Aggiunto in: v20.6.0

Carica le variabili d'ambiente da un file relativo alla directory corrente, rendendole disponibili alle applicazioni su process.env. Le variabili d'ambiente che configurano Node.js, come NODE_OPTIONS, vengono analizzate e applicate. Se la stessa variabile è definita nell'ambiente e nel file, il valore dell'ambiente ha la precedenza.

È possibile passare più argomenti --env-file. I file successivi sovrascrivono le variabili preesistenti definite nei file precedenti.

Viene generato un errore se il file non esiste.

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

Il formato del file deve essere una riga per coppia chiave-valore di nome della variabile d'ambiente e valore separati da =:

PORT=3000

Qualsiasi testo dopo un # viene considerato un commento:

# Questo è un commento {#--env-file=config}
PORT=3000 # Anche questo è un commento

I valori possono iniziare e terminare con le seguenti virgolette: ```, "o'. Vengono omessi dai valori.

USERNAME="nodejs" # risulterà in `nodejs` come valore.

Sono supportati valori multilinea:

MULTI_LINE="QUESTO È
UN MULTILINEA"
# risulterà in `QUESTO È\nUN MULTILINEA` come valore. {#this-is-a-comment}

La parola chiave export prima di una chiave viene ignorata:

export USERNAME="nodejs" # risulterà in `nodejs` come valore.

Se si desidera caricare variabili d'ambiente da un file che potrebbe non esistere, è possibile utilizzare invece il flag --env-file-if-exists.

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

[Cronologia]

Versione	Modifiche
v22.6.0	Eval ora supporta la rimozione sperimentale dei tipi.
v5.11.0	Le librerie integrate sono ora disponibili come variabili predefinite.
v0.5.2	Aggiunto in: v0.5.2

Valuta il seguente argomento come JavaScript. I moduli predefiniti nel REPL possono essere utilizzati anche in script.

Su Windows, usando cmd.exe, un singolo apice non funzionerà correttamente perché riconosce solo il doppio apice " per le virgolette. In Powershell o Git bash, sono utilizzabili sia ' che ".

È possibile eseguire codice contenente tipi inline passando --experimental-strip-types.

--experimental-async-context-frame

Aggiunto in: v22.7.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Abilita l'uso di AsyncLocalStorage supportato da AsyncContextFrame anziché l'implementazione predefinita che si basa su async_hooks. Questo nuovo modello è implementato in modo molto diverso e quindi potrebbe presentare differenze nel modo in cui i dati di contesto fluiscono all'interno dell'applicazione. Pertanto, si raccomanda attualmente di assicurarsi che il comportamento dell'applicazione non sia influenzato da questa modifica prima di utilizzarla in produzione.

--experimental-eventsource

Aggiunto in: v22.3.0, v20.18.0

Abilita l'esposizione dell'EventSource Web API nell'ambito globale.

--experimental-import-meta-resolve

[Cronologia]

Versione	Modifiche
v20.6.0, v18.19.0	import.meta.resolve sincrono reso disponibile di default, con il flag mantenuto per abilitare il secondo argomento sperimentale come supportato in precedenza.
v13.9.0, v12.16.2	Aggiunto in: v13.9.0, v12.16.2

Abilita il supporto sperimentale dell'URL parent di import.meta.resolve(), che consente di passare un secondo argomento parentURL per la risoluzione contestuale.

In precedenza controllava l'intera funzionalità import.meta.resolve.

--experimental-loader=module

[Cronologia]

Versione	Modifiche
v12.11.1	Questo flag è stato rinominato da --loader a --experimental-loader.
v8.8.0	Aggiunto in: v8.8.0

Specifica il module contenente gli agganci di personalizzazione dei moduli esportati. module può essere qualsiasi stringa accettata come specificatore di import.

--experimental-network-inspection

Aggiunto in: v22.6.0, v20.18.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Abilita il supporto sperimentale per l'ispezione di rete con Chrome DevTools.

--experimental-print-required-tla

Aggiunto in: v22.0.0, v20.17.0

Se il modulo ES che viene require() contiene await di livello superiore, questo flag consente a Node.js di valutare il modulo, cercare di individuare gli await di livello superiore e stampare la loro posizione per aiutare gli utenti a trovarli.

--experimental-require-module

[Cronologia]

Versione	Modifiche
v23.0.0	Questo è ora vero per impostazione predefinita.
v22.0.0, v20.17.0	Aggiunto in: v22.0.0, v20.17.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sviluppo Attivo

Supporta il caricamento di un grafico di moduli ES sincrono in require().

Vedi Caricamento di moduli ECMAScript utilizzando require().

--experimental-sea-config

Aggiunto in: v20.0.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Utilizzare questo flag per generare un blob che può essere iniettato nel binario di Node.js per produrre una singola applicazione eseguibile. Vedere la documentazione su questa configurazione per i dettagli.

--experimental-shadow-realm

Aggiunto in: v19.0.0, v18.13.0

Usa questo flag per abilitare il supporto per ShadowRealm.

--experimental-strip-types

Aggiunto in: v22.6.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

Abilita lo stripping sperimentale dei tipi per i file TypeScript. Per ulteriori informazioni, consulta la documentazione sullo stripping dei tipi TypeScript.

--experimental-test-coverage

[Cronologia]

Versione	Cambiamenti
v20.1.0, v18.17.0	Questa opzione può essere utilizzata con --test.
v19.7.0, v18.15.0	Aggiunto in: v19.7.0, v18.15.0

Quando utilizzato in combinazione con il modulo node:test, viene generato un report sulla copertura del codice come parte dell'output dell'esecutore di test. Se non vengono eseguiti test, non viene generato un report sulla copertura. Consulta la documentazione sulla raccolta della copertura del codice dai test per maggiori dettagli.

--experimental-test-isolation=mode

Aggiunto in: v22.8.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.0 - Fase iniziale di sviluppo

Configura il tipo di isolamento dei test utilizzato nell'esecutore di test. Quando mode è 'process', ogni file di test viene eseguito in un processo figlio separato. Quando mode è 'none', tutti i file di test vengono eseguiti nello stesso processo dell'esecutore di test. La modalità di isolamento predefinita è 'process'. Questo flag viene ignorato se il flag --test non è presente. Consulta la sezione modello di esecuzione dell'esecutore di test per maggiori informazioni.

--experimental-test-module-mocks

Aggiunto in: v22.3.0, v20.18.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.0 - Fase iniziale di sviluppo

Abilita il mocking dei moduli nell'esecutore di test.

--experimental-transform-types

Aggiunto in: v22.7.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabile: 1.1 - Sviluppo attivo

Abilita la trasformazione della sintassi esclusiva di TypeScript in codice JavaScript. Implica --experimental-strip-types e --enable-source-maps.

--experimental-vm-modules

Aggiunto in: v9.6.0

Abilita il supporto sperimentale ai moduli ES nel modulo node:vm.

--experimental-wasi-unstable-preview1

[Cronologia]

Versione	Modifiche
v20.0.0, v18.17.0	Questa opzione non è più richiesta poiché WASI è abilitato per impostazione predefinita, ma può comunque essere passata.
v13.6.0	modificato da --experimental-wasi-unstable-preview0 a --experimental-wasi-unstable-preview1.
v13.3.0, v12.16.0	Aggiunto in: v13.3.0, v12.16.0

Abilita il supporto sperimentale di WebAssembly System Interface (WASI).

--experimental-wasm-modules

Aggiunto in: v12.3.0

Abilita il supporto sperimentale ai moduli WebAssembly.

--experimental-webstorage

Aggiunto in: v22.4.0

Abilita il supporto sperimentale di Web Storage.

--expose-gc

Aggiunto in: v22.3.0, v20.18.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabile: 1 - Sperimentale. Questo flag è ereditato da V8 ed è soggetto a modifiche a monte.

Questo flag esporrà l'estensione gc da V8.

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

--force-context-aware

Aggiunto in: v12.12.0

Disabilita il caricamento di addon nativi che non sono context-aware.

--force-fips

Aggiunto in: v6.0.0

Forza la crittografia conforme a FIPS all'avvio. (Non può essere disabilitato dal codice script.) (Stessi requisiti di --enable-fips.)

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

Aggiunto in: v18.3.0, v16.17.0

Impone l'evento uncaughtException sui callback asincroni di Node-API.

Per evitare che un componente aggiuntivo esistente blocchi il processo, questo flag non è abilitato per impostazione predefinita. In futuro, questo flag sarà abilitato per impostazione predefinita per imporre il comportamento corretto.

--frozen-intrinsics

Aggiunto in: v11.12.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Abilita intrinseci congelati sperimentali come Array e Object.

È supportato solo il contesto radice. Non vi è alcuna garanzia che globalThis.Array sia effettivamente il riferimento intrinseco predefinito. Il codice potrebbe non funzionare con questo flag.

Per consentire l'aggiunta di polyfill, sia --require che --import vengono eseguiti prima del congelamento degli intrinseci.

--heap-prof

[Cronologia]

Versione	Modifiche
v22.4.0, v20.16.0	I flag --heap-prof ora sono stabili.
v12.4.0	Aggiunto in: v12.4.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Avvia il profiler heap V8 all'avvio e scrive il profilo heap su disco prima dell'uscita.

Se non viene specificato --heap-prof-dir, il profilo generato viene inserito nella directory di lavoro corrente.

Se non viene specificato --heap-prof-name, il profilo generato viene denominato Heap.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.heapprofile.

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

--heap-prof-dir

[Cronologia]

Versione	Modifiche
v22.4.0, v20.16.0	I flag --heap-prof ora sono stabili.
v12.4.0	Aggiunto in: v12.4.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Specifica la directory in cui verranno inseriti i profili heap generati da --heap-prof.

Il valore predefinito è controllato dall'opzione della riga di comando --diagnostic-dir.

--heap-prof-interval

[Cronologia]

Versione	Modifiche
v22.4.0, v20.16.0	I flag --heap-prof ora sono stabili.
v12.4.0	Aggiunto in: v12.4.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Specifica l'intervallo di campionamento medio in byte per i profili heap generati da --heap-prof. Il valore predefinito è 512 * 1024 byte.

--heap-prof-name

[Cronologia]

Versione	Modifiche
v22.4.0, v20.16.0	I flag --heap-prof sono ora stabili.
v12.4.0	Aggiunto in: v12.4.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Specifica il nome del file del profilo heap generato da --heap-prof.

--heapsnapshot-near-heap-limit=max_count

Aggiunto in: v15.1.0, v14.18.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Scrive uno snapshot dell'heap V8 su disco quando l'utilizzo dell'heap V8 si sta avvicinando al limite dell'heap. count dovrebbe essere un intero non negativo (nel qual caso Node.js non scriverà più di max_count snapshot su disco).

Quando vengono generati snapshot, la garbage collection potrebbe essere attivata e ridurre l'utilizzo dell'heap. Pertanto, è possibile che vengano scritti più snapshot su disco prima che l'istanza di Node.js esaurisca definitivamente la memoria. Questi snapshot dell'heap possono essere confrontati per determinare quali oggetti vengono allocati durante il periodo in cui vengono acquisiti gli snapshot consecutivi. Non è garantito che Node.js scriva esattamente max_count snapshot su disco, ma farà del suo meglio per generare almeno uno e fino a max_count snapshot prima che l'istanza di Node.js esaurisca la memoria quando max_count è maggiore di 0.

La generazione di snapshot V8 richiede tempo e memoria (sia memoria gestita dall'heap V8 che memoria nativa al di fuori dell'heap V8). Più grande è l'heap, più risorse sono necessarie. Node.js regolerà l'heap V8 per accogliere l'overhead di memoria aggiuntivo dell'heap V8 e farà del suo meglio per evitare di utilizzare tutta la memoria disponibile per il processo. Quando il processo utilizza più memoria di quanto il sistema ritenga appropriato, il processo può essere terminato bruscamente dal sistema, a seconda della configurazione del sistema.

$ 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

<--- Ultimi pochi GC --->

[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) fallimento dell'allocazione la garbage collection potrebbe non avere successo
[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) fallimento dell'allocazione la garbage collection potrebbe non avere successo


<--- Stacktrace JS --->

ERRORE FATALE: Mark-compacts inefficaci vicino al limite dell'heap Allocazione fallita - heap JavaScript esaurito
....

--heapsnapshot-signal=signal

Aggiunto in: v12.0.0

Abilita un gestore di segnali che fa sì che il processo Node.js scriva un dump dell'heap quando viene ricevuto il segnale specificato. signal deve essere un nome di segnale valido. Disabilitato per impostazione predefinita.

$ 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

Aggiunto in: v0.1.3

Stampa le opzioni da riga di comando di node. L'output di questa opzione è meno dettagliato di questo documento.

--icu-data-dir=file

Aggiunto in: v0.11.15

Specifica il percorso di caricamento dei dati ICU. (Sovrascrive NODE_ICU_DATA.)

--import=module

Aggiunto in: v19.0.0, v18.18.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Precarica il modulo specificato all'avvio. Se il flag viene fornito più volte, ogni modulo verrà eseguito in sequenza nell'ordine in cui compaiono, a partire da quelli forniti in NODE_OPTIONS.

Segue le regole di risoluzione dei moduli ECMAScript. Utilizzare --require per caricare un modulo CommonJS. I moduli precaricati con --require verranno eseguiti prima dei moduli precaricati con --import.

I moduli vengono precaricati nel thread principale così come in qualsiasi thread di worker, processi forkati o processi in cluster.

--input-type=type

Aggiunto in: v12.0.0

Questo configura Node.js per interpretare l'input --eval o STDIN come CommonJS o come modulo ES. I valori validi sono "commonjs" o "module". Il valore predefinito è "commonjs".

La REPL non supporta questa opzione. L'utilizzo di --input-type=module con --print genererà un errore, poiché --print non supporta la sintassi del modulo ES.

--insecure-http-parser

Aggiunto in: v13.4.0, v12.15.0, v10.19.0

Abilita i flag di tolleranza nel parser HTTP. Ciò potrebbe consentire l'interoperabilità con implementazioni HTTP non conformi.

Quando abilitato, il parser accetterà quanto segue:

• Valori di intestazione HTTP non validi.
• Versioni HTTP non valide.
• Consentire messaggi contenenti sia le intestazioni Transfer-Encoding che Content-Length.
• Consentire dati extra dopo il messaggio quando è presente Connection: close.
• Consentire codifiche di trasferimento aggiuntive dopo che chunked è stato fornito.
• Consentire l'utilizzo di \n come separatore di token invece di \r\n.
• Consentire che \r\n non venga fornito dopo un chunk.
• Consentire la presenza di spazi dopo la dimensione di un chunk e prima di \r\n.

Tutto quanto sopra esporrà la tua applicazione ad attacchi di contrabbando o avvelenamento delle richieste. Evita di utilizzare questa opzione.

Attenzione: associare l'ispettore a una combinazione IP:porta pubblica non è sicuro

Associare l'ispettore a un IP pubblico (incluso 0.0.0.0) con una porta aperta non è sicuro, poiché consente a host esterni di connettersi all'ispettore ed eseguire un attacco di esecuzione di codice remoto.

Se specifichi un host, assicurati che:

• L'host non sia accessibile da reti pubbliche.
• Un firewall blocchi le connessioni indesiderate sulla porta.

Più specificamente, --inspect=0.0.0.0 non è sicuro se la porta (9229 di default) non è protetta da firewall.

Consulta la sezione implicazioni sulla sicurezza del debug per maggiori informazioni.

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

Aggiunto in: v7.6.0

Attiva l'ispettore su host:porta e interrompe all'inizio dello script utente. Il host:porta predefinito è 127.0.0.1:9229. Se viene specificata la porta 0, verrà utilizzata una porta disponibile casuale.

Consulta Integrazione dell'ispettore V8 per Node.js per ulteriori spiegazioni sul debugger di Node.js.

--inspect-port=[host:]port

Aggiunto in: v7.6.0

Imposta host:porta da utilizzare quando l'ispettore è attivato. Utile quando si attiva l'ispettore inviando il segnale SIGUSR1.

L'host predefinito è 127.0.0.1. Se viene specificata la porta 0, verrà utilizzata una porta disponibile casuale.

Consulta l'avviso di sicurezza di seguito riguardo l'utilizzo del parametro host.

--inspect-publish-uid=stderr,http

Specifica i modi in cui viene esposto l'URL del websocket dell'inspector.

Di default, l'URL del websocket dell'inspector è disponibile in stderr e sotto l'endpoint /json/list su http://host:port/json/list.

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

Aggiunto in: v22.2.0, v20.15.0

Attiva l'inspector su host:port e aspetta che venga collegato un debugger. Il host:port predefinito è 127.0.0.1:9229. Se viene specificata la porta 0, verrà utilizzata una porta disponibile casuale.

Vedi Integrazione di V8 Inspector per Node.js per ulteriori spiegazioni sul debugger di Node.js.

--inspect[=[host:]port]

Aggiunto in: v6.3.0

Attiva l'inspector su host:port. Il valore predefinito è 127.0.0.1:9229. Se viene specificata la porta 0, verrà utilizzata una porta disponibile casuale.

L'integrazione di V8 Inspector consente a strumenti come Chrome DevTools e IDE di eseguire il debug e profilare istanze di Node.js. Gli strumenti si collegano alle istanze di Node.js tramite una porta TCP e comunicano utilizzando il Chrome DevTools Protocol. Vedi Integrazione di V8 Inspector per Node.js per ulteriori spiegazioni sul debugger di Node.js.

-i, --interactive

Aggiunto in: v0.7.7

Apre la REPL anche se stdin non sembra essere un terminale.

--jitless

Aggiunto in: v12.0.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale. Questo flag è ereditato da V8 ed è soggetto a modifiche upstream.

Disabilita l'allocazione runtime di memoria eseguibile. Ciò potrebbe essere necessario su alcune piattaforme per motivi di sicurezza. Può anche ridurre la superficie di attacco su altre piattaforme, ma l'impatto sulle prestazioni potrebbe essere grave.

--localstorage-file=file

Aggiunto in: v22.4.0

Il file utilizzato per memorizzare i dati di localStorage. Se il file non esiste, viene creato la prima volta che si accede a localStorage. Lo stesso file può essere condiviso tra più processi Node.js contemporaneamente. Questo flag non ha effetto a meno che Node.js non venga avviato con il flag --experimental-webstorage.

--max-http-header-size=dimensione

[Cronologia]

Versione	Modifiche
v13.13.0	Modificata la dimensione predefinita massima degli header HTTP da 8 KiB a 16 KiB.
v11.6.0, v10.15.0	Aggiunto in: v11.6.0, v10.15.0

Specifica la dimensione massima, in byte, degli header HTTP. Il valore predefinito è 16 KiB.

--napi-modules

Aggiunto in: v7.10.0

Questa opzione non ha alcun effetto. È mantenuta per compatibilità.

--network-family-autoselection-attempt-timeout

Aggiunto in: v22.1.0, v20.13.0

Imposta il valore predefinito per il timeout del tentativo di selezione automatica della famiglia di rete. Per ulteriori informazioni, vedere net.getDefaultAutoSelectFamilyAttemptTimeout().

--no-addons

Aggiunto in: v16.10.0, v14.19.0

Disabilita la condizione di esportazione node-addons e disabilita il caricamento di addon nativi. Quando viene specificato --no-addons, la chiamata a process.dlopen o la richiesta di un addon C++ nativo falliranno e genereranno un'eccezione.

--no-deprecation

Aggiunto in: v0.8.0

Silenzia gli avvisi di deprecazione.

--no-experimental-detect-module

[Cronologia]

Versione	Modifiche
v22.7.0	Il rilevamento della sintassi è abilitato per impostazione predefinita.
v21.1.0, v20.10.0	Aggiunto in: v21.1.0, v20.10.0

Disabilita l'uso del rilevamento della sintassi per determinare il tipo di modulo.

--no-experimental-global-navigator

Aggiunto in: v21.2.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Disabilita l'esposizione dell'API Navigator nell'ambito globale.

--no-experimental-repl-await

Aggiunto in: v16.6.0

Utilizza questo flag per disabilitare top-level await in REPL.

--no-experimental-require-module

[Cronologia]

Versione	Modifiche
v23.0.0	Ora questo è false per impostazione predefinita.
v22.0.0, v20.17.0	Aggiunto in: v22.0.0, v20.17.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo Attivo

Disabilita il supporto per il caricamento di un grafo di moduli ES sincrono in require().

Vedere Caricamento dei moduli ECMAScript utilizzando require().

--no-experimental-sqlite

[Cronologia]

Versione	Modifiche
v23.4.0	SQLite non è più contrassegnato come sperimentale, ma lo è ancora.
v22.5.0	Aggiunto in: v22.5.0

Disabilita il modulo sperimentale node:sqlite.

--no-experimental-websocket

Aggiunto in: v22.0.0

Disabilita l'esposizione di WebSocket nello scope globale.

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

Aggiunto in: v17.0.0

Nasconde informazioni aggiuntive in caso di eccezione fatale che causa l'uscita.

--no-force-async-hooks-checks

Aggiunto in: v9.0.0

Disabilita i controlli di runtime per async_hooks. Questi saranno comunque abilitati dinamicamente quando async_hooks è abilitato.

--no-global-search-paths

Aggiunto in: v16.10.0

Non cercare moduli da percorsi globali come $HOME/.node_modules e $NODE_PATH.

--no-network-family-autoselection

[Cronologia]

Versione	Modifiche
v20.0.0	Il flag è stato rinominato da --no-enable-network-family-autoselection a --no-network-family-autoselection. Il vecchio nome può ancora funzionare come alias.
v19.4.0	Aggiunto in: v19.4.0

Disabilita l'algoritmo di selezione automatica della famiglia a meno che le opzioni di connessione non lo abilitino esplicitamente.

--no-warnings

Aggiunto in: v6.0.0

Disattiva tutti gli avvisi del processo (incluse le deprecazioni).

--node-memory-debug

Aggiunto in: v15.0.0, v14.18.0

Abilita controlli di debug aggiuntivi per le perdite di memoria all'interno di Node.js. Questo è solitamente utile solo per gli sviluppatori che eseguono il debug di Node.js stesso.

--openssl-config=file

Aggiunto in: v6.9.0

Carica un file di configurazione OpenSSL all'avvio. Tra gli altri usi, questo può essere usato per abilitare la crittografia conforme a FIPS se Node.js è compilato con OpenSSL abilitato FIPS.

--openssl-legacy-provider

Aggiunto in: v17.0.0, v16.17.0

Abilita il provider legacy di OpenSSL 3.0. Per maggiori informazioni si prega di consultare OSSL_PROVIDER-legacy.

--openssl-shared-config

Aggiunto in: v18.5.0, v16.17.0, v14.21.0

Abilita la sezione di configurazione predefinita di OpenSSL, openssl_conf, da leggere dal file di configurazione di OpenSSL. Il file di configurazione predefinito è denominato openssl.cnf, ma può essere modificato utilizzando la variabile d'ambiente OPENSSL_CONF o utilizzando l'opzione della riga di comando --openssl-config. La posizione del file di configurazione predefinito di OpenSSL dipende da come OpenSSL è collegato a Node.js. La condivisione della configurazione di OpenSSL può avere implicazioni indesiderate ed è consigliabile utilizzare una sezione di configurazione specifica per Node.js che è nodejs_conf ed è predefinita quando questa opzione non viene utilizzata.

--pending-deprecation

Aggiunto in: v8.0.0

Emette avvisi di deprecazione in sospeso.

Le deprecazioni in sospeso sono generalmente identiche a una deprecazione di runtime con la notevole eccezione che sono disattivate di default e non verranno emesse a meno che non venga impostato il flag della riga di comando --pending-deprecation o la variabile d'ambiente NODE_PENDING_DEPRECATION=1. Le deprecazioni in sospeso vengono utilizzate per fornire una sorta di meccanismo selettivo di "preallarme" che gli sviluppatori possono sfruttare per rilevare l'utilizzo di API deprecate.

--permission

[Cronologia]

Versione	Modifiche
v23.5.0	Il modello di autorizzazioni è ora stabile.
v20.0.0	Aggiunto in: v20.0.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile.

Abilita il Modello di autorizzazioni per il processo corrente. Quando abilitato, le seguenti autorizzazioni sono limitate:

• File System - gestibile tramite i flag --allow-fs-read, --allow-fs-write
• Processo figlio - gestibile tramite il flag --allow-child-process
• Thread di worker - gestibile tramite il flag --allow-worker
• WASI - gestibile tramite il flag --allow-wasi
• Add-on - gestibile tramite il flag --allow-addons

--preserve-symlinks

Aggiunto in: v6.3.0

Istruisce il caricatore di moduli a preservare i collegamenti simbolici durante la risoluzione e la memorizzazione nella cache dei moduli.

Di default, quando Node.js carica un modulo da un percorso collegato simbolicamente a una posizione diversa sul disco, Node.js dereferenzia il collegamento e utilizza il "percorso reale" effettivo del modulo sul disco sia come identificatore che come percorso principale per individuare altri moduli di dipendenza. Nella maggior parte dei casi, questo comportamento di default è accettabile. Tuttavia, quando si utilizzano dipendenze peer collegate simbolicamente, come illustrato nell'esempio seguente, il comportamento di default causa il lancio di un'eccezione se moduleA tenta di richiedere moduleB come dipendenza peer:

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

Il flag della riga di comando --preserve-symlinks istruisce Node.js a utilizzare il percorso del collegamento simbolico per i moduli anziché il percorso reale, consentendo la ricerca delle dipendenze peer collegate simbolicamente.

Si noti, tuttavia, che l'utilizzo di --preserve-symlinks può avere altri effetti collaterali. In particolare, i moduli nativi collegati simbolicamente potrebbero non essere caricati se sono collegati da più posizioni nell'albero delle dipendenze (Node.js li vedrebbe come due moduli separati e tenterebbe di caricare il modulo più volte, causando il lancio di un'eccezione).

Il flag --preserve-symlinks non si applica al modulo principale, il che consente a node --preserve-symlinks node_module/.bin/\<foo\> di funzionare. Per applicare lo stesso comportamento al modulo principale, utilizzare anche --preserve-symlinks-main.

--preserve-symlinks-main

Aggiunto in: v10.2.0

Istruisce il caricatore di moduli a preservare i collegamenti simbolici durante la risoluzione e la memorizzazione nella cache del modulo principale (require.main).

Questo flag esiste in modo che il modulo principale possa aderire allo stesso comportamento che --preserve-symlinks fornisce a tutte le altre importazioni; sono flag separati, tuttavia, per la compatibilità con le versioni precedenti di Node.js.

--preserve-symlinks-main non implica --preserve-symlinks; usa --preserve-symlinks-main in aggiunta a --preserve-symlinks quando non è desiderabile seguire i collegamenti simbolici prima di risolvere i percorsi relativi.

Vedi --preserve-symlinks per maggiori informazioni.

-p, --print "script"

[Cronologia]

Versione	Modifiche
v5.11.0	Le librerie integrate sono ora disponibili come variabili predefinite.
v0.6.4	Aggiunto in: v0.6.4

Identico a -e ma stampa il risultato.

--prof

Aggiunto in: v2.0.0

Genera l'output del profiler V8.

--prof-process

Aggiunto in: v5.2.0

Elabora l'output del profiler V8 generato usando l'opzione V8 --prof.

--redirect-warnings=file

Aggiunto in: v8.0.0

Scrive gli avvisi di processo nel file indicato invece di stamparli su stderr. Il file verrà creato se non esiste e verrà accodato ad esso se esiste già. Se si verifica un errore durante il tentativo di scrivere l'avviso nel file, l'avviso verrà scritto invece su stderr.

Il nome del file può essere un percorso assoluto. Se non lo è, la directory predefinita in cui verrà scritto è controllata dall'opzione della riga di comando --diagnostic-dir.

--report-compact

Aggiunto in: v13.12.0, v12.17.0

Scrive i report in un formato compatto, JSON a riga singola, più facilmente consumabile dai sistemi di elaborazione dei log rispetto al formato predefinito multilinea progettato per il consumo umano.

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

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa opzione non è più sperimentale.
v12.0.0	Modificato da --diagnostic-report-directory a --report-directory.
v11.8.0	Aggiunto in: v11.8.0

Posizione in cui verrà generato il report.

--report-exclude-env

Aggiunto in: v23.3.0

Quando viene passato --report-exclude-env, il report diagnostico generato non conterrà i dati environmentVariables.

--report-exclude-network

Aggiunto in: v22.0.0, v20.13.0

Esclude header.networkInterfaces dal report diagnostico. Per impostazione predefinita, questa opzione non è impostata e le interfacce di rete sono incluse.

--report-filename=filename

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa opzione non è più sperimentale.
v12.0.0	Modificato da --diagnostic-report-filename a --report-filename.
v11.8.0	Aggiunto in: v11.8.0

Nome del file in cui verrà scritto il report.

Se il nome del file è impostato su 'stdout' o 'stderr', il report viene scritto rispettivamente nello stdout o nell'stderr del processo.

--report-on-fatalerror

[Cronologia]

Versione	Modifiche
v14.0.0, v13.14.0, v12.17.0	Questa opzione non è più sperimentale.
v12.0.0	Modificato da --diagnostic-report-on-fatalerror a --report-on-fatalerror.
v11.8.0	Aggiunto in: v11.8.0

Abilita l'attivazione del report in caso di errori fatali (errori interni all'interno del runtime di Node.js come esaurimento della memoria) che portano alla terminazione dell'applicazione. Utile per ispezionare vari elementi di dati diagnostici come heap, stack, stato del ciclo di eventi, consumo di risorse ecc. per comprendere l'errore fatale.

--report-on-signal

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa opzione non è più sperimentale.
v12.0.0	Modificato da --diagnostic-report-on-signal a --report-on-signal.
v11.8.0	Aggiunto in: v11.8.0

Abilita la generazione di report al ricevimento del segnale specificato (o predefinito) al processo Node.js in esecuzione. Il segnale per attivare il report viene specificato tramite --report-signal.

--report-signal=signal

[Cronologia]

Versione	Modifiche
v13.12.0, v12.17.0	Questa opzione non è più sperimentale.
v12.0.0	Modificato da --diagnostic-report-signal a --report-signal.
v11.8.0	Aggiunto in: v11.8.0

Imposta o reimposta il segnale per la generazione di report (non supportato su Windows). Il segnale predefinito è SIGUSR2.

--report-uncaught-exception

[Cronologia]

Versione	Modifiche
v18.8.0, v16.18.0	Il report non viene generato se l'eccezione non gestita viene gestita.
v13.12.0, v12.17.0	Questa opzione non è più sperimentale.
v12.0.0	modificato da --diagnostic-report-uncaught-exception a --report-uncaught-exception.
v11.8.0	Aggiunto in: v11.8.0

Abilita la generazione di un report quando il processo termina a causa di un'eccezione non gestita. Utile quando si ispeziona lo stack JavaScript in combinazione con lo stack nativo e altri dati dell'ambiente di runtime.

-r, --require module

Aggiunto in: v1.6.0

Precarica il modulo specificato all'avvio.

Segue le regole di risoluzione dei moduli di require(). module può essere un percorso a un file o un nome di modulo Node.

Sono supportati solo i moduli CommonJS. Utilizzare --import per precaricare un modulo ECMAScript. I moduli precaricati con --require verranno eseguiti prima dei moduli precaricati con --import.

I moduli vengono precaricati nel thread principale e in qualsiasi thread di lavoro, processi fork o processi in cluster.

--run

[Cronologia]

Versione	Modifiche
v22.3.0	Aggiunta la variabile d'ambiente NODE_RUN_SCRIPT_NAME.
v22.3.0	Aggiunta la variabile d'ambiente NODE_RUN_PACKAGE_JSON_PATH.
v22.3.0	Attraversa fino alla directory radice e trova un file package.json da cui eseguire il comando e aggiorna la variabile d'ambiente PATH di conseguenza.
v22.0.0	Aggiunto in: v22.0.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Questo esegue un comando specificato dall'oggetto "scripts" di un package.json. Se viene fornito un "command" mancante, elencherà gli script disponibili.

--run attraversa fino alla directory radice e trova un file package.json da cui eseguire il comando.

--run antepone ./node_modules/.bin per ogni antenato della directory corrente, al PATH per eseguire i binari da diverse cartelle in cui sono presenti più directory node_modules, se ancestor-folder/node_modules/.bin è una directory.

--run esegue il comando nella directory contenente il package.json correlato.

Ad esempio, il seguente comando eseguirà lo script test del package.json nella cartella corrente:

$ node --run test

Puoi anche passare argomenti al comando. Qualsiasi argomento dopo -- verrà accodato allo script:

$ node --run test -- --verbose

Limitazioni intenzionali

node --run non è pensato per corrispondere ai comportamenti di npm run o dei comandi run di altri gestori di pacchetti. L'implementazione di Node.js è intenzionalmente più limitata, al fine di concentrarsi sulle massime prestazioni per i casi d'uso più comuni. Alcune funzionalità di altre implementazioni run che sono intenzionalmente escluse sono:

• Esecuzione di script pre o post in aggiunta allo script specificato.
• Definizione di variabili d'ambiente specifiche del gestore di pacchetti.

Variabili d'ambiente

Le seguenti variabili d'ambiente vengono impostate quando si esegue uno script con --run:

• NODE_RUN_SCRIPT_NAME: Il nome dello script in esecuzione. Ad esempio, se --run viene utilizzato per eseguire test, il valore di questa variabile sarà test.
• NODE_RUN_PACKAGE_JSON_PATH: Il percorso del file package.json che viene elaborato.

--secure-heap-min=n

Aggiunto in: v15.6.0

Quando si utilizza --secure-heap, il flag --secure-heap-min specifica l'allocazione minima dall'heap sicuro. Il valore minimo è 2. Il valore massimo è il minore tra --secure-heap e 2147483647. Il valore fornito deve essere una potenza di due.

--secure-heap=n

Aggiunto in: v15.6.0

Inizializza un heap sicuro OpenSSL di n byte. Quando inizializzato, l'heap sicuro viene utilizzato per tipi selezionati di allocazioni all'interno di OpenSSL durante la generazione di chiavi e altre operazioni. Ciò è utile, ad esempio, per impedire la fuoriuscita di informazioni sensibili a causa di overflow o underflow di puntatori.

L'heap sicuro ha una dimensione fissa e non può essere ridimensionato in fase di esecuzione, quindi, se utilizzato, è importante selezionare un heap sufficientemente grande da coprire tutti gli usi dell'applicazione.

La dimensione dell'heap fornita deve essere una potenza di due. Qualsiasi valore inferiore a 2 disabiliterà l'heap sicuro.

L'heap sicuro è disabilitato di default.

L'heap sicuro non è disponibile su Windows.

Vedi CRYPTO_secure_malloc_init per maggiori dettagli.

--snapshot-blob=path

Aggiunto in: v18.8.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Quando utilizzato con --build-snapshot, --snapshot-blob specifica il percorso in cui viene scritto il blob di snapshot generato. Se non specificato, il blob generato viene scritto in snapshot.blob nella directory di lavoro corrente.

Quando utilizzato senza --build-snapshot, --snapshot-blob specifica il percorso del blob che viene utilizzato per ripristinare lo stato dell'applicazione.

Quando carica uno snapshot, Node.js verifica che:

Se non corrispondono, Node.js rifiuta di caricare lo snapshot ed esce con codice di stato 1.

--test

[Cronologia]

Versione	Modifiche
v20.0.0	Il runner di test è ora stabile.
v19.2.0, v18.13.0	Il runner di test ora supporta l'esecuzione in modalità watch.
v18.1.0, v16.17.0	Aggiunto in: v18.1.0, v16.17.0

Avvia il runner di test a riga di comando di Node.js. Questo flag non può essere combinato con --watch-path, --check, --eval, --interactive o l'ispettore. Per maggiori dettagli, consulta la documentazione sull'esecuzione dei test dalla riga di comando.

--test-concurrency

Aggiunto in: v21.0.0, v20.10.0, v18.19.0

Il numero massimo di file di test che la CLI del runner di test eseguirà in contemporanea. Se --experimental-test-isolation è impostato su 'none', questo flag viene ignorato e la concorrenza è uno. Altrimenti, la concorrenza è impostata di default su os.availableParallelism() - 1.

--test-coverage-branches=threshold

Aggiunto in: v22.8.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Richiede una percentuale minima di rami coperti. Se la code coverage non raggiunge la soglia specificata, il processo si chiuderà con codice 1.

--test-coverage-exclude

Aggiunto in: v22.5.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Esclude file specifici dalla code coverage utilizzando un pattern glob, che può corrispondere sia a percorsi di file assoluti che relativi.

Questa opzione può essere specificata più volte per escludere più pattern glob.

Se vengono forniti sia --test-coverage-exclude che --test-coverage-include, i file devono soddisfare entrambi i criteri per essere inclusi nel report di coverage.

Per impostazione predefinita, tutti i file di test corrispondenti vengono esclusi dal report di coverage. La specifica di questa opzione sovrascriverà il comportamento predefinito.

--test-coverage-functions=threshold

Aggiunto in: v22.8.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Richiede una percentuale minima di funzioni coperte. Se la code coverage non raggiunge la soglia specificata, il processo si chiuderà con codice 1.

--test-coverage-include

Aggiunto in: v22.5.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Include file specifici nella code coverage utilizzando un pattern glob, che può corrispondere sia a percorsi di file assoluti che relativi.

Questa opzione può essere specificata più volte per includere più pattern glob.

Se vengono forniti sia --test-coverage-exclude che --test-coverage-include, i file devono soddisfare entrambi i criteri per essere inclusi nel report di code coverage.

--test-coverage-lines=threshold

Aggiunto in: v22.8.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Richiede una percentuale minima di linee coperte. Se la code coverage non raggiunge la soglia specificata, il processo terminerà con codice 1.

--test-force-exit

Aggiunto in: v22.0.0, v20.14.0

Configura il test runner per terminare il processo una volta che tutti i test conosciuti hanno finito di essere eseguiti, anche se il ciclo di eventi altrimenti rimarrebbe attivo.

--test-name-pattern

[Cronologia]

Versione	Modifiche
v20.0.0	Il test runner è ora stabile.
v18.11.0	Aggiunto in: v18.11.0

Un'espressione regolare che configura il test runner per eseguire solo i test il cui nome corrisponde al pattern fornito. Consulta la documentazione sul filtraggio dei test per nome per maggiori dettagli.

Se vengono forniti sia --test-name-pattern che --test-skip-pattern, i test devono soddisfare entrambi i requisiti per essere eseguiti.

--test-only

[Cronologia]

Versione	Modifiche
v20.0.0	Il test runner è ora stabile.
v18.0.0, v16.17.0	Aggiunto in: v18.0.0, v16.17.0

Configura il test runner per eseguire solo i test di primo livello che hanno l'opzione only impostata. Questo flag non è necessario quando l'isolamento dei test è disabilitato.

--test-reporter

[Cronologia]

Versione	Modifiche
v20.0.0	Il test runner è ora stabile.
v19.6.0, v18.15.0	Aggiunto in: v19.6.0, v18.15.0

Un test reporter da utilizzare quando si eseguono i test. Consulta la documentazione sui test reporter per maggiori dettagli.

--test-reporter-destination

[Cronologia]

Versione	Modifiche
v20.0.0	Il test runner è ora stabile.
v19.6.0, v18.15.0	Aggiunto in: v19.6.0, v18.15.0

La destinazione per il corrispondente test reporter. Per maggiori dettagli, consultare la documentazione sui test reporter.

--test-shard

Aggiunto in: v20.5.0, v18.19.0

Suddivisione della suite di test da eseguire in un formato di \<index\>/\<total\>, dove

index è un numero intero positivo, indice delle parti divise total è un numero intero positivo, totale delle parti divise Questo comando dividerà tutti i file di test in total parti uguali ed eseguirà solo quelli che si trovano in una parte index.

Ad esempio, per dividere la tua suite di test in tre parti, usa questo:

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

--test-skip-pattern

Aggiunto in: v22.1.0

Un'espressione regolare che configura il test runner per saltare i test il cui nome corrisponde al pattern fornito. Per maggiori dettagli, consultare la documentazione sul filtraggio dei test per nome.

Se vengono forniti sia --test-name-pattern che --test-skip-pattern, i test devono soddisfare entrambi i requisiti per essere eseguiti.

--test-timeout

Aggiunto in: v21.2.0, v20.11.0

Un numero di millisecondi dopo i quali l'esecuzione del test fallirà. Se non specificato, i sottotest ereditano questo valore dal loro genitore. Il valore predefinito è Infinity.

--test-update-snapshots

[Cronologia]

Versione	Modifiche
v23.4.0	Il test degli snapshot non è più sperimentale.
v22.3.0	Aggiunto in: v22.3.0

Rigenera i file di snapshot utilizzati dal test runner per il test degli snapshot.

--throw-deprecation

Aggiunto in: v0.11.14

Genera errori per le deprecazioni.

--title=title

Aggiunto in: v10.7.0

Imposta process.title all'avvio.

--tls-cipher-list=list

Aggiunto in: v4.0.0

Specifica un elenco di cifrari TLS predefinito alternativo. Richiede che Node.js sia compilato con il supporto crittografico (predefinito).

--tls-keylog=file

Aggiunto in: v13.2.0, v12.16.0

Registra il materiale della chiave TLS in un file. Il materiale della chiave è nel formato NSS SSLKEYLOGFILE e può essere utilizzato da software (come Wireshark) per decriptare il traffico TLS.

--tls-max-v1.2

Aggiunto in: v12.0.0, v10.20.0

Imposta tls.DEFAULT_MAX_VERSION su 'TLSv1.2'. Utilizzare per disabilitare il supporto per TLSv1.3.

--tls-max-v1.3

Aggiunto in: v12.0.0

Imposta tls.DEFAULT_MAX_VERSION predefinito su 'TLSv1.3'. Utilizzare per abilitare il supporto per TLSv1.3.

--tls-min-v1.0

Aggiunto in: v12.0.0, v10.20.0

Imposta tls.DEFAULT_MIN_VERSION predefinito su 'TLSv1'. Utilizzare per la compatibilità con vecchi client o server TLS.

--tls-min-v1.1

Aggiunto in: v12.0.0, v10.20.0

Imposta tls.DEFAULT_MIN_VERSION predefinito su 'TLSv1.1'. Utilizzare per la compatibilità con vecchi client o server TLS.

--tls-min-v1.2

Aggiunto in: v12.2.0, v10.20.0

Imposta tls.DEFAULT_MIN_VERSION predefinito su 'TLSv1.2'. Questo è il valore predefinito per la versione 12.x e successive, ma l'opzione è supportata per la compatibilità con le versioni precedenti di Node.js.

--tls-min-v1.3

Aggiunto in: v12.0.0

Imposta tls.DEFAULT_MIN_VERSION predefinito su 'TLSv1.3'. Utilizzare per disabilitare il supporto per TLSv1.2, che non è sicuro come TLSv1.3.

--trace-deprecation

Aggiunto in: v0.8.0

Stampa le stack trace per le deprecazioni.

--trace-env

Aggiunto in: v23.4.0

Stampa informazioni su qualsiasi accesso alle variabili d'ambiente effettuato nell'istanza corrente di Node.js su stderr, inclusi:

• Le letture delle variabili d'ambiente che Node.js effettua internamente.
• Scritture nella forma di process.env.KEY = "QUALCHE VALORE".
• Letture nella forma di process.env.KEY.
• Definizioni nella forma di Object.defineProperty(process.env, 'KEY', {...}).
• Query nella forma di Object.hasOwn(process.env, 'KEY'), process.env.hasOwnProperty('KEY') o 'KEY' in process.env.
• Eliminazioni nella forma di delete process.env.KEY.
• Enumerazioni nella forma di ...process.env o Object.keys(process.env).

Vengono stampati solo i nomi delle variabili d'ambiente a cui si accede. I valori non vengono stampati.

Per stampare la stack trace dell'accesso, utilizzare --trace-env-js-stack e/o --trace-env-native-stack.

--trace-env-js-stack

Aggiunto in: v23.4.0

Oltre a ciò che fa --trace-env, questo stampa la traccia dello stack JavaScript dell'accesso.

--trace-env-native-stack

Aggiunto in: v23.4.0

Oltre a ciò che fa --trace-env, questo stampa la traccia dello stack nativo dell'accesso.

--trace-event-categories

Aggiunto in: v7.7.0

Un elenco di categorie separate da virgola che dovrebbero essere tracciate quando la traccia degli eventi è abilitata usando --trace-events-enabled.

--trace-event-file-pattern

Aggiunto in: v9.8.0

Stringa di modello che specifica il percorso del file per i dati della traccia degli eventi, supporta ${rotation} e ${pid}.

--trace-events-enabled

Aggiunto in: v7.7.0

Abilita la raccolta di informazioni sulla traccia degli eventi.

--trace-exit

Aggiunto in: v13.5.0, v12.16.0

Stampa una traccia dello stack ogni volta che un ambiente viene chiuso in modo proattivo, ovvero invocando process.exit().

--trace-require-module=mode

Aggiunto in: v23.5.0

Stampa informazioni sull'utilizzo di Caricamento di moduli ECMAScript usando require().

Quando mode è all, viene stampato tutto l'utilizzo. Quando mode è no-node-modules, l'utilizzo dalla cartella node_modules viene escluso.

--trace-sigint

Aggiunto in: v13.9.0, v12.17.0

Stampa una traccia dello stack su SIGINT.

--trace-sync-io

Aggiunto in: v2.1.0

Stampa una traccia dello stack ogni volta che viene rilevato I/O sincrono dopo il primo ciclo dell'event loop.

--trace-tls

Aggiunto in: v12.2.0

Stampa le informazioni sulla traccia dei pacchetti TLS su stderr. Questo può essere usato per debuggare i problemi di connessione TLS.

--trace-uncaught

Aggiunto in: v13.1.0

Stampa le tracce dello stack per le eccezioni non catturate; di solito, viene stampata la traccia dello stack associata alla creazione di un Error, mentre questo fa sì che Node.js stampi anche la traccia dello stack associata al lancio del valore (che non deve essere un'istanza di Error).

L'abilitazione di questa opzione potrebbe influenzare negativamente il comportamento della garbage collection.

--trace-warnings

Aggiunto in: v6.0.0

Stampa le tracce dello stack per gli avvisi di processo (incluse le deprecazioni).

--track-heap-objects

Aggiunto in: v2.4.0

Traccia le allocazioni di oggetti heap per gli snapshot dell'heap.

--unhandled-rejections=mode

[Cronologia]

Versione	Cambiamenti
v15.0.0	Il modo predefinito è stato modificato in throw. In precedenza, veniva emesso un avviso.
v12.0.0, v10.17.0	Aggiunto in: v12.0.0, v10.17.0

L'utilizzo di questo flag consente di modificare ciò che deve accadere quando si verifica un rifiuto non gestito. È possibile scegliere una delle seguenti modalità:

• throw: Emette unhandledRejection. Se questo hook non è impostato, genera il rifiuto non gestito come un'eccezione non rilevata. Questo è il valore predefinito.
• strict: Genera il rifiuto non gestito come un'eccezione non rilevata. Se l'eccezione viene gestita, viene emesso unhandledRejection.
• warn: Attiva sempre un avviso, indipendentemente dal fatto che l'hook unhandledRejection sia impostato o meno, ma non stampa l'avviso di deprecazione.
• warn-with-error-code: Emette unhandledRejection. Se questo hook non è impostato, attiva un avviso e imposta il codice di uscita del processo su 1.
• none: Disattiva tutti gli avvisi.

Se si verifica un rifiuto durante la fase di caricamento statico del modulo ES del punto di ingresso della riga di comando, lo genererà sempre come un'eccezione non rilevata.

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

Aggiunto in: v6.11.0

Utilizza l'archivio CA Mozilla in bundle fornito dalla versione corrente di Node.js oppure utilizza l'archivio CA predefinito di OpenSSL. L'archivio predefinito è selezionabile in fase di compilazione.

L'archivio CA in bundle, fornito da Node.js, è un'istantanea dell'archivio CA Mozilla che è fissa al momento del rilascio. È identica su tutte le piattaforme supportate.

L'utilizzo dell'archivio OpenSSL consente modifiche esterne all'archivio. Per la maggior parte delle distribuzioni Linux e BSD, questo archivio è gestito dai responsabili della manutenzione della distribuzione e dagli amministratori di sistema. La posizione dell'archivio CA di OpenSSL dipende dalla configurazione della libreria OpenSSL, ma può essere modificata in fase di esecuzione tramite variabili d'ambiente.

Vedere SSL_CERT_DIR e SSL_CERT_FILE.

--use-largepages=mode

Aggiunto in: v13.6.0, v12.17.0

Rimappa il codice statico di Node.js a pagine di memoria di grandi dimensioni all'avvio. Se supportato dal sistema di destinazione, ciò farà sì che il codice statico di Node.js venga spostato su pagine da 2 MiB invece che su pagine da 4 KiB.

I seguenti valori sono validi per mode:

• off: Non verrà tentata alcuna mappatura. Questo è il valore predefinito.
• on: Se supportato dal sistema operativo, verrà tentata la mappatura. Il fallimento della mappatura verrà ignorato e verrà stampato un messaggio di errore standard.
• silent: Se supportato dal sistema operativo, verrà tentata la mappatura. Il fallimento della mappatura verrà ignorato e non verrà segnalato.

--v8-options

Aggiunto in: v0.1.3

Stampa le opzioni della riga di comando di V8.

--v8-pool-size=num

Aggiunto in: v5.10.0

Imposta la dimensione del pool di thread di V8 che verrà utilizzata per allocare i lavori in background.

Se impostato su 0, Node.js sceglierà una dimensione appropriata del pool di thread in base a una stima della quantità di parallelismo.

La quantità di parallelismo si riferisce al numero di calcoli che possono essere eseguiti simultaneamente in una determinata macchina. In generale, è uguale alla quantità di CPU, ma può divergere in ambienti come VM o container.

-v, --version

Aggiunto in: v0.1.3

Stampa la versione di node.

--watch

[Cronologia]

Versione	Modifiche
v22.0.0, v20.13.0	La modalità di osservazione è ora stabile.
v19.2.0, v18.13.0	Il test runner ora supporta l'esecuzione in modalità di osservazione.
v18.11.0, v16.19.0	Aggiunto in: v18.11.0, v16.19.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Avvia Node.js in modalità di osservazione. In modalità di osservazione, le modifiche ai file osservati causano il riavvio del processo Node.js. Per impostazione predefinita, la modalità di osservazione osserverà il punto di ingresso e qualsiasi modulo richiesto o importato. Utilizzare --watch-path per specificare quali percorsi osservare.

Questo flag non può essere combinato con --check, --eval, --interactive o la REPL.

node --watch index.js

--watch-path

[Cronologia]

Versione	Modifiche
v22.0.0, v20.13.0	La modalità di osservazione è ora stabile.
v18.11.0, v16.19.0	Aggiunto in: v18.11.0, v16.19.0

[Stabile: 2 - Stabile]

Stabile: 2 Stabilità: 2 - Stabile

Avvia Node.js in modalità di osservazione e specifica quali percorsi osservare. Quando è in modalità di osservazione, le modifiche nei percorsi osservati causano il riavvio del processo Node.js. Questo disattiverà l'osservazione dei moduli richiesti o importati, anche se utilizzato in combinazione con --watch.

Questo flag non può essere combinato con --check, --eval, --interactive, --test o REPL.

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

Questa opzione è supportata solo su macOS e Windows. Un'eccezione ERR_FEATURE_UNAVAILABLE_ON_PLATFORM verrà generata quando l'opzione viene utilizzata su una piattaforma che non la supporta.

--watch-preserve-output

Aggiunto in: v19.3.0, v18.13.0

Disabilita la cancellazione della console quando la modalità di osservazione riavvia il processo.

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

--zero-fill-buffers

Aggiunto in: v6.0.0

Riempie automaticamente con zeri tutte le nuove istanze allocate di Buffer e SlowBuffer.

Variabili d'ambiente

FORCE_COLOR=[1, 2, 3]

La variabile d'ambiente FORCE_COLOR viene utilizzata per abilitare l'output colorato ANSI. Il valore può essere:

• 1, true, o la stringa vuota '' indicano il supporto a 16 colori,
• 2 per indicare il supporto a 256 colori, oppure
• 3 per indicare il supporto a 16 milioni di colori.

Quando FORCE_COLOR viene utilizzato e impostato su un valore supportato, le variabili d'ambiente NO_COLOR e NODE_DISABLE_COLORS vengono entrambe ignorate.

Qualsiasi altro valore comporterà la disabilitazione dell'output colorato.

NODE_COMPILE_CACHE=dir

Aggiunto in: v22.1.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo attivo

Abilita la cache di compilazione dei moduli per l'istanza di Node.js. Consultare la documentazione della cache di compilazione dei moduli per i dettagli.

NODE_DEBUG=module[,…]

Aggiunto in: v0.1.32

Elenco separato da ',' di moduli core che dovrebbero stampare informazioni di debug.

NODE_DEBUG_NATIVE=module[,…]

Elenco separato da ',' di moduli core C++ che dovrebbero stampare informazioni di debug.

NODE_DISABLE_COLORS=1

Aggiunto in: v0.3.0

Quando impostato, i colori non verranno utilizzati nella REPL.

NODE_DISABLE_COMPILE_CACHE=1

Aggiunto in: v22.8.0

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1.1 - Sviluppo Attivo

Disabilita la cache di compilazione dei moduli per l'istanza di Node.js. Vedere la documentazione della cache di compilazione dei moduli per i dettagli.

NODE_EXTRA_CA_CERTS=file

Aggiunto in: v7.3.0

Quando impostato, le note CA "root" (come VeriSign) saranno estese con i certificati extra nel file. Il file dovrebbe essere costituito da uno o più certificati attendibili in formato PEM. Verrà emesso un messaggio (una volta) con process.emitWarning() se il file è mancante o non valido, ma eventuali altri errori verranno ignorati.

Né i certificati ben noti né quelli extra vengono utilizzati quando la proprietà delle opzioni ca è specificata esplicitamente per un client o server TLS o HTTPS.

Questa variabile d'ambiente viene ignorata quando node viene eseguito come root setuid o ha le capacità dei file Linux impostate.

La variabile d'ambiente NODE_EXTRA_CA_CERTS viene letta solo quando il processo Node.js viene avviato per la prima volta. La modifica del valore in fase di esecuzione utilizzando process.env.NODE_EXTRA_CA_CERTS non ha alcun effetto sul processo corrente.

NODE_ICU_DATA=file

Aggiunto in: v0.11.15

Percorso dei dati per i dati ICU (oggetto Intl). Estenderà i dati collegati quando compilato con il supporto small-icu.

NODE_NO_WARNINGS=1

Aggiunto in: v6.11.0

Quando impostato su 1, gli avvisi di processo vengono silenziati.

NODE_OPTIONS=options...

Aggiunto in: v8.0.0

Un elenco di opzioni della riga di comando separate da spazi. options... vengono interpretate prima delle opzioni della riga di comando, quindi le opzioni della riga di comando sovrascriveranno o si comporranno dopo qualsiasi elemento in options.... Node.js terminerà con un errore se viene utilizzata un'opzione non consentita nell'ambiente, come -p o un file di script.

Se un valore di opzione contiene uno spazio, può essere preceduto da una sequenza di escape utilizzando le virgolette doppie:

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

Un flag singleton passato come opzione della riga di comando sovrascriverà lo stesso flag passato in NODE_OPTIONS:

# L'inspector sarà disponibile sulla porta 5555 {#node_options=options}
NODE_OPTIONS='--inspect=localhost:4444' node --inspect=localhost:5555

Un flag che può essere passato più volte verrà trattato come se le sue istanze NODE_OPTIONS fossero passate per prime, e poi le sue istanze della riga di comando in seguito:

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

Le opzioni Node.js consentite sono nel seguente elenco. Se un'opzione supporta entrambe le varianti --XX e --no-XX, sono entrambe supportate, ma solo una è inclusa nell'elenco seguente.

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

Le opzioni V8 consentite sono:

• --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 e --perf-prof sono disponibili solo su Linux.

--enable-etw-stack-walking è disponibile solo su Windows.

NODE_PATH=percorso[:...]

Aggiunto in: v0.1.32

Elenco di directory separate da ':' anteposte al percorso di ricerca dei moduli.

Su Windows, questo è invece un elenco separato da ';'.

NODE_PENDING_DEPRECATION=1

Aggiunto in: v8.0.0

Quando impostato su 1, emette avvisi di deprecazione in sospeso.

Le deprecazioni in sospeso sono generalmente identiche a una deprecazione di runtime, con la notevole eccezione che sono disattivate per impostazione predefinita e non verranno emesse a meno che non venga impostato il flag della riga di comando --pending-deprecation o la variabile d'ambiente NODE_PENDING_DEPRECATION=1. Le deprecazioni in sospeso vengono utilizzate per fornire una sorta di meccanismo di "allerta precoce" selettiva che gli sviluppatori possono sfruttare per rilevare l'uso di API deprecate.

NODE_PENDING_PIPE_INSTANCES=istanze

Imposta il numero di handle di istanze pipe in sospeso quando il server pipe è in attesa di connessioni. Questa impostazione si applica solo a Windows.

NODE_PRESERVE_SYMLINKS=1

Aggiunto in: v7.1.0

Quando impostato su 1, indica al caricatore di moduli di conservare i collegamenti simbolici durante la risoluzione e la memorizzazione nella cache dei moduli.

NODE_REDIRECT_WARNINGS=file

Aggiunto in: v8.0.0

Quando impostato, gli avvisi di processo verranno emessi sul file specificato invece di essere stampati su stderr. Il file verrà creato se non esiste e verrà aggiunto ad esso se esiste già. Se si verifica un errore durante il tentativo di scrittura dell'avviso nel file, l'avviso verrà invece scritto su stderr. Questo è equivalente all'uso del flag della riga di comando --redirect-warnings=file.

NODE_REPL_EXTERNAL_MODULE=file

[Cronologia]

Versione	Modifiche
v22.3.0, v20.16.0	Rimossa la possibilità di utilizzare questa variabile d'ambiente con kDisableNodeOptionsEnv per gli incorporatori.
v13.0.0, v12.16.0	Aggiunto in: v13.0.0, v12.16.0

Percorso di un modulo Node.js che verrà caricato al posto del REPL integrato. La sovrascrittura di questo valore con una stringa vuota ('') utilizzerà il REPL integrato.

NODE_REPL_HISTORY=file

Aggiunto in: v3.0.0

Percorso del file utilizzato per memorizzare la cronologia persistente del REPL. Il percorso predefinito è ~/.node_repl_history, che viene sovrascritto da questa variabile. Impostando il valore su una stringa vuota ('' o ' ') si disabilita la cronologia persistente del REPL.

NODE_SKIP_PLATFORM_CHECK=value

Aggiunto in: v14.5.0

Se value è uguale a '1', il controllo per una piattaforma supportata viene saltato durante l'avvio di Node.js. Node.js potrebbe non essere eseguito correttamente. Eventuali problemi riscontrati su piattaforme non supportate non verranno corretti.

NODE_TEST_CONTEXT=value

Se value è uguale a 'child', le opzioni del reporter di test verranno sovrascritte e l'output del test verrà inviato a stdout nel formato TAP. Se viene fornito qualsiasi altro valore, Node.js non fornisce garanzie sul formato del reporter utilizzato o sulla sua stabilità.

NODE_TLS_REJECT_UNAUTHORIZED=value

Se value è uguale a '0', la convalida del certificato viene disabilitata per le connessioni TLS. Ciò rende TLS, e per estensione HTTPS, insicuro. L'uso di questa variabile d'ambiente è fortemente sconsigliato.

NODE_V8_COVERAGE=dir

Quando impostato, Node.js inizierà a inviare copertura del codice JavaScript V8 e dati Source Map alla directory fornita come argomento (le informazioni sulla copertura vengono scritte come JSON in file con un prefisso coverage).

NODE_V8_COVERAGE si propagherà automaticamente ai sottoprocessi, facilitando l'instrumentazione delle applicazioni che chiamano la famiglia di funzioni child_process.spawn(). NODE_V8_COVERAGE può essere impostato su una stringa vuota per impedire la propagazione.

NO_COLOR=<qualsiasi>

NO_COLOR è un alias per NODE_DISABLE_COLORS. Il valore della variabile d'ambiente è arbitrario.

Output della copertura {#no_color=<any>}

La copertura viene restituita come un array di oggetti ScriptCoverage sulla chiave di primo livello result:

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

Cache della source map

[Stabile: 1 - Sperimentale]

Stabile: 1 Stabilità: 1 - Sperimentale

Se trovato, i dati della source map vengono aggiunti alla chiave di primo livello source-map-cache nell'oggetto di copertura JSON.

source-map-cache è un oggetto con chiavi che rappresentano i file da cui sono state estratte le source map e valori che includono l'URL della source map raw (nella chiave url), le informazioni Source Map v3 analizzate (nella chiave data) e le lunghezze delle righe del file sorgente (nella chiave lineLengths).

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

OPENSSL_CONF=file

Aggiunto in: v6.11.0

Carica un file di configurazione OpenSSL all'avvio. Tra gli altri usi, questo può essere utilizzato per abilitare la crittografia conforme a FIPS se Node.js è compilato con ./configure --openssl-fips.

Se viene utilizzata l'opzione della riga di comando --openssl-config, la variabile d'ambiente viene ignorata.

SSL_CERT_DIR=dir

Aggiunto in: v7.7.0

Se --use-openssl-ca è abilitato, questo sovrascrive e imposta la directory di OpenSSL contenente i certificati attendibili.

Si noti che, a meno che l'ambiente figlio non sia esplicitamente impostato, questa variabile d'ambiente sarà ereditata da qualsiasi processo figlio e, se questi utilizzano OpenSSL, potrebbe far sì che si fidino delle stesse CA di node.

SSL_CERT_FILE=file

Aggiunto in: v7.7.0

Se --use-openssl-ca è abilitato, questo sovrascrive e imposta il file di OpenSSL contenente i certificati attendibili.

Si noti che, a meno che l'ambiente figlio non sia esplicitamente impostato, questa variabile d'ambiente sarà ereditata da qualsiasi processo figlio e, se questi utilizzano OpenSSL, potrebbe far sì che si fidino delle stesse CA di node.

TZ

[Cronologia]

Versione	Modifiche
v16.2.0	La modifica della variabile TZ utilizzando process.env.TZ = cambia il fuso orario anche su Windows.
v13.0.0	La modifica della variabile TZ utilizzando process.env.TZ = cambia il fuso orario sui sistemi POSIX.
v0.0.1	Aggiunto in: v0.0.1

La variabile d'ambiente TZ è utilizzata per specificare la configurazione del fuso orario.

Sebbene Node.js non supporti tutti i vari modi in cui TZ viene gestito in altri ambienti, supporta gli ID di fuso orario di base (come 'Etc/UTC', 'Europe/Paris' o 'America/New_York'). Potrebbe supportare alcune altre abbreviazioni o alias, ma questi sono fortemente sconsigliati e non garantiti.

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

UV_THREADPOOL_SIZE=size

Imposta il numero di thread utilizzati nel threadpool di libuv a size thread.

Le API di sistema asincrone sono utilizzate da Node.js quando possibile, ma laddove non esistono, il threadpool di libuv viene utilizzato per creare API di nodo asincrone basate su API di sistema sincrone. Le API di Node.js che utilizzano il threadpool sono:

• tutte le API fs, ad eccezione delle API di osservazione dei file e di quelle esplicitamente sincrone
• API crittografiche asincrone come crypto.pbkdf2(), crypto.scrypt(), crypto.randomBytes(), crypto.randomFill(), crypto.generateKeyPair()
• dns.lookup()
• tutte le API zlib, ad eccezione di quelle esplicitamente sincrone

Poiché il threadpool di libuv ha una dimensione fissa, ciò significa che se per qualsiasi motivo una di queste API richiede molto tempo, altre API (apparentemente non correlate) che vengono eseguite nel threadpool di libuv sperimenteranno prestazioni degradate. Per mitigare questo problema, una potenziale soluzione è aumentare la dimensione del threadpool di libuv impostando la variabile di ambiente 'UV_THREADPOOL_SIZE' su un valore maggiore di 4 (il suo valore predefinito attuale). Tuttavia, l'impostazione di questa variabile dall'interno del processo utilizzando process.env.UV_THREADPOOL_SIZE=size non è garantito che funzioni poiché il threadpool sarebbe stato creato come parte dell'inizializzazione runtime molto prima che il codice utente venga eseguito. Per maggiori informazioni, consultare la documentazione sul threadpool di libuv.

Opzioni V8 utili

V8 ha il proprio set di opzioni CLI. Qualsiasi opzione CLI di V8 fornita a node verrà passata a V8 per essere gestita. Le opzioni di V8 non hanno alcuna garanzia di stabilità. Il team di V8 stesso non le considera parte della loro API formale e si riserva il diritto di modificarle in qualsiasi momento. Allo stesso modo, non sono coperte dalle garanzie di stabilità di Node.js. Molte delle opzioni di V8 sono di interesse solo per gli sviluppatori di V8. Nonostante ciò, esiste un piccolo set di opzioni di V8 che sono ampiamente applicabili a Node.js e sono documentate qui:

--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=SIZE (in MiB)

Imposta la dimensione massima della sezione di memoria vecchia di V8. Quando il consumo di memoria si avvicina al limite, V8 dedicherà più tempo al garbage collection nel tentativo di liberare la memoria non utilizzata.

Su una macchina con 2 GiB di memoria, è consigliabile impostare questo valore a 1536 (1,5 GiB) per lasciare un po' di memoria per altri usi ed evitare lo swapping.

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

--max-semi-space-size=SIZE (in MiB)

Imposta la dimensione massima del semi-spazio per il garbage collector scavenge di V8 in MiB (mebibyte). L'aumento della dimensione massima di un semi-spazio può migliorare il throughput per Node.js al costo di un maggiore consumo di memoria.

Poiché la dimensione della generazione giovane dell'heap di V8 è tre volte (vedi YoungGenerationSizeFromSemiSpaceSize in V8) la dimensione del semi-spazio, un aumento di 1 MiB al semi-spazio si applica a ciascuno dei tre semi-spazi individuali e fa aumentare la dimensione dell'heap di 3 MiB. Il miglioramento del throughput dipende dal carico di lavoro (vedi #42511).

Il valore predefinito dipende dal limite di memoria. Ad esempio, sui sistemi a 64 bit con un limite di memoria di 512 MiB, la dimensione massima di un semi-spazio è impostata per default a 1 MiB. Per i limiti di memoria fino a 2GiB inclusi, la dimensione massima predefinita di un semi-spazio sarà inferiore a 16 MiB sui sistemi a 64 bit.

Per ottenere la migliore configurazione per la tua applicazione, dovresti provare diversi valori di max-semi-space-size quando esegui benchmark per la tua applicazione.

Ad esempio, benchmark su sistemi a 64 bit:

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

Il numero massimo di frame dello stack da raccogliere nello stack trace di un errore. Impostandolo a 0 si disabilita la raccolta dello stack trace. Il valore predefinito è 10.

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