应该“node_modules"文件夹被包含在git存储库中

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

人们习惯在版本控制中存储node_modules来锁定模块的依赖关系，但是使用npm收缩包装就不再需要了。

另一个理由是，@ChrisCM在评论中写道:

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

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

因为他很好地反对node_modules，所以我将集中讨论支持它们的论点。

想象一下，你刚刚完成了一个企业应用程序，你必须支持它3-5年。你肯定不想依赖别人的npm模块，它明天就会消失，你就不能再更新你的应用了。

或者你有你的私有模块，不能从互联网上访问，你不能在互联网上创建你的应用。或者，出于某些原因，你可能不想依赖于npm服务的最终构建。

你可以找到优点和缺点在这篇Addy Osmani的文章中(虽然它是关于Bower，它几乎是相同的情况)。我将引用Bower主页和Addy文章中的一段话作为结束:

“如果你正在创作的包不是要被其他人使用(例如，你正在构建一个web应用程序)，你应该始终将已安装的包检查到源代码控制中。”

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

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

最好检查npm安装下载的tarball，并将npm-shrinkwrap.json指向它们。你可以使用shrinkpack自动化这个过程。

不使用源代码控制跟踪node_modules是正确的选择，因为一些NodeJS模块，如MongoDB NodeJS驱动程序，使用NodeJS c++附加组件。这些附加组件是在运行npm install命令时编译的。所以当你跟踪node_modules目录时，你可能会不小心提交一个特定于OS的二进制文件。

还有一件事需要考虑:签入node_modules会使使用dependencies和devDependencies之间的差异变得更加困难/不可能。

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

如果package.json中提到了依赖关系，则Node_modules不需要检入。任何其他程序员都可以通过npm install来简单地获得它，npm足够聪明，可以让node_modules在你的项目工作目录中。

我看这个话题已经很老了。但由于npm生态系统的情况发生了变化，我错过了这里提供的一些参数的更新。

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

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

2. 把package-json。VCS中的lock文件有助于频繁更新依赖关系，虽然依赖于同一个包，但可能会导致不同的设置。json文件。

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

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

当涉及到git时，这么多额外的文件将立即污染存储库。请记住，git不会跟踪任何文件版本之间的差异，而是在单个字符发生更改时存储文件的两个版本的副本。对任何依赖项的每次更新都会导致另一个大的更改集。因为这会影响备份和远程同步，你的git存储库将很快变得巨大。如果你决定以后从git存储库中删除node_modules，由于历史原因，它仍然是它的一部分。如果你已经将git存储库分布到一些远程服务器上(例如备份)，清理它是另一项痛苦且容易出错的任务。

因此，如果您关心高效的流程，并且喜欢保持事情“小”，我宁愿使用单独的工件存储库，如Nexos repository(或只是一些带有ZIP存档的HTTP服务器)，提供一些先前获取的依赖集供下载。

我同意ivoszz，它是有时是有用的检查node_modules文件夹，但…

场景1:

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

read more

所以出现这种情况的几率很低，但有第二种情况……

场景2:

另一种情况: 你开发了你的软件的企业版或一个非常重要的软件，并在你的package.json中写道:

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

使用该包的__abc0方法。

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

但是:

将整个node_modules文件夹(通常超过100 MB)推到存储库中，将占用您的内存空间。 几个kb(包。json仅)相比，数百MB(包。json,node_modules)…

你可以做/应该考虑一下吗如果:

• 软件非常重要。

• 当某件事失败了，你就得花钱。

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

你不需要来发布node_modules文件夹在99.9%的情况下，如果:

• 你为自己开发了一个软件。

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

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

我想提供一个中间路线的选择。

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

在极少数情况下，你不能访问NPM(或你使用的其他注册表)或NPM中的特定包，你有一个node_modules的副本，可以继续工作，直到恢复访问。