Command-line API

Command-line API

Node.js comes with a variety of CLI options. These options expose built-in debugging, multiple ways to execute scripts, and other helpful runtime options.

To view this documentation as a manual page in a terminal, run man node.

Synopsis

node [options] [V8 options] [<program-entry-point> | -e “script” | -] [--] [arguments]

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

node --v8-options

Execute without arguments to start the [REPL][].

For more info about node inspect, see the [debugger][] documentation.

Program entry point

The program entry point is a specifier-like string. If the string is not an absolute path, it's resolved as a relative path from the current working directory. That entry point string is then resolved as if it's been requested by require() from the current working directory. If no corresponding file is found, an error is thrown.

By default, the resolved path is also loaded as if it's been requested by require(), unless one of the conditions below apply—then it's loaded as if it's been requested by import():

The program was started with a command-line flag that forces the entry point to be loaded with ECMAScript module loader, such as --import.
The file has an .mjs, .mts or .wasm extension.
The file does not have a .cjs extension, and the nearest parent package.json file contains a top-level [“type”][] field with a value of “module”.

See [module resolution and loading][] for more details.

Options

Stability: 2 - Stable

All options, including V8 options, allow words to be separated by both dashes (-) or underscores (_). For example, --pending-deprecation is equivalent to --pending_deprecation.

If an option that takes a single value (such as --max-http-header-size) is passed more than once, then the last passed value is used. Options from the command line take precedence over options passed through the [NODE_OPTIONS][] environment variable.

`-`

Alias for stdin. Analogous to the use of - in other command-line utilities, meaning that the script is read from stdin, and the rest of the options are passed to that script.

`--`

Indicate the end of node options. Pass the rest of the arguments to the script. If no script filename or eval/print script is supplied prior to this, then the next argument is used as a script filename.

`--abort-on-uncaught-exception`

Aborting instead of exiting causes a core file to be generated for post-mortem analysis using a debugger (such as lldb, gdb, and mdb).

If this flag is passed, the behavior can still be set to not abort through [process.setUncaughtExceptionCaptureCallback()][] (and through usage of the node:domain module that uses it).

`--allow-addons`

Stability: 1.1 - Active development

When using the [Permission Model][], the process will not be able to use native addons by default. Attempts to do so will throw an ERR_DLOPEN_DISABLED unless the user explicitly passes the --allow-addons flag when starting Node.js.

Example:

// Attempt to require an native addon
require('nodejs-addon-example');

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

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

`--allow-child-process`

Stability: 1.1 - Active development

When using the [Permission Model][], the process will not be able to spawn any child process by default. Attempts to do so will throw an ERR_ACCESS_DENIED unless the user explicitly passes the --allow-child-process flag when starting Node.js.

Example:

const childProcess = require('node:child_process');
// Attempt to bypass the permission
childProcess.spawn('node', ['-e', 'require("fs").writeFileSync("/new-file", "example")']);

$ node --permission --allow-fs-read=* index.js
node:internal/child_process:388
  const err = this._handle.spawn(options);
                           ^
Error: Access to this API has been restricted
    at ChildProcess.spawn (node:internal/child_process:388:28)
    at node:internal/main/run_main_module:17:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'ChildProcess'
}

The child_process.fork() API inherits the execution arguments from the parent process. This means that if Node.js is started with the Permission Model enabled and the --allow-child-process flag is set, any child process created using child_process.fork() will automatically receive all relevant Permission Model flags.

This behavior also applies to child_process.spawn(), but in that case, the flags are propagated via the NODE_OPTIONS environment variable rather than directly through the process arguments.

`--allow-ffi`

Stability: 1.1 - Active development

When using the [Permission Model][], the process will not be able to use FFI APIs by default. Attempts to use FFI APIs will throw an ERR_ACCESS_DENIED exception unless the user explicitly passes the --allow-ffi flag when starting Node.js. The [node:ffi][] module is only available in builds with FFI support.

Example:

