模块详细信息存储在包中。Json就足够了。不需要签入node_modules。

人们习惯将node_modules存储在版本控制中，以锁定模块的依赖关系，但有了npm shrinkwrap，就不再需要这种方法了。

另一个理由是，@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。你可以使用收缩袋自动化这个过程。

不使用源代码控制跟踪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置于版本控制之下。在公认的答案中列出的几乎所有这样做的好处到目前为止都已经过时了。

已经发布的包不能轻易地从npm注册表中撤销了。因此，您不必担心失去项目以前所依赖的依赖项。 把package-json。VCS中的lock文件有助于频繁更新依赖关系，虽然依赖于同一个包，但可能会导致不同的设置。json文件。

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

像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.

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

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

场景1:

一个场景: 你使用一个从npm中移除的包。 如果所有模块都在node_modules文件夹中，那么这对您来说就不是问题。 如果在包中只有包名。Json，你不能再得到它了。 如果一个包的使用时间小于24小时，可以很容易地从npm中删除它。 如果超过24小时，那么你需要联系他们。 但是:

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

阅读更多

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

场景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")。

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

But:

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

你可以这样做/应该考虑如果:

软件非常重要。 当某件事失败了，你就得花钱。 你不相信NPM注册表。NPM是中心化的，理论上可以被关闭。

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

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

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

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

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

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