关键要点
- 除非全局安装的包没有依赖项,否则将
composer global require
用于安装跨多个项目使用的包现在被许多人认为是不好的做法。这是因为当包共享相同的空间时,可能会发生依赖冲突。 - 另一种解决方案是使用
composer require
将每个命令行工具安装到其自己的本地项目中,手动管理$PATH
或二进制文件。但是,这可能会增加复杂性和乏味性。对全局命令的建议更改可能会看到一个“全局的”但隔离的项目安装到特定位置,其供应商和 bin 目录出现在它们通常的位置。 - 一个新的工具 cgr (Composer Global Require) 已经被开发出来作为全局实现的替代方案。它为每个包创建隔离的安装,避免全局依赖问题。但是,此工具仍处于概念验证阶段,可能会发生更改。建议对其进行测试,但此时不要过度依赖它。
我们之前讨论过 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 的一般帮助文件。
正确安装全局 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 的全局 require 被认为是有害的,因为它可能导致依赖冲突。当您全局安装包时,它们都共享相同的空间,这意味着它们共享相同的依赖项集。如果两个包需要不同版本的相同依赖项,则可能导致冲突和错误。建议为每个项目安装其自己的一组依赖项,以避免此类问题。
Composer 全局 require 的替代方案是什么?
不要使用 Composer 的全局 require,您可以为每个需要的工具创建一个新的 Composer 项目。这样,每个工具将拥有自己的一组依赖项,从而降低冲突的风险。您还可以使用 cgr 等工具,它为每个包创建隔离的安装,从而避免全局依赖问题。
cgr 如何帮助避免全局依赖问题?
CGR(Composer 全局 Require)是一个为每个包创建隔离安装的工具。这意味着每个包及其依赖项都安装在其自己的单独目录中,避免了不同包的依赖项之间发生冲突的风险。这使其成为使用 Composer 全局 require 的更安全替代方案。
如何安装和使用 cgr?
要安装 cgr,您可以使用命令 composer global require consolidation/cgr
。安装后,您可以像使用 Composer 的全局 require 一样使用 cgr。例如,要安装包,您可以使用命令 cgr require package-name
。
Composer 中本地安装和全局安装有什么区别?
在 Composer 中,本地安装意味着包及其依赖项安装在项目的目录中。这是安装包的推荐方法,因为它可以避免依赖冲突。另一方面,全局安装将包及其依赖项安装在全局目录中,如果不同的包需要不同版本的相同依赖项,则可能导致冲突。
如何在 Composer 中管理全局依赖项?
由于存在冲突的风险,在 Composer 中管理全局依赖项可能具有挑战性。但是,像 cgr 这样的工具可以通过为每个包创建隔离的安装来提供帮助。您还可以通过为每个需要的工具创建一个新的 Composer 项目来管理全局依赖项,确保每个工具都拥有自己的一组依赖项。
我可以在 Composer 中同时使用本地安装和全局安装吗?
是的,您可以在 Composer 中同时使用本地安装和全局安装。但是,建议尽可能使用本地安装以避免依赖冲突。如果您需要全局使用包,请考虑使用 cgr 等工具来创建隔离的安装。
不正确管理 Composer 中的依赖项有哪些风险?
不正确管理 Composer 中的依赖项可能导致冲突和错误。如果两个包需要不同版本的相同依赖项,则可能会导致难以调试的问题。它还可能导致应用程序出现意外行为,因为不同版本的依赖项可能具有不同的功能和行为。
如何解决 Composer 中的依赖冲突?
要解决 Composer 中的依赖冲突,您可以尝试将包更新到最新版本,因为这可能会解决冲突。如果这不起作用,您可能需要重新考虑您正在使用的包并找到没有冲突依赖项的替代方案。像 cgr 这样的工具也可以通过为每个包创建隔离的安装来提供帮助。
如何保持 Composer 依赖项的最新状态?
要保持 Composer 依赖项的最新状态,您可以使用 composer update
命令。这会根据 composer.json
文件中指定的版本约束将所有包更新到其最新版本。您还可以使用 composer outdated
命令查看哪些包有可用的较新版本。
以上是作曲家全球需要被认为有害吗?的详细内容。更多信息请关注PHP中文网其他相关文章!

长URL(通常用关键字和跟踪参数都混乱)可以阻止访问者。 URL缩短脚本提供了解决方案,创建了简洁的链接,非常适合社交媒体和其他平台。 这些脚本对于单个网站很有价值

Laravel使用其直观的闪存方法简化了处理临时会话数据。这非常适合在您的应用程序中显示简短的消息,警报或通知。 默认情况下,数据仅针对后续请求: $请求 -

这是有关用Laravel后端构建React应用程序的系列的第二个也是最后一部分。在该系列的第一部分中,我们使用Laravel为基本的产品上市应用程序创建了一个RESTFUL API。在本教程中,我们将成为开发人员

Laravel 提供简洁的 HTTP 响应模拟语法,简化了 HTTP 交互测试。这种方法显着减少了代码冗余,同时使您的测试模拟更直观。 基本实现提供了多种响应类型快捷方式: use Illuminate\Support\Facades\Http; Http::fake([ 'google.com' => 'Hello World', 'github.com' => ['foo' => 'bar'], 'forge.laravel.com' =>

PHP客户端URL(curl)扩展是开发人员的强大工具,可以与远程服务器和REST API无缝交互。通过利用Libcurl(备受尊敬的多协议文件传输库),PHP curl促进了有效的执行

您是否想为客户最紧迫的问题提供实时的即时解决方案? 实时聊天使您可以与客户进行实时对话,并立即解决他们的问题。它允许您为您的自定义提供更快的服务

2025年的PHP景观调查调查了当前的PHP发展趋势。 它探讨了框架用法,部署方法和挑战,旨在为开发人员和企业提供见解。 该调查预计现代PHP Versio的增长

在本文中,我们将在Laravel Web框架中探索通知系统。 Laravel中的通知系统使您可以通过不同渠道向用户发送通知。今天,我们将讨论您如何发送通知OV


热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

AI Hentai Generator
免费生成ai无尽的。

热门文章

热工具

mPDF
mPDF是一个PHP库,可以从UTF-8编码的HTML生成PDF文件。原作者Ian Back编写mPDF以从他的网站上“即时”输出PDF文件,并处理不同的语言。与原始脚本如HTML2FPDF相比,它的速度较慢,并且在使用Unicode字体时生成的文件较大,但支持CSS样式等,并进行了大量增强。支持几乎所有语言,包括RTL(阿拉伯语和希伯来语)和CJK(中日韩)。支持嵌套的块级元素(如P、DIV),

SublimeText3 Linux新版
SublimeText3 Linux最新版

记事本++7.3.1
好用且免费的代码编辑器

PhpStorm Mac 版本
最新(2018.2.1 )专业的PHP集成开发工具

Dreamweaver CS6
视觉化网页开发工具