關鍵要點
composer global require 用於安裝跨多個項目使用的包現在被許多人認為是不好的做法。這是因為當包共享相同的空間時，可能會發生依賴衝突。 composer require 將每個命令行工具安裝到其自己的本地項目中，手動管理 $PATH 或二進製文件。但是，這可能會增加複雜性和乏味性。對全局命令的建議更改可能會看到一個“全局的”但隔離的項目安裝到特定位置，其供應商和 bin 目錄出現在它們通常的位置。 我們之前討論過 Composer 的最佳實踐，我一直提倡在安裝可在多個項目中使用的包（特別是命令行工具）時使用 composer global require。然後，有一天，我遇到了這個討論。
簡而言之，現在大多數人似乎覺得全局 require 是不好的做法，除非全局安裝的包沒有依賴項。從技術上講，當一個人對所有項目使用單個環境時，這是有意義的，但正如我在該討論中評論的那樣，當每個項目使用虛擬機或像Docker 這樣的適當隔離的環境時，這個問題就無關緊要了，全局實際上不會造成損害。
OP 對此問題的建議解決方案是：
作為替代方案，用戶應該使用
composer require將每個命令行工具安裝到其自己的本地項目中，並手動管理其$PATH或二進製文件（例如，通過從$PATH中已有的bin 目錄創建符號鏈接）。
對我來說，這是一個完全不可接受的複雜化。 Composer 一直是 PHP 的驕傲，因為它易於使用，並且使包管理變得對新手友好——本地 或 全局。必須四處創建符號鏈接（尤其要考慮到像 Windows 這樣的非符號鏈接操作系統）會增加乏味感。然後，OP 進一步建議更改全局命令的工作方式：
可以將一個“全局的”但隔離的項目安裝到
~/.composer/global/[something]；其供應商和bin 目錄將出現在它們通常的位置，並且~/.composer/global/[something]/bin目錄的內容可以在~/.composer/vendor/bin中鏡像（通過符號鏈接），或者更好的選擇可能是~/.composer/bin。字符串[something]可以通過多種方式選擇；最直接的方法是org/project（儘管這意味著將存在像~/.composer/global/org/project/vendor/org/project這樣的長路徑）。
我完全同意這種方法，它似乎是兩全其美的。顯然，這可能會導致一些向後兼容性問題，但這並不意味著它不能在 Composer 的 2.0 版本中發生。 Taylor Otwell 在下面進一步回應了這種觀點：
完全同意。能夠將每個 composer 全局安裝的包安裝到其自己的隔離目錄中，並擁有其自己的隔離依賴項，而不是可能與其他全局安裝的包衝突，這將是令人驚奇的。
在此之後，本著真正的開源精神，OP 隨後將替代全局實現構建為一個單獨的工具：cgr。讓我們看看它是如何工作的。
CGR – Composer 全局 Require 替代方案
我將在 Homestead Improved 實例上執行以下所有命令
要開始使用 CGR，我們將其作為全局包安裝。
composer global require consolidation/cgr
如果 Composer 的 bin 文件夾不在 PATH 變量中，請添加它：
echo "export PATH=$PATH:$HOME/.composer/vendor/bin/" >> ~/.bashrc echo "export CGR_BIN_DIR=$HOME/.composer/vendor/bin" >> ~/.bashrc source ~/.bashrc
以上命令使用 Composer 的全局 bin 目錄的路徑擴展 $PATH 環境變量（Homestead Improved 上的默認位置——你的位置可能不同）。第二個命令配置 cgr 使用的 bin 目錄，而第三個命令加載這些更改。這些也將在每次以該用戶身份運行終端界面時自動加載（在我的情況下，通過 vagrant ssh 使用 Vagrant）。
然後可以通過運行 cgr 來訪問 CGR，它應該輸出 Composer 的一般幫助文件。
cgr phpunit/phpunit
在 Homestead Improved 上，配置了一個有用的別名，在其中鍵入 phpunit 會擴展為 vendor/bin/phpunit，這在每個項目安裝 phpunit 時非常方便，因此可以從根文件夾運行它。為了測試 PhpUnit 的全局安裝，我們需要先刪除此別名（在 ~/.bash_aliases 中註釋相應的行），然後退出 shell 並重新進入，以便別名重新加載。然後，使用版本輸出運行這個新全局安裝的 PhpUnit 應該產生類似以下內容：
vagrant@homestead:~$ phpunit --version PHPUnit 5.4.2 by Sebastian Bergmann and contributors.
現在讓我們嘗試安裝兩個不兼容的包。
cgr laravel/installer cgr wp-cli/wp-cli
當然，它們都可以正常安裝。讓我們檢查它們是否有效。
composer global require consolidation/cgr
一切順利！以前由於依賴項不匹配而發生衝突的全局包現在可以並排共存，並且可以在整個操作系統中使用，而不會出現任何問題！
在某些情況下，您可能希望安裝 Composer 插件。如限制部分所述，由於 CGR 將每個全局包安裝到其自己的文件夾中並擁有其自己的依賴項樹，因此這些插件不會在所有全局項目中全局可用。因此，如果您想安裝更改 composer 通用行為的插件，您仍然應該使用 composer global require 而不是 cgr。例如，CGR 本身就是這樣一個插件。
測試，測試，測試！如果您是全局 require 命令的常用用戶，我強烈建議您測試這個新工具，並向 Greg Anderson 提供一些反饋，說明它在多大程度上滿足了您的全局需求，以及是否有任何改進之處。
請注意，此工具目前只是一個概念驗證，實現方式可能會或可能不會重命名、重新打包、最終集成到 Composer 的核心等等。換句話說，盡可能多地使用它，但暫時不要過度依賴它。
在您的全局包安裝的同時，為什麼不告訴我們您對 composer global require 的看法呢？它像許多人現在認為的那樣有害嗎？還是僅僅是謹慎行事和擁有隔離的開發環境的問題？其他什麼？請在下面發表您的意見！
Composer 的全局 require 被認為是有害的，因為它可能導致依賴衝突。當您全局安裝包時，它們都共享相同的空間，這意味著它們共享相同的依賴項集。如果兩個包需要不同版本的相同依賴項，則可能導致衝突和錯誤。建議為每個項目安裝其自己的一組依賴項，以避免此類問題。
不要使用 Composer 的全局 require，您可以為每個需要的工具創建一個新的 Composer 項目。這樣，每個工具將擁有自己的一組依賴項，從而降低衝突的風險。您還可以使用 cgr 等工具，它為每個包創建隔離的安裝，從而避免全局依賴問題。
CGR（Composer 全局 Require）是一個為每個包創建隔離安裝的工具。這意味著每個包及其依賴項都安裝在其自己的單獨目錄中，避免了不同包的依賴項之間發生衝突的風險。這使其成為使用 Composer 全局 require 的更安全替代方案。
要安裝 cgr，您可以使用命令 composer global require consolidation/cgr。安裝後，您可以像使用 Composer 的全局 require 一樣使用 cgr。例如，要安裝包，您可以使用命令 cgr require package-name。
在 Composer 中，本地安裝意味著包及其依賴項安裝在項目的目錄中。這是安裝包的推薦方法，因為它可以避免依賴衝突。另一方面，全局安裝將包及其依賴項安裝在全局目錄中，如果不同的包需要不同版本的相同依賴項，則可能導致衝突。
由於存在衝突的風險，在 Composer 中管理全局依賴項可能具有挑戰性。但是，像 cgr 這樣的工具可以通過為每個包創建隔離的安裝來提供幫助。您還可以通過為每個需要的工具創建一個新的 Composer 項目來管理全局依賴項，確保每個工具都擁有自己的一組依賴項。
是的，您可以在 Composer 中同時使用本地安裝和全局安裝。但是，建議盡可能使用本地安裝以避免依賴衝突。如果您需要全局使用包，請考慮使用 cgr 等工具來創建隔離的安裝。
不正確管理 Composer 中的依賴項可能導致衝突和錯誤。如果兩個包需要不同版本的相同依賴項，則可能會導致難以調試的問題。它還可能導致應用程序出現意外行為，因為不同版本的依賴項可能具有不同的功能和行為。
要解決 Composer 中的依賴衝突，您可以嘗試將包更新到最新版本，因為這可能會解決衝突。如果這不起作用，您可能需要重新考慮您正在使用的包並找到沒有衝突依賴項的替代方案。像 cgr 這樣的工具也可以通過為每個包創建隔離的安裝來提供幫助。
要保持 Composer 依賴項的最新狀態，您可以使用 composer update 命令。這會根據 composer.json 文件中指定的版本約束將所有包更新到其最新版本。您還可以使用 composer outdated 命令查看哪些包有可用的較新版本。
以上是作曲家全球需要被認為有害嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
