node.js git 存储库中是否应包含“node_modules”文件夹

Should "node_modules" folder be included in the git repository

提问by Tolga E

I'm wondering if we should be tracking node_modules in our repo or doing an npm install when checking out the code?

我想知道我们是否应该在我们的 repo 中跟踪 node_modules 或在检查代码时进行 npm install？

采纳答案by ivoszz

The answer is not as easy as Alberto Zaccagni suggests. If you develop applications (especially enterprise applications), including node_modules in your git repo is a viable choice and which alternative you choose depends on your project.

答案并不像阿尔贝托·扎卡尼 (Alberto Zaccagni) 所说的那么简单。如果您开发应用程序（尤其是企业应用程序），在您的 git repo 中包含 node_modules 是一个可行的选择，您选择哪种替代方案取决于您的项目。

Because he argued very well against node_modules I will concentrate on arguments for them.

因为他很好地反对 node_modules，所以我将专注于他们的论点。

Imagine that you have just finished enterprise app and you will have to support it for 3-5 years. You definitely don't want to depend on someone's npm module which can tomorrow disappear and you can't update your app anymore.

想象一下，您刚刚完成了企业应用程序，您将需要支持它 3-5 年。你绝对不想依赖某人的 npm 模块，因为它明天就会消失并且你不能再更新你的应用程序。

Or you have your private modules which are not accessible from the internet and you can't build your app on the Internet. Or maybe you don't want to depend on your final build on npm service for some reasons.

或者您拥有无法从 Internet 访问的私有模块，并且您无法在 Internet 上构建您的应用程序。或者，由于某些原因，您可能不想依赖于 npm 服务的最终构建。

You can find pros and cons in this Addy Osmani article(although it is about Bower, it is almost the same situation). And I will end with a quote from Bower homepage and Addy's article:

您可以在这篇 Addy Osmani 文章中找到优缺点（虽然是关于 Bower，但情况几乎相同）。最后我会引用 Bower 主页和 Addy 文章中的一段话：

“If you aren't authoring a package that is intended to be consumed by others (e.g., you're building a web app), you should always check installed packages into source control.”

“如果您编写的包不是供其他人使用的（例如，您正在构建 Web 应用程序），则应始终将已安装的包检查到源代码管理中。”

回答by Alberto Zaccagni

Modules details are stored in packages.json, that is enough. There's no need to checkin node_modules.

模块详细信息存储在 中packages.json，这就足够了。没有必要签到node_modules。

People used to store node_modulesin version control to lock dependencies of modules, but with npm shrinkwrapthat's not needed anymore.

人们过去常常node_modules在版本控制中存储来锁定模块的依赖关系，但是现在不再需要npm shrinkwrap了。

Another justification for this point, as @ChrisCM wrote in the comment:

这一点的另一个理由，正如@ChrisCM 在评论中所写：

Also worth noting, any modules that involve native extensions will not work architecture to architecture, and need to be rebuilt. Providing concrete justification for NOT including them in the repo.

另外值得注意的是，任何涉及本机扩展的模块都不会在架构间工作，需要重新构建。提供不将它们包含在回购中的具体理由。

回答by Jamie Mason

I would recommend against checking in node_modulesbecause of packages like PhantomJS and node-sass for example, which install the appropriate binary for the current system.

我建议不要检查 node_modules，因为像 PhantomJS 和 node-sass 这样的包，它们会为当前系统安装适当的二进制文件。

This means that if one Dev runs npm installon Linux and checks in node_modules – it won't work for another Dev who clones the repo on Windows.

这意味着，如果一个 Devnpm install在 Linux 上运行并检查 node_modules - 它不适用于在 Windows 上克隆 repo 的另一个 Dev。

It's better to check in the tarballs which npm install downloads and point npm-shrinkwrap.jsonat them. You can automate this process using shrinkpack.

最好检查 npm install 下载的 tarball 并指向npm-shrinkwrap.json它们。您可以使用shrinkpack自动执行此过程。

回答by Thomas Urban

This topic is pretty old, I see. But I'm missing some update to arguments provided here due to changed situation in npm's eco system.

这个话题很老了，我明白了。但是由于 npm 生态系统中的情况发生了变化，我错过了对此处提供的参数的一些更新。

I'd always advise not to put node_modules under version control. Nearly all benefits from doing so as listed in context of accepted answer are pretty outdated as of now.

我总是建议不要将 node_modules 置于版本控制之下。到目前为止，在接受的答案中列出的几乎所有这样做的好处都已经过时了。

