7 More npm Tricks to Knock Your Wombat Socks Off
There are definitely some tricks when it comes to using npm’s CLI. There’s a ton of small features that you’d never know about unless someone told you or you inspect the docs insanely thoroughly.
If you missed it, we put out a set of 11 Simple npm Tricks to Knock Your Wombat Socks off a few months ago. Since then, I’ve been using them as appropriate - I’ve gotten way faster working with Node.js and npm.
That said, we’ve gone through and collected yet another set of really awesome and useful tricks to speed up your productivity when using npm - with Node.js, on the front-end, or for anything else. Yet again, there’s one killer trick in here that’s helped tremendously: adding npm autocompletion to my shell. That's mine, but I'm sure you'll find a helpful one, too!
1. View Globally Installed Node Modules
I’ve run into a problem a handful of times where I’ve globally installed a module that I want to start using when I’m working. When it finally comes time to use it, I can’t actually *remember *what it was.
Thankfully, there’s a super easy way to solve this - you can list out all your globally installed modules with one simple command:
npm ls -g --depth 0
The command will run for a bit, depending on how many global modules you have, and then print out a list of them all.
Hat tip to @reverentgeek for sharing this one.
2. Adding npm Command Autocompletion to Your Shell
If you want to get a quick improvement to your npm productivity, you can add autocompletion for npm to your shell with just one command.
bash, you can add npm autocompletion with:
npm completion >> ~/.bashrc
zsh, you can add npm autocompletion with:
npm completion >> ~/.zshrc
And now you’ll have tab autocomplete for npm commands.
3. Check Your Packages for Security Vulnerabilities
Almost all Node projects have dependencies. One of those dependencies can and will have a vulnerability that’s found and made public at some point - one example is moment, which had a regular expression denial of service vulnerability.
Thankfully, tools like Snyk can inform you if any of your packages have a security vulnerability. They can run on the CLI, in your CI/CD, and automatically against your commits. You can set up Snyk to monitor your npm dependencies in a given project with the following commands:
npm install -g snyk cd ~/code/my-node-project/ snyk monitor
4. Set a Custom npm Configuration Per-Project
Your default npm configs live in
~/.npmrc - this includes the settings you set up through
npm config [...]. These user defaults can be overridden with an added
.npmrc inside of a Node project to enforce standardization of npm with your packages as well.
You can see your
.npmrc file with the
npm config list
Additionally, to see all the settings npm is currently using, including the defaults, you can run:
npm config list -l
5. Modify Your Log Level To Get More
Adjusting npm’s loglevel allows you to set the level of output for
npm install. In total, there are seven different levels.
loglevel defaults to
warn, but you can expand or throttle that as you’d like. The different options are:
silly. If you just want to make installs more verbose, and actually see how many requests and other dependencies are being fetched, go ahead and try:
npm config set loglevel http
6. Link Your Local Dependencies for Development
If you’re working with package that depends on another package that’s needs updating, npm’s
link can help. It allows you to have a local copy of that other package linked inside of a dependency tree. This local development step provides a major assist with verifying code changes are valid before actually publishing to npm.
If the package is very deep in the dependency tree, or depended on multiple time look, at a tool like lnr.
For example, let’s say we want to update the
cookie module and verify it works with
cd cookie // Go to your local cookie package npm link // Link the local cookie package cd ../express // Go to your application npm link cookie // Links the local cookie package to your application npm install // Will ignore the local cookie package when installing modules
This allows us to make our changes to the cookie module and update express at the same time if need be. We can then publish our local
cookie package and update our app,
express, with the new package version.
7. Ensure Your Packages are Running in Node Securely
If you’re running a specific Node version in production, you need to make sure your dependencies actually work with the Node version that you’re running. Luckily, there’s a quick trick to get npm to verify that your packages say they’re compatible with the version of Node you’re running.
npm config set engine-strict true
Additionally, if you want to block npm scripts (for security reasons), you can set the
ignore-script config option - this will completely block any scripts in an application’s
package.json - including the application’s dependencies. To do this, you can run:
npm config set ignore-scripts
One last thing...
For some more awesome npm stuff, check out Sindre’s awesome-npm list - you’ll find some pretty nifty stuff there!