Why You Should Never Check-in node_modules
Why You Should Never Check-in node_modules

As a node.js developer, there is sometimes a debate about committing node_modules into source control. Having worked with node_modules both in and out of git, I'm adamantly against the checking them in. Here's why:

  • Merge conflicts in node_modules suck. They're really hard to resolve.
  • Merge diffs become useless. It's really hard to do a code review when there's tons of node_modules junk to look through
  • The size of the repo is dramatically increased. This has many side effects. Switching between branches is slower. More importantly, it increases the amount of code you need to send between servers during your deploy process. This can really increase deploy times.
  • Deploys are harder! You'll have to npm rebuild on every machine to make sure native modules are compiled correctly. This of course means that git diff on the server will be bloated.
  • It's too easy to forget to save a module to package.json. That wouldn't be a problem for deploys because the module is in source control, but this breaks many npm commands like npm dedupe.
  • It allows people to make one-off changes in node_modules. This is a huge pain when it comes to upgrading those modules. The better answer is to fix the upstream module (it's open source right?). Failing that, you can fork the module and use npm's namespacing to maintain your fork (hopefully just until upstream is fixed).
Why You Should Never Check-in node_modules

Joey Baker

By

I write code most days. Prevously: photojournalist, EMT. Somewhat obsessed with jouralism.