3 Pretty Cool Built-In Node.js Modules

nancy

10 min readNov 15, 2020

Source: The Author

Before we start: This is the second part, for 4 more practical built-in modules you can have a look here:

4 Very Useful Built-In Node.js Modules

A deeper look at perf_hooks, fs, os, and URL

medium.com

What Are Built-In Modules in Node.js?

Node.js has some so-called built-in modules. This means that although these modules work like other modules that we can install, e.g., via NPM and then include using the require or import syntax, as the name suggests, built-in modules are already installed and, therefore, always available.

And of course, they are maintained by the development team behind Node.js, so everything is always up to date and we can use the modules without worries.

Features of the modules that are deprecated can be recognized as such in the official documentation.

So, all good reasons to have a look at some of these modules and to use them in our next project.

1. Reading data from input streams like the keyboard (readline)

Admittedly, there are many libraries that provide the ability to read & process input from the console. But also the readline module has some really cool features that we can take a look at now.

Prompt and process input in the Console

const readline = require('readline')const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout,
})console.log('Enter a number, Node will double it for you')rl.question('Your Number: ', (number) => {
  console.log(parseInt(number) * 2)
  rl.close()
})

Important: Input in the console is always captured as string by this module
besides we always have to create rl using the createInterface function first, as given above. In the following code I will omit this.

Output any input that the user confirms with Enter

rl.on('line', (input) => {
  console.log('You entered: ${input}')
})

So it works like rl.question, but without the question.
If we want, we can of course stop the reading of user input with rl.close() here and in all other functions of readline at any time.

Register if a user wants to terminate the program with ctrl-C

rl.on('SIGINT', (input) => {
  console.log('you exited')
  process.exit()
})

Caution: This is only a listener, so the program must be terminated by e.g. process.exit(), otherwise the user cannot terminate the program himself with ctrl-C.

Furthermore, we can practically combine this with rs.question to require user input. This way, if the user enters “yes” or “y”, we can terminate the program at their request.

rl.on(‘SIGINT’, (input) => {
  rl.question(‘Are you sure you want to exit? ‘, (answer) => {
    if (answer.match(/^y(es)?$/i)) process.exit()
    else console.log(‘glad you stay’)
  })
})

This way you can doubly ensure that the user has not inadvertently pressed ctrl-c.

2. Run shell commands with Node (child_process)

The child_process module can be used for many different things, but essentially it’s all about what the name says. Running processes, more or less in the background.

I will now show you how to use it to execute shell commands that won’t interrupt your Node.js app.

Use ls to list the contents of the higher-level directory

const { exec } = require(‘child_process’)exec('cd .. && ls', (error, output) => {
  if (error) throw error
  console.log(output)
})

Theoretically there are no limits, the terminal commands can be strung together on both Windows and Linux with “&&”, and thus various commands can be executed one after the other.

You can integrate exec into the flow of the Node App super fluently and thus also send content from a file with Express.js as HTTP response to the user. Of course this is only for illustration.

app.get(‘/’, (req, res) => {
  exec(‘cat test.txt‘, (error, output) => {
    res.send(output)
  })
})

3. Run JavaScript code in a virtual machine, in Node.js (vm)

Personally I think vm is one of the most interesting modules, because there is so much to try with it.
Let’s start with a little code.

We define “x” as a global variable. Nothing special, but keep this in mind.
Then we take the variable x into the context of our VM, which we do with createContext.
Our code variable is then the JavaScript code that we want to execute in our VM. Here we access x without having created it in the code itself. x is only available because we passed it into the context.
We also create two other variables. Important: If we want to access the variables in the VM context outside of the VM afterwards, they apparently must not be available as let or const, we must use the var keyword.
Finally, with runInContext we can bring together and execute our context with the variable x, which we borrow from the global scope, and the code to be executed in the VM.

Okay, let’s work with the VM:

Whenever we want to access variables in our VM context, that is, the code, we can do this using the context object:

console.log(context.x) // 41
console.log(context.y) // 17

We we see everything as expected. Since x was global 1 and we added 40 in VM, it is now in VM 41.
But if we want to access the variable x in the global scope, it is unchanged:

console.log(x) // 1

And of course we can execute the function from within the VM:

console.log(context.hello()) // “from the VM”

A note from JavaScript in Plain English:

We have launched three new publications! Show some love for our new publications by following them: AI in Plain English, UX in Plain English, Python in Plain English — thank you and keep learning!