1. Published packages can't be revoked from npm registry that easily anymore. So you don't have to fear loosing dependencies your project has relied on before.

2. Putting package-json.lock file in VCS is helping with frequently updated dependencies probably resulting in different setups though relying on same package.json file.

1. 已发布的包不能再轻易地从 npm 注册表中撤销了。因此，您不必担心失去项目之前依赖的依赖项。

2. 将 package-json.lock 文件放在 VCS 中有助于解决频繁更新的依赖项，尽管依赖于相同的 package.json 文件，但可能会导致不同的设置。

So, putting node_modules into VCS in case of having offline build tools might be considered the only eligible use case left. However, node_modules usually grows pretty fast. Any update will change a lot of files. And this is affecting repositories in different ways. If you really consider long-term affects that might be an impediment as well.

因此，在具有离线构建工具的情况下将 node_modules 放入 VCS 可能被认为是剩下的唯一合格用例。然而，node_modules 通常增长得非常快。任何更新都会改变很多文件。这正在以不同的方式影响存储库。如果你真的考虑长期影响，那也可能是一个障碍。

Centralized VCS' like svn require transferring committed and checked out files over the network which is going to be slow as hell when it comes to checking out or updating a node_modules folder.

像 svn 这样的集中式 VCS 需要通过网络传输提交和检出的文件，这在检出或更新 node_modules 文件夹时会非常慢。

When it comes to git this high number of additional files will instantly pollute the repository. Keep in mind that git isn't tracking differences between versions of any file, but is storing copies of either version of a file as soon as a single character has changed. Every update to any dependency will result in another large changeset. Your git repository will quickly grow huge because of this affecting backups and remote synchronization. If you decide to remove node_modules from git repository later it is still part of it for historical reasons. If you have distributed your git repository to some remote server (e.g. for backup) cleaning it up is another painful and error-prone task you'd be running into.

当涉及到 git 时，大量的附加文件会立即污染存储库。请记住，git 不会跟踪任何文件版本之间的差异，而是在单个字符发生更改后立即存储文件的任一版本的副本。对任何依赖项的每次更新都将导致另一个大型变更集。由于这会影响备份和远程同步，您的 git 存储库将迅速增长。如果您决定稍后从 git 存储库中删除 node_modules，由于历史原因，它仍然是其中的一部分。如果您已将 git 存储库分发到某个远程服务器（例如用于备份），则清理它是您将遇到的另一项痛苦且容易出错的任务。

Thus, if you care for efficient processes and like to keep things "small" I'd rather use a separate artifacts repository such as Nexos Repository (or just some HTTP server with ZIP archives) providing some previously fetched set of dependencies for download.

因此，如果您关心高效的流程并希望保持“小”，我宁愿使用单独的工件存储库，例如 Nexos Repository（或只是一些带有 ZIP 存档的 HTTP 服务器），提供一些先前获取的依赖项集以供下载。

回答by M.Z.

Not tracking node_moduleswith source control is the right choice because some NodeJS modules, like MongoDB NodeJS driver, use NodeJS C++ add-ons. These add-ons are compiled when running npm installcommand. So when you track node_modulesdirectory, you may accidentally commit an OS specific binary file.

不node_modules使用源代码控制进行跟踪是正确的选择，因为某些 NodeJS 模块（如 MongoDB NodeJS 驱动程序）使用 NodeJS C++ 附加组件。这些附加组件在运行npm install命令时被编译。因此，当您跟踪node_modules目录时，您可能会不小心提交特定于操作系统的二进制文件。

回答by ndsvw

I agree with ivoszzthat it's sometimes usefulto check the node_modules folder, but...

我同意ivoszz 的观点，即检查 node_modules 文件夹有时很有用，但是......

---

---

scenario 1:

场景一：

One scenario: You use a package that gets removed from npm. If you have all the modules in the folder node_modules, then it won't be a problem for you. If you do only have the package name in the package.json, you can't get it anymore. If a package is less than 24 hours old, you can easily remove it from npm. If it's older than 24 hours old, then you need to contact them. But:

一种情况：您使用从 npm 中删除的包。如果您在文件夹 node_modules 中拥有所有模块，那么这对您来说就不成问题。如果您在 package.json 中只有包名称，则无法再获取它。如果一个包不到 24 小时，你可以很容易地从 npm 中删除它。如果超过 24 小时，则您需要与他们联系。但：

If you contact support, they will check to see if removing that version of your package would break any other installs. If so, we will not remove it.