const { DynamicLibrary, suffix } = require('node:ffi');
const lib = new DynamicLibrary(`./mylib.${suffix}`);

$ node --permission index.js
Error: Access to this API has been restricted. Use --allow-ffi to manage permissions.
    at node:internal/main/run_main_module:17:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'FFI'
}

`--allow-fs-read`

This flag configures file system read permissions using the [Permission Model][].

The valid arguments for the --allow-fs-read flag are:

* - To allow all FileSystemRead operations.
Multiple paths can be allowed using multiple --allow-fs-read flags. Example --allow-fs-read=/folder1/ --allow-fs-read=/folder2/

Examples can be found in the [File System Permissions][] documentation.

The initializer module and custom --require modules has a implicit read permission.

$ node --permission -r custom-require.js -r custom-require-2.js index.js

The custom-require.js, custom-require-2.js, and index.js will be by default in the allowed read list.

process.permission.has('fs.read', 'index.js'); // true
process.permission.has('fs.read', 'custom-require.js'); // true
process.permission.has('fs.read', 'custom-require-2.js'); // true

`--allow-fs-vfs`

Stability: 1.1 - Active development

When using the [Permission Model][], a [virtual file system][] cannot be mounted by default: [vfs.mount()][] throws ERR_INVALID_STATE unless the user explicitly passes the --allow-fs-vfs flag when starting Node.js.

A mounted VFS serves paths that the file system permissions do not describe, so mounting one is gated on its own flag rather than on --allow-fs-read or --allow-fs-write.

$ node --experimental-vfs --permission --allow-fs-vfs app.js

`--allow-fs-write`

This flag configures file system write permissions using the [Permission Model][].

The valid arguments for the --allow-fs-write flag are:

* - To allow all FileSystemWrite operations.
Multiple paths can be allowed using multiple --allow-fs-write flags. Example --allow-fs-write=/folder1/ --allow-fs-write=/folder2/

Paths delimited by comma (,) are no longer allowed. When passing a single flag with a comma a warning will be displayed.

Examples can be found in the [File System Permissions][] documentation.

`--allow-inspector`

Stability: 1.0 - Early development

When using the [Permission Model][], the process will not be able to connect through inspector protocol.

Attempts to do so will throw an ERR_ACCESS_DENIED unless the user explicitly passes the --allow-inspector flag when starting Node.js.

Example:

const { Session } = require('node:inspector/promises');

const session = new Session();
session.connect();

$ node --permission index.js
Error: connect ERR_ACCESS_DENIED Access to this API has been restricted. Use --allow-inspector to manage permissions.
  code: 'ERR_ACCESS_DENIED',
}

`--allow-net`

Stability: 1.1 - Active development

When using the [Permission Model][], the process will not be able to access network by default. Attempts to do so will throw an ERR_ACCESS_DENIED unless the user explicitly passes the --allow-net flag when starting Node.js.

Example:

const http = require('node:http');
// Attempt to bypass the permission
const req = http.get('http://example.com', () => {});

req.on('error', (err) => {
  console.log('err', err);
});

$ node --permission index.js
Error: connect ERR_ACCESS_DENIED Access to this API has been restricted. Use --allow-net to manage permissions.
  code: 'ERR_ACCESS_DENIED',
}

`--allow-openssl-store`

Stability: 1.1 - Active development

When using the [Permission Model][], the process will not be able to use OpenSSL STORE loaders by default, for example to load a private key from a {URL} passed to [crypto.createPrivateKey()][]. Attempts to do so will throw an ERR_ACCESS_DENIED unless the user explicitly passes the --allow-openssl-store flag. This permission can be dropped at runtime via [permission.drop()][].

This flag grants broad authority to configured OpenSSL STORE loaders. A loader may access files, devices, tokens, or the network. Access performed by a loader is not constrained by the fs.read, fs.write, or net permission scopes.

`--allow-wasi`

Stability: 1.1 - Active development

