Command Line Flags by the Node Binary

In this article, we will learn about the command line flags offered by the Node binary. The Node.js platform is almost entirely represented by the node binary executable. In order to execute a JavaScript program we use: node app.js, where app.js is the program we wish to run. However, before we can start running programs, we need to learn some basic command line flags offered by the Node binary and how to use them.

Printing command options: In order to view the command-line flags for any version of the node, we can use the –help flag. Write the below code in the terminal:

node --help

Beyond the Node command line flags, there are additional flags for modifying the JavaScript runtime engine: V8. To view, these flags run node –v8-options. Write the below code in the terminal:

node --v8-options

This was all about the command line, now we need to know how to use it in order to save the hassle while the program is being executed. As you might know, the most basic requirement for a program to execute is that there shouldn’t be any syntax errors. Some popular IDEs like VS Code come with tools like Intellisense which informs the users in case of any syntax errors, but what if you don’t want to use the extensions and actually use the command line to know if there are any syntax errors. The node binary aids this too.

Checking the Syntax: It is possible to parse the JavaScript Application without actually running it, just to check the syntax.

To check the Syntax we can use:

node --check app.js
node -c app.js

Note: Any one of the flags can be used from the above list. On successful parsing one of the two things happen:

• There is no syntax error and no output is generated
• There is an error and an error message is displayed in the terminal window.\

Example 1: This is Case 1 where there isn’t any syntax error:

Javascript

const func = () => {
    console.log("This block of code is "
      + "the example of good/correct syntax");
}

Step to check the Syntax: Write the below code in the terminal to check the syntax:

node --check app.js

Output:

Example 2: This is Case 2 where there is a syntax error.

Javascript

const func: () => {
    console.log("This block of code is an example of incorrect syntax.");
}

Step to check the Syntax: Write the below code in the terminal to check the syntax:

node --check app.js

Output:

In this way, we can check whether or not our code has any syntax errors.

Dynamic Evaluation: Node can directly evaluate code from the shell, which becomes very useful for quickly checking a code snippet. There are two flags that can evaluate the code. They are as follows:

• -p or –print: Evaluates the expression and prints the result.
• –e or –eval: Evaluates the expression but doesn’t print the result.

Here are a few examples of how the –print and –-eval flag works:

node -p "2+2"
node -e "2+2"

As you can see the –p flag evaluates the expression 2+2  and prints 4 as the output.

Consider another example that evaluates the console.log function in the command line:

node -e "console.log(2)"

The –eval or -e flag doesn’t generate any output but here, as the console.log prints 2, the output is explicitly generated.

Similarly, when console.log  is evaluated using the –print flag, this is what we get as the output:

node -p "console.log(2)"

2 is generated as output because it is explicitly printed using the console.log function, also undefined is printed in the terminal because console.log itself returns undefined.

Another example is where we can use the -p or –-print flag to print all the files with the .js extension in the current working directory.

For the below example, these are the files that we have in the current directory:

We can use the –print flag as follows:

node -p "fs.readdirSync('.').filter(cf=>/.js$/.text(cf))"

Pre-Loading CommonJs Modules: The command line flag -r or –require can be used to preload a CommonJS module before anything else loads.

Suppose that there are two files preload.js and app.js, and their content is as follows:

Now in order the preload a file over another, we can use the –require flag as follows:

node --require ./preload.js app.js

Preloading modules is useful when using consuming modules that instrument or configure the process in some way.

NOTE: There are two module systems that Node uses, CommonJS and ESM, but it’s important to note here that the –require flag can only preload a CommonJS module, not an ESM module. ESM modules have a vaguely related flag, called –loader, a currently experimental flag that should not be confused with the –require preloader flag. For more info on CommonJS and ESM modules, refer to the node documentation here.

Stack Trace Limit: Stack traces are generated for any Error that occurs, so they’re usually the first point of call when debugging a failure scenario. By default, a stack trace will contain the last ten stack frames (function call sites) at the point where the trace occurred. This is often fine because the part of the stack you are interested in is often the last 3 or 4 call frames. However, there are scenarios where seeing more call frames in a stack trace makes sense, like checking that the application flow through various functions is as expected.

The stack trace limit can be modified with the –stack-trace-limit flag. This flag is part of the JavaScript runtime engine, V8, and can be found in the output of the –-v8-options flag.

Consider a file named will-throw.js, with the following contents:

Javascript

function f(n = 99) {
    if (n == 85)
        throw Error();
    f(n - 1)
}
f()

When we execute the following command in the command line:

node --stack-trace-limit=10 will-throw.js 

There will be only ten stack frames in the error output because the limit is explicitly set to 10.

What if we set the limit to say 1000, something like this:

node --stack-trace-limit=1000 will-throw.js

In this case, we can display output to 1000 stack frames.

We see that setting the stack trace limit to a number higher than the number of call frames in the stack guarantees that the entire stack will be output (In our case greater than 85).

But wait, is it really feasible to change the default limit of the stack frames?

The answer is NO because in production scenarios the overhead involved with retaining long stacks will not only cause overhead but also consume a lot of memory space, ultimately degrading the performance of your application.