在研究Node的node_modules是否应该检入到你的版本控制库时，最近的共识似乎是你应该在你部署的应用程序中包含它。
来源:
- 检查node_modules和shrinkwrap 当我在Heroku上创建node.js应用程序时，我应该检查node_modules到git吗?
- https://www.npmjs.org/doc/misc/npm-faq.html Should-I-check-my-node_modules-folder-into-git
在阅读这些论点时，它使我质疑Composer的/vendors目录是否也应该检入到版本控制中。Composer的文档建议您不要这样做:
我应该在我的供应商目录中提交依赖关系吗?
一般建议是no。供应商目录[…].gitignore/svn:ignore/etc.
最佳实践是让所有开发人员使用Composer来安装依赖项。类似地，构建服务器、CI、部署工具等也应该适应运行Composer，将其作为项目引导的一部分。虽然在某些环境中提交它很诱人，但它会导致一些问题:
- 大型VCS存储库大小和更新代码时的差异。
- 在你自己的VCS中复制所有依赖的历史。[…]
对比那个论点的是这个(来源):
在node_modules中检查是否会在与我的应用程序无关的源树中产生很多噪音?
不，你错了，这个代码是你的应用程序使用的，它是你的应用程序的一部分，假装它不是会让你陷入麻烦。你依赖于其他人的代码，他们和你一样有可能写出新的bug，甚至更多。将所有这些代码检入到源代码管理中，使您能够审计应用程序中更改过的每一行代码。它允许您在本地使用$ git bisect，并确保它与生产中的相同，并且生产中的每台机器都是相同的。不再需要跟踪依赖中未知的更改，所有的更改，每一行，都可以在源代码管理中查看。
总之，问题是这样的:为什么一个gitignore(即不是版本控制)node_modules，但不做同样的作曲家的vendor/目录?
提交外部依赖的原因是
- 使用git pull更容易部署
- 使用的代码直接包含在提交中，任何人签出
反对这个的参数是
- Git不是部署工具
- 所有依赖管理器都有一种方法来确保所使用的代码可以被获取
我对npm一无所知，但对于Composer来说，最后一点是通过提交composer.lock来实现的。
我不认为"审计代码"在任何情况下都是有效的。如果您编写的软件需要自己进行审计，并且随后需要对所有库进行审计，那么可能需要保留所有代码更改。对于一般情况，这不是正确的。
git bisect与已提交的composer.lock仍然可以正常工作。它确实需要在每个步骤中安装依赖项，但这只是一个简单的步骤，可能已经在自动测试套件运行中完成了。
最后要担心的是使用的包何时脱机。这对Composer来说是一个更大的问题，因为它没有可下载版本的中央托管(npm可能会这样做)。如果这是一个问题，要么提交代码(并尝试找出如何在将来更新丢失的包)，要么设置Satis实例来创建您使用的代码的本地副本。
把你所有的模块放在你的VCS中会让下载或上传变得非常繁重。例如，我在两个node.js项目中工作，node_modules目录的总大小在250MB到500MB之间，而整个带有资产的代码通常小于40MB。每个Node.js开发者都喜欢Node的轻量级，所以代码必须保持易于下载和共享。
对于第二点，避免回归的替代方法是在包中进行更严格的限制。Json依赖版本。你可以在这里找到更多信息。
最后，最好的论证是看看大家都知道的著名模块:
- 表示无视node_modules
- 摩卡忽略node_modules
- q忽略node_modules
- …
我越研究这个问题，我就越觉得这个问题没有一个正确的答案，只有不同的观点以及每种方法的优缺点。
这个博客，从鲍尔的背景来看，做了一个很好的权衡利弊的工作:http://addyosmani.com/blog/checking-in-front-end-dependencies/。
总之:至少现在，权衡利弊，决定最适合你的情况。