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

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

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

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

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

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

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

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

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

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

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

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

最好检查npm安装下载的tarball，并指向npm-shrinkwrap。Json。你可以使用收缩袋自动化这个过程。

我看这个话题已经很老了。但由于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服务器)，提供一些先前获取的依赖集供下载。