When using the [Permission Model][], the process will not be capable of creating any WASI instances by default. For security reasons, the call will throw an ERR_ACCESS_DENIED unless the user explicitly passes the flag --allow-wasi in the main Node.js process.

Example:

const { WASI } = require('node:wasi');
// Attempt to bypass the permission
new WASI({
  version: 'preview1',
  // Attempt to mount the whole filesystem
  preopens: {
    '/': '/',
  },
});

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

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

`--allow-worker`

Stability: 1.1 - Active development

When using the [Permission Model][], the process will not be able to create any worker threads by default. For security reasons, the call will throw an ERR_ACCESS_DENIED unless the user explicitly pass the flag --allow-worker in the main Node.js process.

Example:

const { Worker } = require('node:worker_threads');
// Attempt to bypass the permission
new Worker(__filename);

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

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

`--bench`

Stability: 1 - Experimental

Starts the Node.js command-line benchmark runner. At least one explicit file or glob pattern is required:

node --experimental-bench --bench benchmark.mjs
node --experimental-bench --bench 'benchmarks/**/*.js'

The --experimental-bench flag is required to use this flag or any other --bench-* option.

Quote glob patterns to prevent expansion by the shell. Matching files are sorted and executed serially. By default, each file runs in a separate child process. Benchmark files declare benchmarks using node:bench; they must not call run() themselves. See the [benchmark runner][] documentation for more details.

This flag cannot be combined with --test, --watch, --watch-path, --check, --eval, or --interactive.

`--bench-isolation=mode`

Stability: 1 - Experimental

Configures benchmark file isolation. When mode is 'process', each matching file runs in a separate child process. This is the default. Files are still run serially so their measured work does not overlap.

When mode is 'none', all matching files and benchmarks run serially in the benchmark runner process. This reduces startup overhead but allows module, heap, and process state to carry between files. User writes to stdout or stderr also share destinations with benchmark reporters in this mode.

The supported modes are 'process' and 'none'.

`--bench-name-pattern=pattern`

Stability: 1 - Experimental

Only runs benchmarks whose full hierarchical name matches the JavaScript regular expression pattern. Non-matching benchmarks are reported as skipped.

`--bench-reporter-destination=destination`

Stability: 1 - Experimental

Specifies the destination for the corresponding benchmark reporter. The value can be stdout, stderr, or a file path. A single reporter defaults to stdout when no destination is specified.

`--bench-reporter=reporter`

Stability: 1 - Experimental

Specifies a benchmark reporter. The built-in reporters are spec and json. The json reporter emits newline-delimited JSON. A custom reporter can be specified using a module specifier resolved from the current working directory.

This option can be repeated. When multiple reporters are specified, each must have a corresponding --bench-reporter-destination. The default reporter is spec.

`--bench-samples=count`

Stability: 1 - Experimental

Overrides the maximum number of measured callback invocations for every selected benchmark. A benchmark may finish earlier by calling context.done(). count must be an integer between 1 and 4294967295.

`--bench-warmup=count`

Stability: 1 - Experimental

Overrides the number of unreported warmup callback invocations for every selected benchmark. count must be an integer between 0 and 4294967295. Without this option, each benchmark uses its own warmup value, which defaults to 10.

`--build-sea=config`

Stability: 1.1 - Active development

Generates a [single executable application][] from a JSON configuration file. The argument must be a path to the configuration file. If the path is not absolute, it is resolved relative to the current working directory.

For configuration fields, cross-platform notes, and asset APIs, see the [single executable application][] documentation.

`--build-snapshot`

Generates a snapshot blob when the process exits and writes it to disk, which can be loaded later with --snapshot-blob.

When building the snapshot, if --snapshot-blob is not specified, the generated blob will be written, by default, to snapshot.blob in the current working directory. Otherwise it will be written to the path specified by --snapshot-blob.

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

## Run snapshot.js to initialize the application and snapshot the
## state of it into snapshot.blob.
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js

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

## Load the generated snapshot and start the application from index.js.
$ node --snapshot-blob snapshot.blob index.js
I am from the snapshot

