我现在工作的Laravel的web应用，并保持vendor目录出来的git（版本控制）至今并安装新的每一次我曾经有过的作曲家install命令添加到自动化的脚本，一切都很好。PHP作曲家安装或不？在生产环境中
现在就在2天之前，我在我的项目中添加了laravelcollective（https://laravelcollective.com/），以帮助我在刀片模板中使用表单和html。现在不知何故，其中一个依赖需要我生成GIT私有令牌来安装它，这很痛苦，因为它会伤害我的自动化。我仍然可以通过调用url和废除html来读取令牌和类似东西来破解它，但我不喜欢它。然后我认为保持vendor目录不在SVN/GIT中是个好主意？产品的源代码是否包含其内部的所有依赖关系？我不是在说安装程序中填充JRE，而是涉及到使用本地语言的产品库。
我想听到更多关于它的行业标准或对这个最佳实践。
P.S： 这个问题是非常通用的，并不仅仅局限于laravel甚至PHP的针对此事。
那么，对于生产环境，你通常先在自己的CI软件运行构建过程。如果在编译过程中'composer install'失败 - 应用程序将不会部署到生产环境，因此您很安全。
是，大多数（99％+）的人保持“供应商”文件夹进行回购的，因为它是一个第三方的代码，这是不是你的。您甚至可能无权将其托管在回购协议中。
如果你想确保你的量产版将拥有所有的依赖，从而，你CI期间有他们的方式，总是会释放 - 你可以建立泊坞窗图像，并把它们运到生产。然后，预先包装所有东西。
现在不知何故，其中一个依赖需要我生成GIT私人令牌来安装它，这很痛苦，因为它会伤害我的自动化。
您刚刚进入Github针对匿名用户的软件包下载速率限制。没有理由你不能自动化这个。生成Github上令牌（你只需要做一次 - 他们得到非常用于身份验证的要求高的速率限制），然后让你的自动化使用该令牌就像这样：
composer config -g github-oauth.github.com <oauthtoken>
https://getcomposer.org/doc/articles/troubleshooting.md#api-rate-limit-and-oauth-tokens
“产品的源代码是否包含自身内部的所有依赖关系？” - 列出所有依赖关系，使用你的代码的人将知道需要什么，当人们通过运行'composer update'获得相同的代码时，向版本控制添加大量额外的代码是不必要的。 – Drown
作曲家有它的好处但是当你试图自动化构建过程并被一些需要你去创建访问令牌的库/插件命中时，解决方案是什么？ – Dharmavir
我从来没有遇到过，你在说什么图书馆？ – Drown