The rest of the npm install process is exactly the same. The only difference is that no network activity is necessary when installing and building your project. The node_shrinkwrap directory can be ignored in your editor (much like is done with the node_modules directory) but is instead checked into source control.

npm install --global shrinkpack

For context, please see theandsections of this README.

Whenever we add, remove, or update an npm dependency — we should test our application for regressions before locking down our dependencies to avoid them mutating over time.

On most projects I’ve worked on we’ve had a Jenkins (or similiar) continuous integration environment, where we would run tests, analyse code, gather metrics, and create deployment packages.

Each time code was pushed to our develop and master branches, a repeatable process was carried out where a clean workspace is created, the latest version of the project is installed and configured, before testing and code analysis take place.

We were all very happy with this process and the convenience of npm in particular, but the phase of our builds where npm install listed a huge amount of network traffic would always raise the same concerns;

The first suggestion was always to check in our dependencies, but the idea of some large and chatty commits whenever we chose to upgrade or change them would put us off.

Some teams went a little further and decided that pain was acceptable and decided to proceed, only to find that some packages such asphantomjs helpfully install the appropriate binary for you depending on what system you’re running.

This meant that if Chris added phantomjs to the project on his Mac and checked it into the repository, Helen wouldn’t be able to use it on her Windows Machine. The remaining alternatives were proxies, mirrors, and caches-of-sorts.

None of these approaches appealed to us and, grudgingly, we continued as we were (YMMV).

npm shrinkwrap is something I would recommend you use anyway, even if you don’t decide to use shrinkpack . It brings certainty and confidence over exactly what versions of every nested dependency you’ve tested against and approved.

A tagged release should be a locked-down, fixed point in time which has been tested sufficiently enough that it is approved and trusted. When fed into a repeatable, automated deployment process it should always result in the same output.

Without npm shrinkwrap that’s not guaranteed.

Consider this snippet from the package.json of a nested dependency in your project as an example;

"dependencies": { "lolwut": ">=0.1.0" }

If lolwut@0.2.4 contains a regression and you’re not using npm shrinkwrap then congratulations , your project now contains a regression.

With you hopefully convinced of the merits of npm shrinkwrap , shrinkpack will hopefully be seen as a small and complimentary addition.

shrinkpack hopes to take npm shrinkwrap a little further by taking the .tgz tarballs of that specific, shrinkwrapped dependency graph saved by npm shrinkwrap and stores them within your project.