The [v8.startupSnapshot API][] can be used to specify an entry point at snapshot building time, thus avoiding the need of an additional entry script at deserialization time:

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

For more information, check out the [v8.startupSnapshot API][] documentation.

The snapshot currently only supports loading a single entrypoint during the snapshot building process, which can load built-in modules, but not additional user-land modules. Users can bundle their applications into a single script with their bundler of choice before building a snapshot.

As it's complicated to ensure the serializablility of all built-in modules, which are also growing over time, only a subset of the built-in modules are well tested to be serializable during the snapshot building process. The Node.js core test suite checks that a few fairly complex applications can be snapshotted. The list of built-in modules being [captured by the built-in snapshot of Node.js][] is considered supported. When the snapshot builder encounters a built-in module that cannot be serialized, it may crash the snapshot building process. In that case a typical workaround would be to delay loading that module until runtime, using either [v8.startupSnapshot.setDeserializeMainFunction()][] or [v8.startupSnapshot.addDeserializeCallback()][]. If serialization for an additional module during the snapshot building process is needed, please file a request in the [Node.js issue tracker][] and link to it in the [tracking issue for user-land snapshots][].

`--build-snapshot-config`

Specifies the path to a JSON configuration file which configures snapshot creation behavior.

The following options are currently supported:

builder {string} Required. Provides the name to the script that is executed before building the snapshot, as if [--build-snapshot][] had been passed with builder as the main script name.
withoutCodeCache {boolean} Optional. Including the code cache reduces the time spent on compiling functions included in the snapshot at the expense of a bigger snapshot size and potentially breaking portability of the snapshot.

When using this flag, additional script files provided on the command line will not be executed and instead be interpreted as regular command line arguments.

`-c`, `--check`

Syntax check the script without executing.

`--completion-bash`

Print source-able bash completion script for Node.js.

node --completion-bash > node_bash_completion
source node_bash_completion

`-C condition`, `--conditions=condition`

Provide custom [conditional exports][] resolution conditions.

Any number of custom string condition names are permitted.

The default Node.js conditions of “node”, “default”, “import”, and “require” will always apply as defined.

For example, to run a module with “development” resolutions:

node -C development app.js

`--config-file=path`, `--config-file`

If present, Node.js will look for a configuration file at the specified path. If the path is not specified, Node.js will look for a node.config.json file in the current working directory. To specify a custom path, use the --config-file=path form. The space-separated --config-file path form is not supported. Node.js will read the configuration file and apply the settings. The configuration file should be a JSON file with the following structure. vX.Y.Z in the $schema must be replaced with the version of Node.js you are using or latest-vX.x for the latest version of that major release line.

{
  "$schema": "https://nodejs.org/dist/vX.Y.Z/docs/node-config-schema.json",
  "nodeOptions": {
    "import": [
      "amaro/strip"
    ],
    "watch-path": "src",
    "watch-preserve-output": true
  },
  "test": {
    "test-isolation": "process"
  },
  "watch": {
    "watch-preserve-output": true
  }
}

The configuration file supports namespace-specific options:

The nodeOptions field contains CLI flags that are allowed in [NODE_OPTIONS][].
Namespace fields like test, watch, and permission contain configuration specific to that subsystem.

The configuration file can target a specific Node.js major version with nodeVersion:

{
  "nodeVersion": 25,
  "nodeOptions": {
    "watch-path": "src"
  }
}

To keep multiple version-specific configurations in the same file, use the configs array. Node.js will use the first entry whose nodeVersion matches the current Node.js major version:

{
  "$schema": "https://nodejs.org/dist/latest-v26.x/docs/node-config-schema.json",
  "configs": [
    {
      "nodeVersion": 25,
      "config": {
        "$schema": "https://nodejs.org/dist/latest-v25.x/docs/node-config-schema.json",
        "nodeOptions": {
          "watch-path": "src"
        }
      }
    }
  ]
}

