Replace global installations with npx

If you have Node.js installed on your computer, chances are that you use some kind of package manager to install dependencies and development dependencies. It’s most likely to be npm or yarn, but other, less frequently used tools are also available.

You can find a summary of some important and often used features of npm here.

What is npx?

While npm is used to install and manage packages from the npm registry, npx is a package manager that makes running them much easier, given that the package can also be found in the registry.

npx is bundled with npm from version 5.2. The current long term supported version of Node (8.12.0 as of today) comes with npm version 5.8, so npx is available on any system that has the latest Node.js.

Alternatively, npx can be installed separately typing in the terminal npm install -g npx.

Now let’s see how npx can replace some local and global installations.

Run locally installed packages

Say we want to write some test cases to our newly created functions and want to run them with Mocha.

In order to do that, we have to set up a test command in the scripts part of package.json, similar to this:

// ...
"scripts": {
    "test": "mocha test/**/*.test.js"
  },
// ...

Each time we want to run a test we can do it by typing npm test and if Mocha is installed in the node_modules folder of the project, Mocha will run and evaluate the assertions we wrote.

With npx, we don’t have to set up the test command anymore. Instead, we can type npx mocha from the project root folder and we’ll get Mocha running.

What happens when the npx <command> command is run?

npx reaches out to $PATH (folders where executables are stored) and checks if the command (in our case, mocha) exists either there or in the local node_modules folder. If Mocha is installed as a development dependency in the project folder, its binary will be found in node_modules. npm then executes the mocha command.

npx commands with arguments

Mocha looks for test files in the test folder by default. Some developers like to place the test files next to the function file though, like this:

modules
  |__ functions.js
      functions.test.js

The npx mocha command won’t work in this case.

It’s possible though to add arguments to npx commands. All we have to do is to type npx mocha modules/**/*.test.js and the assertions in the test files in the modules folder will be run. This line of command is not much shorter though, so it might not be worth using npx.

Replace global packages with npx

One of the best features npx offers is that we can run global CLI tools without installing them.

Scaffolding tools like Angular CLI, Create React App and the Express application generator might only be used when a new project is set up, which doesn’t happen every day.

For example, if you work with Angular to build the front end of the application, and have to add a new feature to an already existing project, you might have seen a message like this:

Your global Angular CLI version (6.1.5) is greater than your local
version (1.4.4). The local Angular CLI version is used.

Even if the latest version of Angular CLI is installed globally, the local version is used to generate new components, directives etc. So why bother with global installations?

npx shines in replacing global installations with nice one liners.

Example 1: Create a new Angular project

A new Angular project can be created with npm -p <package name> <command> <command arguments> syntax:

npx -p @angular/cli ng new my-new-project

npx will find the latest version of Angular CLI in the npm registry, downloads and uses npm to temporarily install the package to the npm cache. Then it adds this directory to $PATH, so the package (in our case, it’s Angular CLI) can run the ng new command with the my-new-project arguments. When it finishes running, npx will clean up after itself, i.e. removes the temporary directory from $PATH.

The -p or --package flag defines the package to be used (@angular/cli). This is what otherwise needs to be installed globally. The <command> part (ng new my-new-project) will execute after the package has been downloaded.

If we run the above command, we’ll get a brand new Angular project and we haven’t polluted our disk.

Example 2: Test servers with loadtest

loadtest is a tool to stress test servers and they also recommend to install the package globally. loadtest can also be installed as a development dependency, so it’s a great example to replace the installations with npx.

The following example assumes that we have a server (hopefully Node.js :) ) running on port 3000. We can type the following in a separate terminal window:

npx loadtest http://localhost:3000 -c 10 -t 5

Here we don’t even need to use the -p flag as it defaults to <command>, which is loadtest in this case. Here the command and the name of the package will be the same.

The next few arguments belong to loadtest: The URL of the server, the number of concurrent requests and the time in seconds while the stress test lasts.

Once loadtest has done its job, we will see the report in the terminal after 5 seconds.

Conclusion

npx is a great package manager tool that can do much more than described in this post. One can run scripts and even access environment variables with npx.

Two of its main benefits are though that we can run local packages without extra configuration in package.json and we don’t have to install once-in-a-while used CLI tools globally anymore.

Thanks for reading and see you next time.