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