Why NPX?

Over the past few years, the NPM ecosystem has become increasingly dependent on development of local installation projects rather than global installations.

Tools like Mocha, Grunt, and Bower used to be installed globally, but now you can manage versions of them locally.

This also means that all you need to do to get an NPM-based project up and running is make sure you have Node + NPM on your system, clone the Git repo, and then run the NPM to run the installation and tests. Because NPM run-script adds the local binaries to the path, it works fine!

The downside is that this does not provide a quick/convenient way to interactively invoke the local binaries.

There are several ways to do this, and they all have some complications:

  • You can add these tools to your scripts, but you need to remember to use — pass parameters,
  • Alias NPMX =PATH= (nPMbin) : (NPM bin) : (nPMbin) : PATH
  • You can manually specify paths for them using./node\u modules/.bin/mocha. It all worked, but none of it was ideal.

NPX is considered the best solution: $NPX Mocha is all you need to do using your local installation. If you take extra steps and configure shell auto-fallback, then $Mocha in the project directory will help you!

In addition, if you call an already installed binary, NPX has virtually no overhead and can load the tool’s code directly into the currently running Node process.

introduce

[email protected] version, installed with a NPM package runner.

If it does not work, install it manually

npm install -g npx
Copy the code

NPX is a tool designed to help perfect the experience of using software packages in the NPM registry – NPM makes it super easy to install and manage dependencies hosted in the registry, NPX makes it easy to use CLI tools and other executables hosted in the registry. So far, it has greatly simplified many of the things that need to be done programmatically using pure NPM:

Using a native installation tool without NPM run-script:

Install cowsay as a local development dependency and run it through NPX Cowsay

Use guide

Invoke the module installed by the project

(1) Presentation

  • The test tool Mocha was installed internally.

    npm install -D mocha

  • In general, Mocha can only be called in the scripts fields of project scripts and package.json. If you want to call Mocha from the command line, you must do something like this.

    // Run node-modules/.bin/mocha –version in the root directory of the project

  • NPX is intended to solve this problem by making it easier to use modules installed inside the project, simply by calling them as follows.

    npx mocha –version

(2) The principle of NPX

Bin and the environment variable $PATH to check if the command exists.

Since NPX checks the environment variable $PATH, system commands can also be invoked.

# = ls $NPX lsCopy the code

Note that the commands built into Bash are not in $PATH, so they don’t work. For example, CD is the Bash command, so you can’t use NPX CD.

Control calls to local/remote modules

  • Force the use of local modules, do not download remote modules,--no-install

If the module does not exist locally, an error is reported.

npx --no-install http-server
Copy the code
  • Ignore local modules with the same name and force the installation to use remote modules.--ignore-existing

For example, if create-react-app is installed globally locally, but you still want to use remote modules, use this parameter.

npx --ignore-existing create-react-app my-react-app
Copy the code

NPX checks for the presence of commands in node_modules/. Bin and the environment variable $PATH.

Run the one-time command to avoid global installation

$NPX create-react-app my-app Installs a temporary create-react-app and calls it without polluting the global installation

scenario

For example, trying some CLI tool, but only installing a global to run it once, is annoying?

steps

  • Calling NPX when not in $PATH automatically installs a package with that name from the NPM registry and calls it.
  • NPX willcreate-react-appDownload to a temporary directory and delete after use.
  • When done, installed packages will be removed without appearing in Globals, without worrying about global contamination.

advantages

  • Avoid global module installation and occupy local resources.
  • Don’t worry about delayed module version updates;

apply

This feature is perfect for requirements such as generator CLI, such as · Yeoman or create-React-app.

Similar packages: happy-birthday, Benny-Hill, Workin-Hard, Cowsay, Yo, create-React-app, NPM-check. See the full NPX repository for more

Use different versions of Node

NPX -p node@

node -v can be used to run the node version at once

operation

(1) Directly use NPX

NPX [email protected] - vCopy the code

The principle is to download this version of Node from NPM, use it and then delete it.

(2) Specify the module using the -p parameter

$NPX -p [email protected] node -v v0.12.8Copy the code

The -p parameter is useful for scenarios where multiple modules need to be installed.