When configs is used, the top level may only contain $schema and configs. Each configs item must define an integer nodeVersion and an object config. A single top-level config does not require nodeVersion, but if present it must match the current Node.js major version.

When a namespace is present in the configuration file, Node.js automatically enables the corresponding flag (e.g., --test, --watch, --permission). This allows you to configure subsystem-specific options without explicitly passing the flag on the command line.

For example:

{
  "test": {
    "test-isolation": "process"
  }
}

is equivalent to:

node --test --test-isolation=process

To disable the automatic flag while still using namespace options, you can explicitly set the flag to false within the namespace:

{
  "test": {
    "test": false,
    "test-isolation": "process"
  }
}

No-op flags are not supported. Not all V8 flags are currently supported.

It is possible to use the official JSON schema to validate the configuration file, which may vary depending on the Node.js version. Each key in the configuration file corresponds to a flag that can be passed as a command-line argument. The value of the key is the value that would be passed to the flag.

For example, the configuration file above is equivalent to the following command-line arguments:

node --import amaro/strip --watch-path=src --watch-preserve-output --test-isolation=process

The priority in configuration is as follows:

NODE_OPTIONS and command-line options
Dotenv NODE_OPTIONS
Configuration file

Values in the configuration file will not override the values in the environment variables, command-line options, or the NODE_OPTIONS env file parsed by the --env-file flag.

Keys cannot be duplicated within the same or different namespaces.

The configuration parser will throw an error if the configuration file contains unknown keys or keys that cannot be used in a namespace.

Node.js will not sanitize or perform validation on the user-provided configuration, so NEVER use untrusted configuration files.

`--cpu-prof`

Starts the V8 CPU profiler on start up, and writes the CPU profile to disk before exit.

If --cpu-prof-dir is not specified, the generated profile is placed in the current working directory.

If --cpu-prof-name is not specified, the generated profile is named CPU.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.cpuprofile.

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

If --cpu-prof-name is specified, the provided value is used as a template for the file name. The following placeholder is supported and will be substituted at runtime:

${pid} — the current process ID

$ node --cpu-prof --cpu-prof-name 'CPU.${pid}.cpuprofile' index.js
$ ls *.cpuprofile
CPU.15293.cpuprofile

`--cpu-prof-dir`

Specify the directory where the CPU profiles generated by --cpu-prof will be placed.

The default value is controlled by the [--diagnostic-dir][] command-line option.

`--cpu-prof-interval`

Specify the sampling interval in microseconds for the CPU profiles generated by --cpu-prof. The default is 1000 microseconds.

`--cpu-prof-name`

Specify the file name of the CPU profile generated by --cpu-prof.

`--diagnostic-dir=directory`

Set the directory to which all diagnostic output files are written. Defaults to current working directory.

Affects the default output directory of:

[--cpu-prof-dir][]
[--heap-prof-dir][]
[--redirect-warnings][]

`--disable-proto=mode`

Disable the Object.prototype.__proto__ property. If mode is delete, the property is removed entirely. If mode is throw, accesses to the property throw an exception with the code ERR_PROTO_ACCESS.

`--disable-sigusr1`

Disable the ability of starting a debugging session by sending a SIGUSR1 signal to the process.

`--disable-warning=code-or-type`

Stability: 2 - Stable

Disable specific process warnings by code or type.

Warnings emitted from [process.emitWarning()][emit_warning] may contain a code and a type. This option will not-emit warnings that have a matching code or type.

List of [deprecation warnings][].

The Node.js core warning types are: DeprecationWarning and ExperimentalWarning

For example, the following script will not emit [DEP0025 require('node:sys')][DEP0025 warning] when executed with node --disable-warning=DEP0025:

import sys from 'node:sys';

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

For example, the following script will emit the [DEP0025 require('node:sys')][DEP0025 warning], but not any Experimental Warnings (such as [ExperimentalWarning: vm.measureMemory is an experimental feature][] in <=v21) when executed with node --disable-warning=ExperimentalWarning:

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

