Run and Check JavaScript with Node.js on Linux

You will finish with a small, repeatable Node.js command-line workflow: identify the installed runtime, run a short expression, check a JavaScript file without executing it, and run Node's built-in test runner. The examples use Node.js v24.21.0 from package version 24.21.0-1nodesource1, installed here as both node and nodejs. Allow about fifteen minutes if you already have a script to test.

You need a shell and the nodejs package. These examples do not need sudo. Keep application files in a working directory you control. Running JavaScript can read files, open network connections or start child processes, so do not execute code you have not inspected.

1. Check the runtime you are about to use

Start with read-only checks. The two command names are aliases on this installation, and the manpages are identical:

$ command -v node
/usr/bin/node
$ node --version
v24.21.0
$ nodejs --version
v24.21.0
$ dpkg-query -W -f='${Package} ${Version}\n' nodejs
nodejs 24.21.0-1nodesource1

Your path or package version may differ. The useful checkpoint is that the command resolves to the runtime you expect. If a project requires a particular major version, compare this result with its documented requirement before installing dependencies or changing system packages.

2. Evaluate one expression without creating a file

Use --eval, or its short form -e, for a small one-off action. The shell handles the outer quotes and Node.js receives the JavaScript inside them:

$ node --eval 'console.log(JSON.stringify({ runtime: process.version, platform: process.platform }))'
{"runtime":"v24.21.0","platform":"linux"}

This is ordinary user-level execution. It does not alter Node.js configuration, but the JavaScript itself can still alter your files or contact a service. A common trap is confusing shell syntax with JavaScript syntax. Keep the complete JavaScript expression inside one quoted argument, and use double quotes inside it when that makes the boundary clearer.

Use --print, or -p, when you want Node.js to print the value of the expression automatically:

$ node --print '2 ** 8'
256
$ node -p 'process.arch'
x64

3. Check a file without running it

From the directory containing your script, run --check (or -c):

$ node --check app.js
$ printf 'syntax check exit status: %s\n' "$?"
syntax check exit status: 0

A successful check prints no normal output and returns status 0. It checks syntax without executing the script, so it will not prove that imports resolve, files exist or the application behaves correctly. If the syntax is invalid, Node.js prints an error and exits non-zero. Fix the reported location, then repeat the check.

Do not use shell redirection to replace the original script while experimenting. If you need to generate a changed file, write to a new name, check it, and replace the old file only after reviewing the difference. Replacement can discard work and is not automatically reversible.

4. Pass script arguments deliberately

When a script filename is followed by more words, Node.js passes those words to the script as arguments. The first application argument is available at process.argv[2] in this form:

$ node app.js --input '/path/to/data.json' --verbose

If an argument begins with a hyphen and must not be treated as a Node.js option, put -- before the script filename or before the remaining arguments as appropriate for your command shape:

$ node -- app.js --input '/path/to/data.json'

Quote paths and values that may contain spaces. Avoid building a command by concatenating untrusted text into a shell string. Passing separate, quoted arguments keeps the shell from interpreting characters such as semicolons, dollar signs and wildcard patterns.

5. Run the built-in test runner

Node.js v24 includes the command-line test runner. Run it from the project directory with --test:

$ node --test

The exact test names, counts and timing depend on the files in your project. A passing summary should show zero failed tests. The runner discovers test files according to Node.js's test-runner rules; if it reports that no tests were found, inspect the file names and the current directory rather than assuming the application is tested.

For a single known test file, name it explicitly:

$ node --test test/basic.test.js

Do not add --watch to a command intended for automation. Watch mode restarts the process when the entry point or watched files change and keeps the terminal occupied until you stop it with Ctrl-C:

$ node --watch app.js

6. Keep environment settings visible

NODE_OPTIONS adds allowed Node.js options before the options on the command line. That means an inherited environment can change how an apparently simple command behaves. Inspect it when debugging a surprising result:

$ printf 'NODE_OPTIONS=%s\n' "${NODE_OPTIONS-}"
NODE_OPTIONS=
$ env | grep '^NODE_OPTIONS=' || true

For a one-command experiment, set a value explicitly and let it disappear when the command exits:

$ NODE_OPTIONS='--trace-warnings' node app.js

Do not put secrets in NODE_OPTIONS, shell history or a shared service environment. The manpage also documents NODE_PATH for adding module-search directories, but it can make a script load a different module from the one you expect. Prefer the project's normal dependency layout and inspect the working directory when module resolution fails.

Node's REPL history is stored in ~/.node_repl_history by default. Set NODE_REPL_HISTORY to an empty value if commands entered interactively must not be persisted:

$ NODE_REPL_HISTORY='' node

This affects the REPL process only. It does not erase an existing history file. If you need to remove that file, review its exact path first and make a deliberate backup or deletion decision.

7. Avoid unsafe TLS shortcuts

Never use NODE_TLS_REJECT_UNAUTHORIZED=0 as a routine fix for certificate errors. The installed manpage says that value disables TLS certificate validation, which permits an active network attacker to impersonate a service. Fix the certificate chain, trust store or proxy configuration instead. Similarly, treat --insecure-http-parser as a compatibility exception only: the manpage warns that accepting invalid headers can enable request-smuggling attacks.