coenjacobs/mozart

将所有依赖作为包集成在WordPress插件中

资助包维护!
coenjacobs

安装: 1,972,430

依赖者: 15

建议者: 4

安全性: 0

星标: 425

关注者: 12

分支: 53

开放问题: 42

0.7.1 2021-02-02 21:37 UTC

README

将所有依赖作为包集成在WordPress插件中。通过Composer加载包,并将它们封装在您自己的命名空间中。那些插件可以加载同一包的冲突版本并导致难以复现的bug的日子已经过去了。

此包需要PHP 8.0或更高版本才能运行工具。您可以将生成的文件用作捆绑包,要求任何PHP版本,甚至PHP 5.2。

警告:此包非常实验性,直到版本1.0.0发布之前可能会出现破坏性更改。请谨慎使用,在生产环境中使用时请始终佩戴头盔。

安装

Mozart带来自己的依赖项,这可能会引入自己的问题(是的,我意识到这对于这个包来说是如何的元)。这就是为什么建议单独安装Mozart,无论是通过Docker容器、可用的PHAR文件,还是通过Composer将Mozart作为全局依赖项安装。在所有情况下,配置仍需要放在项目的composer.json文件中。

Docker

从注册表中拉取Docker镜像

docker pull coenjacobs/mozart

然后您可以在容器中启动容器并运行容器中的mozart compose命令。单条命令

docker run --rm -it -v ${PWD}:/project/ coenjacobs/mozart /mozart/bin/mozart compose

上述命令自动将当前工作目录作为卷添加到项目指定的目录:/project/。在Docker容器中,Mozart安装在/mozart/目录中。使用上述命令将在当前工作目录上运行Mozart。

请注意,Mozart的Docker镜像仅从版本0.7.0的latest构建开始可用。latest标签始终是master分支的最新构建,而不是稳定版本。您可以在Docker Hub上的所有可用标签中查看。

PHAR(通过Phive)

Mozart可以通过Phive安装

phive install coenjacobs/mozart --force-accept-unsigned

或者,可以从发行版页面下载mozart.phar文件,然后在项目目录中运行

php mozart.phar compose

Composer

如果您选择通过Composer安装Mozart,建议将Mozart作为全局包安装,以免与项目的依赖项冲突。

全局包

使用global命令安装Mozart时,它将作为全局包安装

composer global require coenjacobs/mozart

然后您可以在~/.composer/vendor/bin/目录中找到名为mozart的bin文件,并从项目目录中运行它,引用bin文件的完整路径

~/.composer/vendor/bin/mozart compose

项目开发依赖项

您可以通过Composer在项目本身中安装,仅在开发环境中需要

composer require coenjacobs/mozart --dev

这将在您的vendor/bin目录中创建一个名为mozart的bin文件,在项目内部加载整个包之后。尝试运行vendor/bin/mozart以验证其是否正常工作。

配置Mozart后,mozart compose命令将执行所有魔法

vendor/bin/mozart compose

配置

莫扎特配置简单。您只需指定捆绑依赖项存储的位置以及它们应放置的命名空间。此配置需要在您的 composer.json 文件的 extra 属性中完成。

"extra": {
    "mozart": {
        "dep_namespace": "CoenJacobs\\TestProject\\Dependencies\\",
        "dep_directory": "/src/Dependencies/",
        "classmap_directory": "/classes/dependencies/",
        "classmap_prefix": "CJTP_",
        "packages": [
            "pimple/pimple"
        ],
        "excluded_packages": [
            "psr/container"
        ],
        "override_autoload": {
            "google/apiclient": {
                "classmap": [
                    "src/"
                ]
            }
        },
        "delete_vendor_directories": true
    }
},

以下配置值是必需的

  • dep_namespace 定义了每个包将被放入的根命名空间。示例:如果我们正在加载的包正在使用 Pimple 命名空间,那么使用上述配置示例,该包将被放入 CoenJacobs\\TestProject\\Dependencies\\Pimple 命名空间。
  • dep_directory 定义了包文件将存储的目录。请注意,该目录需要与您在自动加载器中使用的命名空间以及捆绑包中定义的命名空间相对应。当您的项目使用 PSR-4 自动加载规范 时,可以取得最佳效果。
  • classmap_directory 定义了将通过类映射自动加载的文件将存储的目录。请注意,此目录需要由您的项目自动加载器通过类映射自动加载。
  • classmap_prefix 定义了将应用于您捆绑的包的类映射中的所有类的前缀。例如,一个名为 Pimple 的类和定义的前缀 CJTP_ 将导致类名 CJTP_Pimple

