TomNPX, NPM, NP-What?
You've probably seen it here and there, but didn't really know what it does exactly and, to be honest, didn't really care - that's how I treated NPX after I first saw it. Yet little did I know what mighty and handy library NPX is and how it would change my workflow for the better, as it did for the whole team! So without further ado (to once again use my 18th-century-English, as keen as a mustard), let's take a look at it!
The Manager
To recall, NPM stands for Node Package Manager. NPM's job is to manage the dependencies in your project - no more, no less. NPM can add other libs to your project, remove them and keep the overall dependency-state sane across various users of the project thanks to its lock-file.
But what you can't do with NPM is do much else with your external modules. Sure, there's the script-key in package.json, but that helps you only add predefined routines or custom ones, such as build and deploy, which are callable via npm run.
And just like most npm-users, you've already used certain special commands in your scripts, which are provided from installed dependencies. As an example, you can call the mocha-tool or the firebase-tool by installing mocha and firebase-tools, respectively.
And when using such tools, npm always threw an error if the related library wasn't installed globally, ergo in a special place on your mechanical calculator, consumable by every npm-project.
But what if you don't want global depdencies? What if such tools should be used on a per-project basis? Introducing NPX.
The Executor
NPX stands for Node Package Executor/Runner (although I couldn't find a scientific valid source for the exact meaning, which is odd!), and its job is not to manage dependencies, but to look into the currently available project (based on your current path) and allow you to execute said tools locally.
You can call any tool in your project via npx [tool-name] [tool-args] and execute it locally, without having to install anything globally. This means that
- with a single npm i, all your depencies get installed, same for every user of the project - this means after installing, you're instantly ready to go!
- safety for your dependencies - a globally installed tool might be too old or too new to work in the current project, using a local module solves this problem, as the tool's version always represents the currently correct one to use
If NPX doesn't find the the tool installed locally, it automatically installs it (transparently for you) in a seperate global directory at the latest version and caches it there. This works as a fallback.
NPX comes bundled by default with the current NPM-install, so you can use it right from the get-go.
It's just the beginning
And that's about it for a brief introduction to NPX vs NPM. By using NPX, you can avoid errors and the hassle of handling global dependencies. You just install your external modules once and can safely use any tools provided - and every member of your team as well.
There's much more to learn and be amazed of regarding NPX, so if you're curious, just check out the link below. Thanks for the read!
- Tom