Here’s what you need to know about npm 5

This blog post was written under the Pusher Guest Writer program.

I’m sure you’ve heard the news by now, npm5 is here and it’s faster, stabler, and more secure than ever!

The npm team recently made the announcement on their blog and npm 5 is a result of months of hard work from the team.

What’s new in npm 5?

Existing npm caches will no longer be used: you will have to re-download any cached packages. There is no tool or intention to reuse old caches. This is due to the fact that the old method of caching has been replaced and package caching is now being handled with pacote and cacache. You can read more about that here.

npm will now save by default. In the previous version of npm, if we wanted to save a package, we were forced to add the --save flag while installing a new package, which was cumbersome in the development workflow. With the release of npm5, this is now easily achievable with the commands below:

bash
1#npm 5
2
3npm install package-name
4
5
6# Before
7
8npm install package-name --save
Copy

Of course, if you would like npm to work in a similar fashion (no autosave) to how it was working in previous versions, you can update the config option to enable autosave. Below is an example of how to do this:

bash
1npm config set save false
Copy

To get the current setting, you can execute the following command:

bash
1npm config get save
Copy

New package-lock.json. A package-lock.json will be created for you automatically**.** This is a new, standardized lockfile feature meant for cross-package-manager compatibility. This means that the versions of the packages in use will be locked down and headaches about different package versions will be eliminated.

A lockfile is a file automatically created by the package manager itself. It locks down the exact versions of the packages that have been installed and all their dependencies. It also allows cross-package-manager compatibility (npm, Yarn, Bower, JSPM) as a standardized lockfile means the versions of the dependencies needed are locked

The major difference between yarn’s lock file (Yarn is a package manager built as an open source collaboration between Facebook, Google and others that promises fast and secure dependency management) and npm’s lock file lies in the formatting. Yarn uses a custom format because it makes it easier to read and review. It also implies that merge conflicts are handled automatically by version control (read more about this here). Below is an example of a lockfile from yarn:

bash
1# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
2# yarn lockfile v1
3abbrev@1:
4  version "1.1.0"
5  resolved "https://registry.yarnpkg.com/abbrev/-/abbrev-1.1.0.tgz#d0554c2256636e2f56e7c2e5ad183f859428d81f"
6
7accepts@~1.3.3:
8  version "1.3.3"
9  resolved "https://registry.yarnpkg.com/accepts/-/accepts-1.3.3.tgz#c3ca7434938648c3e0d9c1e328dd68b622c284ca"
10  dependencies:
11    mime-types "~2.1.11"
12    negotiator "0.6.1"
Copy

While npm’s package-lock.json is a JSON file which looks as below:

bash
1{
2  "name": "react-example",
3  "version": "1.0.0",
4  "lockfileVersion": 1,
5  "dependencies": {
6    "has-flag": {
7      "version": "1.0.0",
8      "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-1.0.0.tgz",
9      "integrity": "sha1-nZ55MWXOAXoA8AQYxD+UKnsdEfo="
10    },
11    "supports-color": {
12      "version": "3.2.3",
13      "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-3.2.3.tgz",
14      "integrity": "sha1-ZawFBLOVQXHYpklGsq48u4pfVPY="
15    }
16  }
17}
Copy

The --cached-min and --cached-max command-line arguments have been replaced with --prefer-offline and --prefer-online respectively.

bash
1#npm 4
2npm install package-name --cache-min=999999
3npm install package-name --cache-max=0
4
5#npm 5
6npm install package-name --prefer-offline
7npm install package-name --prefer-online
Copy

Whenever you are offline, npm will fallback to your cache if possible – as opposed to insisting on retrying network requests or failing.

Package locks no longer exclude optionalDependencies that fail to build. This means package-lock.json and npm-shrinkwrap.json should now be cross-platform. There were cases in the past where when using npm-shrinkwrap, optionalDependencies were an issue. For example, It would try to install devDependencies during a production build and other similar issues that caused headaches for developers.

A package lock file describes a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

Feature Summary

npm no longer blasts your screen with the whole installed tree. Instead, you’ll see a nice little summary report of the install that is much kinder on your shell real estate, especially for large projects:

bash
1$ npm install
2npm added 125, removed 32, updated 148 and moved 5 packages in 5.032s.
Copy

A new --prefer-offline option will make npm skip any conditional requests (304 checks) for stale cache data, and only hit the network if something is missing from the cache.

For example, npm install nodemon --``prefer-offline will look for the resources needed to install nodemon in the cache first and will only use the network if something is not present in the cache.

This means a whole lot faster process of adding packages to projects as we don’t need to hit the network (and wait) every time before installing a new package, as long as that package has been previously cached.

A new --prefer-online option that will force npm to revalidate cached data (with 304 checks), ignoring any staleness checks, and refreshing the cache with revalidated, fresh data. Below is an example of this:

bash
1npm install nodemon --prefer-online
Copy

A new --offline option will force npm to use the cache or exit. It will error with an ENOTCACHED code if anything it tries to install isn’t already in the cache. Below is the example of this:

bash
1npm install nodemon --offline
Copy

It’s also important to note that npm 5 might break existing code. Existing npm caches are no longer used and the cache commands have been rewritten. You will have to download any cached product. So you might have to run npm install to download the cache again.

Indentation is now detected and preserved for following files:

• package.json
• package-lock.json
• npm-shrinkwrap.json

If the package-lock.json is missing, it will default to the current indentation of package.json

I think it’s really interesting to note how disruption and competition lead to positive change. Yarn was released a while ago and the JS crowd said “death to npm”, but it’s really refreshing to see that npm has pushed this significant update to the package manager.

I ran a small benchmark test to compare npm 4 and npm 5 and I have to say, the difference in speed is notable. npm 4 took about 36s to complete the npm i command while npm 5 took about 25s. My package.json contained dependencies like express, nodemon, pusher and body-parser.

See GIFs below for more visual information.

Another interesting thing to note is that Node 8 (which was recently released) ships with npm 5 and the async/await function!

It's official. #npm5 is in node8, coming out *tomorrow*. And look at all those other amazing goodies omg.

It's a good release, bront https://t.co/6K8KZzZKJG

— Kat Marchán (@zkat__) May 29, 2017

The full release notes about npm 5 can be seen on Github and also on their Medium page. You can upgrade to npm 5 with:

bash
1npm install -g npm@next
Copy

So what do you think? Will you go back to using npm 5 package manager? Will you stick with Yarn? Let us know in the comments below.