vm.measureMemory();

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

vm.measureMemory();

`--disable-wasm-trap-handler`

Node.js enables V8's trap-handler-based WebAssembly bound checks on 64-bit platforms, which significantly improves WebAssembly performance by eliminating the need for inline bound checks. This optimization requires allocating a large virtual memory cage per WebAssembly memory instance (currently typically 8GB for 32-bit WebAssembly memory, 16GB for 64-bit WebAssembly memory) to trap out-of-bound accesses. On most 64-bit platforms, the virtual memory address space is usually large enough (around 128TB) to accommodate typical WebAssembly usages, but if the machine has manual limits on virtual memory (e.g. through ulimit -v), WebAssembly memory allocation is more likely to fail with WebAssembly.Memory(): could not allocate memory.

At startup, Node.js automatically checks whether there is enough virtual memory available to allocate at least one cage, and if not, the trap-handler optimization is automatically disabled so that WebAssembly can still run using inline bound checks (with less optimal performance). But if the application needs to create many WebAssembly memory instances and the machine still configures a relatively high limit on virtual memory, allocation of WebAssembly memory instances may still fail more quickly than expected due to the raised virtual memory usage.

--disable-wasm-trap-handler fully disables this optimization so that WebAssembly memory instances always use inline bound checks instead of reserving large virtual memory cages. This allows more instances to be created when the virtual memory address space available to the Node.js process is limited.

`--disallow-code-generation-from-strings`

Make built-in language features like eval and new Function that generate code from strings throw an exception instead. This does not affect the Node.js node:vm module.

`--dns-result-order=order`

Set the default value of order in [dns.lookup()][] and [dnsPromises.lookup()][]. The value could be:

ipv4first: sets default order to ipv4first.
ipv6first: sets default order to ipv6first.
verbatim: sets default order to verbatim.

The default is verbatim and [dns.setDefaultResultOrder()][] have higher priority than --dns-result-order.

`--enable-fips`

Enable [FIPS mode][] at startup. With OpenSSL 3, a configured provider named fips must be available and initialize successfully. With OpenSSL 1.1.1, Node.js must be built against a FIPS-capable OpenSSL.

`--enable-fips-indicator-events`

Publish OpenSSL FIPS indicator results to the ['crypto.fips.indicator'][] diagnostics channel. This option requires OpenSSL 3.4 or later. It does not enable [FIPS mode][] or change whether an operation is permitted.

`--enable-source-maps`

Enable [Source Map][] support for stack traces.

When using a transpiler, such as TypeScript, stack traces thrown by an application reference the transpiled code, not the original source position. --enable-source-maps enables caching of Source Maps and makes a best effort to report stack traces relative to the original source file.

Overriding Error.prepareStackTrace may prevent --enable-source-maps from modifying the stack trace. Call and return the results of the original Error.prepareStackTrace in the overriding function to modify the stack trace with source maps.

const originalPrepareStackTrace = Error.prepareStackTrace;
Error.prepareStackTrace = (error, trace) => {
  // Modify error and trace and format stack trace with
  // original Error.prepareStackTrace.
  return originalPrepareStackTrace(error, trace);
};

Note, enabling source maps can introduce latency to your application when Error.stack is accessed. If you access Error.stack frequently in your application, take into account the performance implications of --enable-source-maps.

`--entry-url`

Stability: 1 - Experimental

When present, Node.js will interpret the entry point as a URL, rather than a path.

Follows [ECMAScript module][] resolution rules.

Any query parameter or hash in the URL will be accessible via [import.meta.url][].

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

`--env-file-if-exists=file`

Behavior is the same as [--env-file][], but an error is not thrown if the file does not exist.

`--env-file=file`

Loads environment variables from a file relative to the current directory, making them available to applications on process.env. The [environment variables which configure Node.js][environment_variables], such as NODE_OPTIONS, are parsed and applied. If the same variable is defined in the environment and in the file, the value from the environment takes precedence.

