node.js - 在版本控制中不包含 Node 模块的情况是否也适用于 Composer 包？

Question

正在研究 Node 的 node_modules 是否应该 checkin 您的版本控制存储库，最近的共识似乎是您应该将其包含在您部署的应用程序中。

来源:

• Check in node_modules vs. shrinkwrap
• Should I check in node_modules to git when creating a node.js app on Heroku?
• https://www.npmjs.org/doc/misc/npm-faq.html#Should-I-check-my-node_modules-folder-into-git

在阅读这些论点时，它让我质疑 Composer 的 /vendors 是否是这样的？目录也应该被 checkin 版本控制。 Composer's documentation建议您不要:

Should I commit the dependencies in my vendor directory?

The general recommendation is no. The vendor directory [...] should be added to .gitignore/svn:ignore/etc.

The best practice is to then have all the developers use Composer to install the dependencies. Similarly, the build server, CI, deployment tools etc should be adapted to run Composer as part of their project bootstrapping.

While it can be tempting to commit it in some environment, it leads to a few problems:

• Large VCS repository size and diffs when you update code.
• Duplication of the history of all your dependencies in your own VCS. [...]

对比这个论点的是这个( source ):

Doesn’t checking in node_modules create a lot of noise in the source tree that isn’t related to my app?

No, you’re wrong, this code is used by your app, it’s part of your app, pretending it’s not will get you in to trouble. You depend on other people’s code and they are just as likely to write new bugs as you are, probably more so. Checking all of that code in to source control gives you a way to audit every line that ever changed in your application. It allows you to use $ git bisect locally and be ensured that it’s the same as in production and that every machine in production is identical. No more tracking down unknown changes in dependencies, all the changes, in every line, are viewable in source control.

总而言之，问题是这样的:为什么一个 gitignore(即不是版本控制)node_modules但不要对 Composer 的 vendor/ 做同样的事情目录？

Answer 1

提交外部依赖的原因是

• 使用 git pull 部署更容易
• 所使用的代码直接包含在任何人 checkout 的提交中

反对这一点的论点是

• Git 不是部署工具
• 所有依赖管理器都有办法确保可以获取所使用的代码

我对npm一无所知，但对于Composer来说，最后一点是通过提交composer.lock来实现的。

我不认为“审核代码”参数在所有情况下都是有效的。如果您编写的软件需要自行审核，并且随后需要审核所有库，那么可能需要保留所有代码更改。对于一般情况而言并非如此。

git bisect 仍然可以与提交的 composer.lock 一起使用。它确实需要在每个二等分步骤中安装依赖项，但这只是一个简单的步骤，可能已经在自动测试套件运行中完成。

最后要担心的是使用过的软件包何时离线。这确实是 Composer 的一个问题，因为没有可下载版本的集中托管(npm 可能会这样做)。如果这是一个问题，请提交代码(并尝试找出将来如何更新缺少的包)，或设置 Satis 实例来创建您使用的代码的本地副本。