The -p option of NPX allows you to specify the package to install and add it to the running $PATH,

$ npx -p lolcatjs -p cowsay [command]
Copy the code

Application scenario: Test the running status of the project in different Node versions

Specify the version

NPX [email protected] main.js -o./dist/main.jsCopy the code

As long as the module after NPX cannot be found locally, the module with the same name will be downloaded

Interactive development of NPM run-script

$ npx -p cowsay -p lolcatjs -c ‘echo “$ npm_package_name@$npm_package_version” | Cowsay | lolcatjs’ Both Cowsay and LolcatJS are installed and the script is allowed to access a series of $NPM_ ‘variables from the running script.

Many NPM users are now taking advantage of this very cool run-script feature. Not only do they arrange your PATH so that local binaries are accessible, but they also add a number of environment variables that you can access in these scripts! You can make local binaries accessible through PATH, and you’ve also added a number of environment variables that you can access in these scripts! You can make local binaries accessible through PATH, and you’ve also added a number of environment variables that you can access in these scripts! You can use the NPM run env | grep NPM to check these additional variables.

This makes developing and testing scripts to run tricky — it means that even with tricks like $(NPM bin) /some bin, you still can’t access those magic env variables while interacting.

Here’s another trick with NPX: When you use the -c option, scripts written in the string argument will have full access to the same env variables as regular running scripts! You can even use pipes and multiple commands with a single NPX call!

-c Specifies the function of the parameter

(1) Control commands are explained using NPX

If NPX installs multiple modules, by default, only the first executable of the command executed will use the module installed by NPX, and the subsequent executables will be interpreted by the Shell.

$NPX - p lolcatjs -p cowsay 'cowsay hello | lolcatjs' # errorCopy the code

The above code, cowsay hello | lolcatjs executes error, the reason is that the first cowsay the NPX the explanation, and the second command localcatjs is interpreted by a Shell, but there is no global lolcatjs and installed, so an error.

The -c argument interprets all commands with NPX. With this, the following code should execute normally.

$ npx -p lolcatjs -p cowsay -c 'cowsay hello | lolcatjs'
Copy the code

(2) Put the environment variable into the command to be executed. For example, NPM provides some environment variables for the current project, which can be viewed with the following command.

$ npm run env | grep npm_
Copy the code

The -c argument carries these NPM environment variables into the NPX command.

$ npx -c 'echo "$npm_package_name"'
Copy the code

The above code prints the project name of the current project.

Execute Github source code

Instead of setting up whole Git repos, releasing new tools, etc., share utility scripts at gist.github.com.

With NPX, you can go one step further: since NPX accepts whatever specifiers NPM itself accepts, you can create a bullet point that people can call directly, with just one command!

NPX can also execute the GitHub module source code.

# warehouse code executed Gist code $NPX https://gist.github.com/zkat/4bc19503fe9e9309e2bfaa2c58074d32 # $NPX lot: piuccio/cowsay helloCopy the code

Note that the remote code must be a module, that is, it must contain package.json and entry scripts.

Bonus round: Shell automatically falls back

Putting NPX automatically back into. ZSHRC means you can execute ‘$ember-cli@latest… ‘Don’t reference NPX at all!

This great feature, added by Felix Saparelli, means that for many of these use cases, you don’t even need to call NPX directly! The main difference between regular NPX use and fallback is that, unless you use the wrapper @ version syntax: a safety net against potentially dangerous squatting.

Setting up automatic fallback is simple: find the command for the current shell in the NPX document, add it to.bashrc/.zshrc/.fishrc, and then restart the shell (or refresh the shell using source or some other mechanism).

Now, you can do something like standard @8−− version to try different versions of things, if you’re in an NPM project, standard @8−− version to try different versions of things, if you’re in an NPM project, Mocha will automatically revert to the locally installed version of Mocha if it has not been installed globally.

The resources

  • NPX package management

  • The official warehouse

  • Mp.weixin.qq.com/s/4Pc4EkRm2…

  • www.npmjs.com/package/npx

  • Alligator. IO/workflow/np…

  • medium.com/@maybekatz/…