You can pass multiple --env-file arguments. Subsequent files override pre-existing variables defined in previous files.

An error is thrown if the file does not exist.

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

The format of the file should be one line per key-value pair of environment variable name and value separated by =:

PORT=3000

Any text after a # is treated as a comment:

## This is a comment
PORT=3000 # This is also a comment

Values can start and end with the following quotes: `, “ or '. They are omitted from the values.

USERNAME="nodejs" # will result in `nodejs` as the value.

Multi-line values are supported:

MULTI_LINE="THIS IS
A MULTILINE"
## will result in `THIS IS\nA MULTILINE` as the value.

Export keyword before a key is ignored:

export USERNAME="nodejs" # will result in `nodejs` as the value.

If you want to load environment variables from a file that may not exist, you can use the [--env-file-if-exists][] flag instead.

`-e`, `--eval “script”`

Evaluate the following argument as JavaScript. The modules which are predefined in the REPL can also be used in script.

If script starts with -, pass it using = (for example, node --print --eval=-42) so it is parsed as the value of --eval.

On Windows, using cmd.exe a single quote will not work correctly because it only recognizes double “ for quoting. In Powershell or Git bash, both ' and “ are usable.

It is possible to run code containing inline types unless the [--no-strip-types][] flag is provided.

`--experimental-addon-modules`

Stability: 1.2 - Release candidate

Enable experimental import support for .node addons.

`--experimental-bench`

Stability: 1 - Experimental

Enable the experimental node:bench module and command-line benchmark runner.

`--experimental-dtls`

Stability: 1 - Experimental

Enable experimental support for the DTLS protocol. See the [dtls documentation][] for details.

`--experimental-eventsource`

Enable exposition of [EventSource Web API][] on the global scope.

`--experimental-import-meta-resolve`

Enable experimental import.meta.resolve() parent URL support, which allows passing a second parentURL argument for contextual resolution.

Previously gated the entire import.meta.resolve feature.

`--experimental-import-text`

Stability: 1.0 - Early development

Enable experimental support for importing modules with with { type: 'text' }.

`--experimental-inspector-network-resource`

Stability: 1.1 - Active Development

Enable experimental support for inspector network resources.

`--experimental-loader=module`

This flag is discouraged and may be removed in a future version of Node.js. Please use [--import with register()][preloading asynchronous module customization hooks] instead.

Specify the module containing exported [asynchronous module customization hooks][]. module may be any string accepted as an [import specifier][].

This feature requires --allow-worker if used with the [Permission Model][].

`--experimental-network-inspection`

Stability: 1 - Experimental

Enable experimental support for the network inspection with Chrome DevTools.

`--experimental-package-map=<path>`

Stability: 1 - Experimental

Enable experimental package map resolution. The path argument specifies the location of a JSON configuration file that defines package resolution mappings.

node --experimental-package-map=./package-map.json app.js

When enabled, bare specifier resolution consults the package map for resolution. This allows explicit control over which packages can import which dependencies.

See [Package maps][] for details on the configuration file format and resolution algorithm.

`--experimental-print-required-tla`

If the ES module graph cannot be require()'d because it contains any top-level await, this flag allows Node.js to locate and print their locations.

`--experimental-quic`

Stability: 1.1 - Active development

Enable experimental support for the QUIC protocol.

`--experimental-sea-config`

Stability: 1 - Experimental

Use this flag to generate a blob that can be injected into the Node.js binary to produce a [single executable application][]. See the documentation about [this configuration][--experimental-sea-config] for details.

`--experimental-shadow-realm`

Use this flag to enable [ShadowRealm][] support.

`--experimental-storage-inspection`

Stability: 1.1 - Active Development

Enable experimental support for storage inspection

`--experimental-stream-iter`

Stability: 1 - Experimental

Enable the experimental [node:stream/iter][] module.

`--experimental-test-coverage`

When used in conjunction with the node:test module, a code coverage report is generated as part of the test runner output. If no tests are run, a coverage report is not generated. See the documentation on [collecting code coverage from tests][] for more details.

`--experimental-test-module-mocks`

Stability: 1.0 - Early development

Enable module mocking in the test runner.

This feature requires --allow-worker if used with the [Permission Model][].

`--experimental-test-tag-filte

