“node_modules”文件夹是否应该包含在git存储库中

Question

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

Answer 1

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

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

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

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

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

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

Answer 2

模块详细信息存储在packages.json ，这就足够了。 无需签入node_modules 。

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

Answer 6

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

---

场景一：

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

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

阅读更多

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

---

场景2：

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

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

您使用该包的方法function1(x) 。

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

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

---

但是：

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

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

• 软件非常重要。

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

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

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

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

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

---

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

Answer 7

我想提供一个中间选择。

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

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

Answer 8

还要考虑的另一件事：检查node_modules会使使用dependencies和devDependencies之间的差异变得更加困难/不可能。

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

Answer 9

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