如果您联系支持人员，他们将检查删除该版本的软件包是否会破坏任何其他安装。如果是这样，我们不会删除它。

read more

阅读更多

So the chances for this are low, but there is scenario 2...

所以这种情况的可能性很小，但有情况 2 ......

---

---

scenario 2:

场景2：

An other scenario where this is the case: You develop an enterprise version of your software or a very important software and write in your package.json:

另一种情况是这样的：您开发软件的企业版或非常重要的软件，并在 package.json 中写入：

"dependencies": {
    "studpid-package": "~1.0.1"
}

You use the method function1(x)of that package.

你使用function1(x)那个包的方法。

Now the developers of studpid-package rename the method function1(x)to function2(x)and they make a fault... They change the version of their package from 1.0.1to 1.1.0. That's a problem because when you call npm installthe next time, you will accept version 1.1.0because you used the tilde ("studpid-package": "~1.0.1").

现在，studpid-package 的开发人员将方法重命名function1(x)为function2(x)，他们犯了一个错误……他们将包的版本从 更改1.0.1为1.1.0。这是一个问题，因为当您npm install下次调用时，您将接受版本，1.1.0因为您使用了波浪号 ( "studpid-package": "~1.0.1")。

Calling function1(x)can cause errors and problems now.

function1(x)现在调用可能会导致错误和问题。

---

---

But:

但：

Pushing the whole node_modules folder (often more than 100 MB) to your repository, will cost you memory space. A few kb (package.json only) compared with hundreds of MB (package.json & node_modules)... Think about it.

将整个 node_modules 文件夹（通常超过 100 MB）推送到您的存储库，将消耗您的内存空间。几 kb（仅 package.json）与数百 MB（package.json & node_modules）相比......想想吧。

You could do it / should think about itif:

如果出现以下情况，您可以/应该考虑一下：

• the software is very important.

• it costs you money when something fails.

• you don't trust the npm registry. npm is centralized and could theoretically be shut down.

• 软件非常重要。

• 当某些事情失败时，它会花费您金钱。

• 你不信任 npm 注册表。npm 是中心化的，理论上可以关闭。

You don't needto publish the node_modules folder in 99.9% of the cases if:

在 99.9% 的情况下，您不需要发布 node_modules 文件夹，如果：

• you develop a software just for yourself.

• you've programmed something and just want to publish the result on GitHub because someone else could maybe be interested in it.

• 您只为自己开发一个软件。

• 你已经编写了一些东西，只是想在 GitHub 上发布结果，因为其他人可能会对它感兴趣。

---

---

If you don't want the node_modules to be in your repository, just create a .gitignorefile and add the line node_modules.

如果您不希望 node_modules 位于您的存储库中，只需创建一个.gitignore文件并添加行node_modules.

回答by Martin Capodici

I would like to offer a middle of the road alternative.

我想提供一个中间选择。

1. Don't add node_modulesinto git.
2. Use a package-lock.jsonfile to nail down your dependency versions.
3. In your CI or release process, when you release a version make a copy of the node_modules folder and back it up (e.g. in cloud storage).

1. 不要添加node_modules到 git 中。
2. 使用package-lock.json文件来确定您的依赖版本。
3. 在您的 CI 或发布过程中，当您发布一个版本时，复制 node_modules 文件夹并备份它（例如在云存储中）。

In the rare event that you cannot access NPM (or other registries you use) or a specific package in NPM, you have a copy of node_modules and can carry on working until you restore access.

在极少数情况下您无法访问 NPM（或您使用的其他注册表）或 NPM 中的特定包，您拥有 node_modules 的副本并且可以继续工作，直到您恢复访问权限。

回答by Jan ?ankowski

One more thing to consider: checking in node_modulesmakes it harder / impossible to use the difference between dependenciesand devDependencies.

还有一两件事要考虑：在检查node_modules就更难/不可能使用之间的区别dependencies和devDependencies。

On the other hand though, one could say it's reassuring to push to production the exact same code that went through tests - so including devDependencies.

但另一方面，人们可以说将经过测试的完全相同的代码推向生产是令人放心的——因此包括devDependencies.

回答by Himanshu

node_modules is not required to be checked-in if dependencies are mentioned in package.json. Any other programmer can simply get it by doing npm install and the npm is smart enough to make the node_modules in you working directory for the project.

如果 package.json 中提到了依赖项，则不需要签入 node_modules。任何其他程序员都可以通过执行 npm install 简单地获得它，并且 npm 足够智能，可以在项目的工作目录中创建 node_modules。