Run node --check app.js to check whether Node.js can parse a file without executing it. Checking JavaScript locally gives you a fast first result; an online validator for JavaScript can also help with a short, non-sensitive example. Neither replaces a test of what the program actually does.
Find and Fix a Syntax Error
With Node.js installed, save this example as app.js:
function double(value) {
return value * 2;
console.log(double(3));
Run the check from the directory containing the file:
node --check app.js
Node reports a SyntaxError and a location near the end of the file because the function’s closing brace is missing. The reported position is where the parser became unable to continue; the cause may be earlier. Read the surrounding lines and pair opening braces, brackets, parentheses, and quotes before editing.
Add the missing brace before the last line:
function double(value) {
return value * 2;
}
console.log(double(3));
A successful check typically produces no output. Run node app.js separately to execute the program; the corrected example prints 6. The Node.js CLI documentation describes the check option.
Add a Lint Check
A javascript code validator can find parse errors, but lint rules can also flag valid code that is likely to be a mistake. For example, after installing ESLint locally in a project with Node.js and npm, run:
npx eslint --no-config-lookup --rule 'no-undef: error' app.js
This command uses the stated rule without loading the project’s configuration. In PowerShell or a Unix-like shell the single quotes keep the rule argument together. In Windows Command Prompt, use double quotes instead. If ESLint is not already installed locally, install it as a development dependency with npm install --save-dev eslint before running the command.
The no-undef rule flags references to undeclared names. In this isolated example, tell ESLint that console is an available global by adding --global console to the command. Now change double(3) to duble(3): the code parses, but lint reports the unknown name and its line and column. Restore the spelling to fix the error.
A project’s own ESLint configuration can define its environment, globals, and rules. Use the project command when working in an existing repository; the isolated command above intentionally ignores that configuration. The ESLint CLI reference explains the options.
JavaScript Validator Online or Local Tool?
A JavaScript validator online is convenient for a small sample on a device without a local setup. When validating JavaScript online, check which language version and rules the service uses before relying on the result. Do not paste private code into a service unless its handling is approved. A local tool can use the same settings in an editor, command line, and continuous integration, making results easier to reproduce.
To validate JavaScript for a real project, match the parser and runtime to its actual environment. A Node check may not accept every file intended for a browser build pipeline without the project’s transformations. A clean parse only establishes that the selected parser accepts the syntax; it does not verify APIs or results.
Test Behavior After the Checks
Lint can catch an undeclared name, but it cannot prove that double implements the intended calculation. JavaScript code validation should be followed by tests with representative inputs and expected outputs. For this example, check zero and a negative number as well as 3; a browser feature also needs a test in the target browser.
After fixing a file, rerun node --check app.js and the relevant lint command. Then run the program or its automated tests and compare the result with the behavior you intended.