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

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

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

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

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

不过，另一方面，可以说，将通过测试的代码完全相同的生产放到生产中是令人放心的-因此包括devDependencies。

我知道这个话题很老。但是由于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存储库（或者只是一些带有ZIP存档的HTTP服务器），以提供一些以前提取的依赖项供下载。

模块详细信息存储在中packages.json，这就足够了。无需办理登机手续node_modules。

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

这一点的另一种理由，如@ChrisCM在评论中写道：

同样值得注意的是，任何涉及本机扩展的模块将无法在不同架构之间工作，需要重新构建。提供具体理由说明不将其包括在存储库中。

我建议不要检入node_modules，因为例如PhantomJS和node-sass之类的软件包会为当前系统安装适当的二进制文件。

这意味着，如果一个开发人员npm install在Linux上运行并检入node_modules –它对于在Windows上克隆该存储库的另一个开发人员将无效。

最好检查一下哪个npm安装下载的压缩文件并指向npm-shrinkwrap.json它们。您可以使用rinkepack自动执行此过程。

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