Should you commit the node_modules folder to git? This is a very valid question. You need to consider both the advantages and disadvantages here.
I am going to talk about this topic in this article so that you can reach your conclusions.
Here we discuss
.gitignore however, what we discuss here is applicable in the case of all other version control system you use.
The default option is here not to commit the node_modules folder, you should instead add it to the
Why You Should Not Commit node_modules Folder to Git?
Let’s take a look at some of the arguments which are in favor of committing node_modules below.
Keeping the Git history clan is essential. When it is time for you to add a fresh package, you store the file changes in
package.json. However, in the case of updating a package, you only bother to store the file changes in
As far as
package-lock.json is considered, this is not an old feature of npm. It is a replacement for
shrinkwrap command which has become obsolete. The best thing about this is that it is faster given the fact that you don’t have to put several MB of dependencies in the repository. Speaking of repository size, checking out the code and switching branches get affected by this.
Coming to the branches, you may have to deal with merge conflicts. Maybe it is smart to involve dependencies code. This can be time-consuming. It would be better to avoid such a scenario.
Sometimes changing dependencies will affect so many files in the process. Tools tend to get slower in such scenarios. In some cases, tools might refuse to show the full diff. We can take GitHub as an example here.
In case the deployed platform is different from the development machine, you need to recompile the native node modules. You may have developed it on Mac, but planning to deploy it on Linux. Here you need to call npm rebuild.
When you do not commit node_modules, you must list all your modules in the package-lock.json and package.json. It’s a beautiful thing. If you don’t do this, npm operations might get affected which should be avoided.
Tip: Thanks to the introduction of the
package-lock.json file, you don’t have to use a specific version in the package.json file.
When you commit node_modules folder, you are just committing the developer dependencies. Moreover, the production build might find it hard to get rid of them.
Let’s have a look at the reasons that would prompt you to commit node_modules.
We will also tell you how to mitigate them.
The author can remove the npm package from the registry. The now-famous left-pad incident which happened in 2016 is an example. Such incidents rarely happen for popular packages. In case it happens, you may have lost access to the specific functionality.
There is this popular argument that npm might not be around for long. Yes, it could disappear someday. Given that, committing your code sounds like a smart idea.
Whenever you use a package, the GitHub fork should be created. Moreover, you need to keep it up to date as well. However, this can be automated as well.
However, I wouldn’t call it the most practical idea since packages come with their baggage of dependencies.
We recommend using a private repository server. You can host all your dependencies here.
You have the following options:
If you commit the dependencies, you will be able to edit the code quickly. You can easily add an element to the library as well.
However, it comes with disadvantages as well. When you go for this, you will not be able to upgrade the package when new releases come to the fore. If we are talking about temporary fixes, then it is recommended.
We recommend submitting a PR. Alternatively, you can fork it.