Composer 为我们安装依赖包,使用丰富的PHP开源程序包提供了非常大的便利,如果您是一个有经验的 WordPress开发者,看到这篇文章的时候,你很可能已经在自己的项目中使用了 Composer。
在自己的网站上使用 Composer,依赖是可控的,遇到极赖冲突的机会比较小 ,如果你打算把自己开发的主题或插件共享出去供大家使用,使用 Composer 的时候就要小心了,因为你不知道使用你插件的网站使用了哪些插件,更无法知道这些插件是否使用 compser 安装了相同但不兼容的 PHP 包,哪个先加载,冲突的结果是什么?
尝试解决Composer依赖冲突
Imposter插件两个Composer 工具。他们目的就是帮助你使用自己的命名空间包装使用 Composer 安装的依赖包,从而避免依赖冲突。
使用这两个工具都需要在 comopser.json 中进行一些设置,然后花一些时间测试他们是否能正确处理您的 composer 依赖。
下面是我在一个插件中使用 imposter-plugin 处理 league/container 依赖的示例,注意下面代码中的 「extra」部分,这是我们需要添加的配置代码。
{
"name": "wenprise/project-name",
"description": "Demo project",
"require": {
"php": ">=7.1",
"league/container": "^3.3",
"psr/container": "^1.0",
"psr/container-implementation": "^1.0",
"typisttech/imposter-plugin": "^0.6.0"
},
"autoload": {
"psr-4": {
"Wenprise\\ProjectName\\": "src/"
}
},
"extra": {
"imposter": {
"namespace": "Wenprise\\ProjectName\\Vendor",
"excludes": [
"psr/container-implementation"
]
}
}
}
编辑好 composer.json 后,运行 composer update
, 然后打开 league/container 看一下 imposter 插件为我们做的工作。
<?php
namespace Wenprise\ProjectName;
use Wenprise\ProjectName\Vendor\League\Container\Container as Container;
我们可以发现,命名空间如我们的预期,被添加了「Wenprise\ProjectName」前缀,这样处理后, league/container 包就运行在我们自己的命名空间之内了,等于变成了这个插件专属的代码。其他主题或插件使用的是哪个 league/container 就和我们的插件没关系了。
一些限制和类似工具
截止本文发布之前,Imposter插件的最新版本是 0.6.0,离 1.0 版本的发布还有一段距离。经过我们的测试,使用此插件处理不包含其他依赖的 composer 包基本都可以正确处理,但是如果需要处理的 composer 包又依赖了其他的包,使用 Imposter 处理就有很大的机会遇到错误。建议使用此插件进行插件或主题开发的时候,进行充分的测试。
Mozart 和 PHP-Scoper 是另外两个类似的工具,我还没有时间进行测试,但是都未发布稳定的 1.0 版本,有需要的朋友可以同时测试一下,看那个工具最能满足你的需要。