Join the AI Workshop and learn to build real-world apps with AI. A hands-on, practical program to level up your skills.
Should you commit the node_modules folder to Git?
The same applies to other version control systems.
There are pros and cons. The usual recommendation is to not commit node_modules and to add it to .gitignore. Some setups may justify committing it; below are the tradeoffs.
Here are some arguments in favor of not committing node_modules
You keep your Git history clean. When you add a new package, you store the package.json and package-lock.json file changes.
When you decide to update the package version, all you store is the package-lock.json file change.
package-lock.jsonis a relatively new feature of npm, that obsoletes the shrinkwrap command used in the past
You avoid having to put possibly hundreds of MB of dependencies in your repository, and this means that over time it will be faster to work with. Switching branches and checking out the code are 2 operations hugely affected by the repository size.
When working with branches, merge conflicts can involve dependency code, which is tedious to resolve. Pull requests that include node_modules touch many more files. Tools become slower or even decide to not show the full diff (GitHub, for example)
Native modules must be rebuilt when the deployment platform differs from your dev machine (e.g. Mac vs Linux). You would need to run npm rebuild on the server.
Not committing node_modules forces you to declare all dependencies in package.json (and keep package-lock.json), which keeps the project reproducible and avoids broken npm operations.
Tip: there is no need to specify the exact version in your
package.jsonfile, any longer since the introduction of thepackage-lock.jsonfile.
If you use separate dependencies and devDependencies sets, by committing the node_modules folder you’re basically committing the devDependencies and there’s no (easy) way for the production build to get rid of them.
Reasons that might lead you to commit node_modules, and how to mitigate them
An npm package might be removed by its author from the npm registry. It happened with the famous left-pad incident in 2016 (read more). This is very rare to happen for popular packages. If this happens, you might no longer have access to that particular piece of functionality.
You might also argue that npm is not guaranteed to stay around indefinitely, it might disappear, so an easy way to guarantee to have the full code of your application in the future is to commit it along with your app.
Every time you use a package, create a fork on GitHub. Every once in a while, keep it up to date with the origin (can be automated).
This is not always practical as packages can have dozens of their own dependencies.
You can use a private repository server for your project, and use that to host all your dependencies.
Options include
- sinopia
- npm_lazy
- npm-lazy-mirror
- artifactory
- npm Enterprise, from the npm company
Another reason to commit the dependencies is the ability to quickly edit the code, if you find a bug or if you want to add something to a library.
This is a double-edged sword: if you do so, you lose the ability to upgrade the package if new releases are made, and it’s just good for quick, temporary fixes.
The optimal solution is to either submit a PR that does what you want to the original project or fork it and use your fork as a dependency.