我現在工作的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