Question

Checking in node_module was the community standard but now we also have an option to use shrinkwrap. The latter makes more sense to me but there is always the chance that someone did “force publish” and introduced a bug. Are there any additional drawbacks?

Answer 1

My favorite post/philosophy on this subject goes all the way back (a long time in node.js land) to 2011:

https://web.archive.org/web/20150116024411/http://www.futurealoof.com/posts/nodemodules-in-git.html

To quote directly:

If you have an application, that you deploy, check in all your dependencies in to node_modules. If you use npm do deploy, only define bundleDependencies for those modules. If you have dependencies that need to be compiled you should still check in the code and just run $ npm rebuild on deploy.

Everyone I’ve told this too tells me I’m an idiot and then a few weeks later tells me I was right and checking node_modules in to git has been a blessing to deployment and development. It’s objectively better, but here are some of the questions/complaints I seem to get.

I think this is still the best advice.

The force-publish scenario is rare and npm shrinkwrap would probably work for most people. But if you’re deploying to a production environment, nothing gives you the peace-of-mind like checking in the entire node_modules directory.

Alternately, if you really, really don’t want to check in the node_modules directory but want a better guarantee there hasn’t been a forced push, I’d follow the advice in npm help shrinkwrap:

If you want to avoid any risk that a byzantine author replaces a package you’re using with code that breaks your application, you could modify the shrinkwrap file to use git URL references rather than version numbers so that npm always fetches all packages from git.

Of course, someone could run a weird git rebase or something and modify a git commit hash… but now we’re just getting crazy.