关键要点
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中文网其他相关文章！
