Edit: It’s worth pointing out that freezing versions in libraries is not generally recommended (though this is a matter of community contention). Further publishing anything to the public registry with a shrinkwrap causes problems for people with private registry mirrors as the shrinkwrap encodes the public registry url. Obviously, if your organization has decided to freeze its libraries then publishing shrinkwraps to your own private registry like npme or as private modules is quite alright.

Some people also feel that shrinkwraps MUST be checked into git, so that you can recreate published archives from the git repository. Some do not. Obviously you need to fit things to your workflow and your release practices.

npm’s shrinkwrap feature provides a key benefit when it comes to supporting published code– it fixes all of the dependency versions for all of your dependencies AND THEIR dependencies. This means that you can be sure that your end users are using exactly the same software as you are.

But shrinkwrap can also be frustrating to use because as long as the npm-shrinkwrap.json file is laying around npm won’t behave the same as it usually does.

What this does, is only include the npm-shrinkwrap.json in the published artifact. This means that your development will get newer versions of your dependencies to test, while your users will get exactly what you tested with at the time you published.

How To

“` $ npm install -g npm-script … $ npm install —save-dev in-publish rimraf … $ npm-script set prepublish “in-publish && npm shrinkwrap || in-install” set: prepublish $ npm-script set postpublish “rimraf npm-shrinkwrap.json” set: postpublish $ npm publish

your-module@1.0.0 prepublish … in-publish && npm shrinkwrap || in-install

npm WARN shrinkwrap Excluding devDependency: in-publish npm WARN shrinkwrap Excluding devDependency: rimraf wrote npm-shrinkwrap.json + your-module@1.0.0

your-module@1.0.0 postpublish . rimraf npm-shrinkwrap.json

“`