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