（本文超出站点单文档体积上限，已截断）

Command-line API

Command-line API

Synopsis

Program entry point

Options

-

--

--abort-on-uncaught-exception

--allow-addons

--allow-child-process

--allow-ffi

--allow-fs-read

--allow-fs-vfs

--allow-fs-write

--allow-inspector

--allow-net

--allow-openssl-store

--allow-wasi

--allow-worker

--bench

--bench-isolation=mode

--bench-name-pattern=pattern

--bench-reporter-destination=destination

--bench-reporter=reporter

--bench-samples=count

--bench-warmup=count

--build-sea=config

--build-snapshot

--build-snapshot-config

-c, --check

--completion-bash

-C condition, --conditions=condition

--config-file=path, --config-file

--cpu-prof

--cpu-prof-dir

--cpu-prof-interval

--cpu-prof-name

--diagnostic-dir=directory

--disable-proto=mode

--disable-sigusr1

--disable-warning=code-or-type

--disable-wasm-trap-handler

--disallow-code-generation-from-strings

--dns-result-order=order

--enable-fips

--enable-fips-indicator-events

--enable-source-maps

--entry-url

--env-file-if-exists=file

--env-file=file

-e, --eval “script”

--experimental-addon-modules

--experimental-bench

--experimental-dtls

--experimental-eventsource

--experimental-import-meta-resolve

--experimental-import-text

--experimental-inspector-network-resource

--experimental-loader=module

--experimental-network-inspection

--experimental-package-map=<path>

--experimental-print-required-tla

--experimental-quic

--experimental-sea-config

--experimental-shadow-realm

--experimental-storage-inspection

--experimental-stream-iter

--experimental-test-coverage

--experimental-test-module-mocks

`--experimental-test-tag-filte

`-`

`--`

`--abort-on-uncaught-exception`

`--allow-addons`

`--allow-child-process`

`--allow-ffi`

`--allow-fs-read`

`--allow-fs-vfs`

`--allow-fs-write`

`--allow-inspector`

`--allow-net`

`--allow-openssl-store`

`--allow-wasi`

`--allow-worker`

`--bench`

`--bench-isolation=mode`

`--bench-name-pattern=pattern`

`--bench-reporter-destination=destination`

`--bench-reporter=reporter`

`--bench-samples=count`

`--bench-warmup=count`

`--build-sea=config`

`--build-snapshot`

`--build-snapshot-config`

`-c`, `--check`

`--completion-bash`

`-C condition`, `--conditions=condition`

`--config-file=path`, `--config-file`

`--cpu-prof`

`--cpu-prof-dir`

`--cpu-prof-interval`

`--cpu-prof-name`

`--diagnostic-dir=directory`

`--disable-proto=mode`

`--disable-sigusr1`

`--disable-warning=code-or-type`

`--disable-wasm-trap-handler`

`--disallow-code-generation-from-strings`

`--dns-result-order=order`

`--enable-fips`

`--enable-fips-indicator-events`

`--enable-source-maps`

`--entry-url`

`--env-file-if-exists=file`

`--env-file=file`

`-e`, `--eval “script”`

`--experimental-addon-modules`

`--experimental-bench`

`--experimental-dtls`

`--experimental-eventsource`

`--experimental-import-meta-resolve`

`--experimental-import-text`

`--experimental-inspector-network-resource`

`--experimental-loader=module`

`--experimental-network-inspection`

`--experimental-package-map=<path>`

`--experimental-print-required-tla`

`--experimental-quic`

`--experimental-sea-config`

`--experimental-shadow-realm`

`--experimental-storage-inspection`

`--experimental-stream-iter`

`--experimental-test-coverage`

`--experimental-test-module-mocks`