Last night I attended waffle.js and heard a great talk by Laurie Voss, aka seldo, the CTO of npm, about new features in npm@5. Several things have been upgraded and new features have been added in npm@5, so, if you haven’t upgraded yet, you’re missing out.
Here are a few things were upgraded in npm@5:
1 ) npm@5 is fast
npm@5 is much faster than previous versions of npm, and as easy to install as:
npm i npm -g
npm@5 is ten times faster than npm@4.
npm@4 is ten times faster than npm@3.
npm@3 is ten times faster than npm@2.
npm@2 is ten times faster than npm@1.
What does this mean?
10 x 10 x 10 x 10 = 104 = 10,000
It means the current version of npm is 10,000 faster than v1. Yes, I am exaggerating, but just a bit. Believe me, npm@5 is super fast.
Package lock makes npm faster because it doesn’t have to look up all the packages: it knows to use the ones you locked in. In addition, with locked packages, you get the same package versions in production as you do in development. This makes builds more reliable. Gone are the days of trying to figure out a bug only to discover it came from others running different versions of a library.
This does change how updates work. You will no longer automatically get the latest updates. Rather, you now need to explicitly update your packages to semver compatible package versions.
npx npm-check -u
The above snippet will make you go thru each npm update, allowing you to accept or decline breaking changes. npx is introduced in #6 below.
3) npm@5 saves by default
The risk of accidentally deleting a package is gone. You no longer have to use --save
. If you install a package it will be there. If you don’t want the package anymore, you can delete it.
If you don’t want to save, you can override the default saving with --no-save
.
4) Improved cache
Unbeknownst to many, npm has always had a cache — everything downloaded was stored locally — but not a very good one.
The cache improvements in npm@5 include how corrupt caches are handled: cache --clear
has been made obsolete as with npm@5, if the cache is corrupted it will not be used.
5) npm@5 works offline
npm@5 auto detects when you are offline. When offline, npm will install using the local, improved, non-corrupted cache, noted in #4 above. You can force npm to run offline when you are actually online, by using --offline
, This is handy for less than optimal connections, like when you’re whining about airplane, Starbucks, or conference wifi, and for those on metered data plans.
The new npx
package runner will download, install, execute, and clean itself up. The order will be executed either locally or from a cache, installing any dependencies needed. If a full package specifier is included, npx will use a freshly-installed, temporary version of the package. If no –package option is specified, npx can guess the name of the binary to invoke depending on the specifier provided.
As an example, if you want to create a React app, simply run:
$ npx create-react-app
$ npm start
This will create a working React app.
The npx package runner is probably the most exciting of the six new features. Laurie’s talk covered the syntax for creating working apps for various libraries.
Future feature: cipm
cipm, the continuous integration package manager currently under development, installs npm dependencies from a package lock. Similar in usage to npm install
, cipm
removes node_modules before beginning the install. It works with npm@5’s lock file. cipm is useful in continuous integration environments requiring regular, full installs of apps that can cache package data in a central cache.
You can take a look at https://github.com/zkat/cipm. Play with it, but don’t put it into production. Yet.