coenjacobs/mozart

Composes all dependencies as a package inside a WordPress plugin

1.1.3 2026-03-04 08:57 UTC

Requires

• php: ^8.1
• league/flysystem: ^3.0
• league/flysystem-local: ^3.0
• netresearch/jsonmapper: ^4.4
• nikic/php-parser: ^4.0 || ^5.0
• symfony/console: ^6.4
• symfony/finder: ^6.4

Requires (Dev)

• dealerdirect/phpcodesniffer-composer-installer: ^1.0
• mheap/phpunit-github-actions-printer: ^1.5
• niels-de-blaauw/php-doc-check: ^0.4.0
• phpcompatibility/php-compatibility: ^10.1
• phpmd/phpmd: ^2.15
• phpstan/extension-installer: ^1.4
• phpstan/phpstan: ^1.12
• phpstan/phpstan-deprecation-rules: ^1.2
• phpunit/phpunit: ^10.0
• squizlabs/php_codesniffer: ^4.0

Conflicts

• symfony/config: >=7.0
• symfony/dependency-injection: >=7.0
• symfony/filesystem: >=7.0
• symfony/string: >=7.0
• symfony/var-exporter: >=8.0

MIT

• Coen Jacobs

README

Composes all dependencies as a package inside a WordPress plugin. Load packages through Composer and have them wrapped inside your own namespace. Gone are the days when plugins could load conflicting versions of the same package, resulting in hard to reproduce bugs.

This package requires PHP 8.1 or higher in order to run the tool. You can use the resulting files as a bundle, requiring any PHP version you like, even PHP 5.2.

How it works

Mozart takes your Composer dependencies, copies them into your plugin, and rewrites their namespaces and class names so they can't conflict with other plugins loading the same packages.

For namespaced packages, Mozart prefixes the namespace and updates all references:

-namespace Pimple;
+namespace CoenJacobs\TestProject\Dependencies\Pimple;

-use Psr\Container\ContainerInterface;
+use CoenJacobs\TestProject\Dependencies\Psr\Container\ContainerInterface;

 class Container implements ContainerInterface

For packages using global-scope classes, Mozart adds a prefix to class names:

-class Container {
+class CJTP_Container {
     // ...
 }

-$container = new Container();
+$container = new CJTP_Container();

This happens across the full dependency tree — namespace declarations, use statements, type hints, string references in class_exists() calls, and more. The result is a self-contained copy of your dependencies that won't collide with any other plugin's versions.

Installation

Mozart brings its own dependencies to the table and that potentially introduces its own problems (yes, I realise how meta that is, for a package like this). That's why installing Mozart in isolation, either through the Docker container, the available PHAR file or installing Mozart as a global dependency with Composer is preferred.

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

See docs/installation.md for all installation methods (Docker, PHAR, Composer).

Configuration

Mozart potentially requires zero configuration. When your project has a PSR-4 autoload entry or a package name in composer.json, Mozart infers everything it needs: the dependency namespace, target directories, and classmap prefix. Just run mozart compose and it works.

If you want to customize the behavior, add an extra.mozart block to your composer.json. Even an empty block is valid — Mozart fills in every setting it can infer:

"extra": {
    "mozart": {}
}

You can verify the resolved configuration with mozart config.

For full control, you can set every option explicitly:

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

The core settings and their defaults:

• dep_namespace — root namespace for bundled packages. Default: inferred from your PSR-4 autoload namespace + \Dependencies, or from the package name.
• dep_directory — target directory for namespaced package files. Default: vendor-prefixed/.
• classmap_directory — target directory for classmap package files. Default: same as dep_directory.
• classmap_prefix — prefix applied to classmap class names. Default: derived from dep_namespace with \ replaced by _.
• constant_prefix — prefix for global-scope constants. Default: empty (disabled).
• functions_prefix — prefix for global-scope functions. Default: empty (disabled).
• generate_autoloader — generate a Composer-compatible autoloader for prefixed dependencies. Default: true.

See docs/configuration.md for the full configuration reference with defaults and inference logic.

Further reading

Document	Description
docs/installation.md	All installation methods: Docker, PHAR, Composer
docs/configuration.md	Full configuration reference with defaults and inference
docs/usage.md	Automating Mozart with Composer scripts, configuring your project's autoloader
docs/docker.md	Docker registries, tag strategy, multi-architecture support
docs/background.md	Why Mozart was created and how it compares to PHP-Scoper