Avoiding Dependency Conflicts When Using Composer in WordPress Themes or Plugins

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 WenpriseProjectName;

use WenpriseProjectNameVendorLeagueContainerContainer as Container;

我们可以发现，命名空间如我们的预期，被添加了「WenpriseProjectName」前缀，这样处理后， league/container 包就运行在我们自己的命名空间之内了，等于变成了这个插件专属的代码。其他主题或插件使用的是哪个 league/container 就和我们的插件没关系了。

一些限制和类似工具

截止本文发布之前，Imposter插件的最新版本是 0.6.0，离 1.0 版本的发布还有一段距离。经过我们的测试，使用此插件处理不包含其他依赖的 composer 包基本都可以正确处理，但是如果需要处理的 composer 包又依赖了其他的包，使用 Imposter 处理就有很大的机会遇到错误。建议使用此插件进行插件或主题开发的时候，进行充分的测试。

Mozart 和 PHP-Scoper 是另外两个类似的工具，我还没有时间进行测试，但是都未发布稳定的 1.0 版本，有需要的朋友可以同时测试一下，看那个工具最能满足你的需要。