重要:由于莫扎特会自动处理您指定的包的完整依赖树,因此您必须指定所有这些配置选项,因为您无法可靠地确定完整依赖树中正在使用哪些自动加载器。例如,依赖树深处的包可能会突然使用类映射自动加载器。请确保您在自己的自动加载器中也包括命名空间目录和类映射目录,以确保它们始终被加载。

以下配置是可选的

  • delete_vendor_directories 是一个布尔标志,用于指示是否在处理完包后删除包的 vendor 目录。默认值:true
  • packages 是一个可选数组,定义了莫扎特将处理的包。该数组需要与您的 composer.json 中提供的格式相同的包 slugs。莫扎特将自动重写这些包的依赖关系。您不需要将这些包的依赖关系添加到列表中。如果此字段不存在,将包括 composer require 下列出的所有包。
  • excluded_packages 是一个可选数组,定义了要从莫扎特执行的处理中排除的包。当 packages 数组中的一些包定义了您希望保持不变的命名空间的依赖包时,这很有用。该数组需要与 packages 数组中的 slugs 相同。
  • override_autoload 是一个字典,以包名称为键,包含要替换原始包 composer.jsonautoload 属性中的自动加载设置的设置。

在 Composer 根据您的 composer.json 文件加载了包之后,现在您可以运行 mozart compose,莫扎特将根据上述配置捆绑您的包。建议在莫扎特运行完成后导出自加载器,以防生成新的类或命名空间而尚未包含在自加载器中。

脚本

莫扎特旨在安装后即可忘记。使用 Composer 脚本,莫扎特脚本可以在 Composer 安装新包或更新已安装的包后立即运行。这确保了您要捆绑的包始终捆绑在最新安装的版本中,自动完成。这些脚本还提供了在莫扎特运行完成后脚本导出自加载器的可能性。

"scripts": {
    "post-install-cmd": [
        "\"vendor/bin/mozart\" compose",
        "composer dump-autoload"
    ],
    "post-update-cmd": [
        "\"vendor/bin/mozart\" compose",
        "composer dump-autoload"
    ]
}

当通过Docker容器使用Mozart时,您可以替换"\"vendor/bin/mozart\" compose",这些行,使用您用于运行特定项目Docker容器的实际命令。在Docker容器内运行Mozart非常快,不应该超过几秒钟。

背景和哲学

Mozart旨在弥合WordPress生态系统与PHP整体庞大的包生态系统之间的差距。由于WordPress非常注重面向终端用户的CMS(有很好的理由),在生态系统内没有地方会让终端用户负担使用如Composer这样的开发者工具。另外,由于WordPress需要在基本上任何托管基础设施上运行,使用Composer从管理面板安装包(相信我,我已经尝试过——这是可能的)是一项几乎不可能完成的任务,并且要使它适用于每个服务器。

但为什么需要为这个目的创建一个新工具呢?已经有其他工具可以做到这一点,对吧?是的,现在有了。例如,PHP-Scoper。PHP-Scoper是一个非常棒的工具,能够正确完成工作。但是,PHP-Scoper在我开始Mozart项目的时候并不存在。此外,PHP-Scoper有一些限制(例如,不支持classmap自动加载器)这在WordPress生态系统中很常见。最后,PHP-Scoper可能是一个相当的工具,可以添加到您的开发流程中,而Mozart旨在易于实施,特别针对WordPress项目。

Mozart重要的核心价值观

  • 必须能够由开发者轻松安装,最好是在特定版本。
  • 分发必须通过现有的包管理器或易于单独维护。
  • 不应该给开发过程增加一个复杂的层级,即学习全新的工具/语言。

Mozart始终并且将继续致力于以尽可能高效和有见地的方式解决WordPress生态系统中的冲突依赖问题。通过在某些方面有见地并且专注于WordPress项目,Mozart很快变得容易理解和实施。