Shipping unprefixed dependencies causes conflicts.

[ju1ius]

Bug Report

The wp-cli phar release currently ships with unprefixed composer dependencies.

Since most wp-cli commands need to load the wordpress application, this can cause conflicts in case a plugin or the application/website itself require the same dependency with different version constraints.

For example:

• an application or plugin requires psr/log:^3.0, but wp-cli ships with psr/log:^2.0
• a command in an application or plugin requires symfony/console:^7.0, but wp-cli ships with symfony/console:^3.4
• and so on...

An external tool should not impose a specific version of a dependency on the application developper.

In order to get rid of these issues, wp-cli should do what phpunit does in its phar release: ship all dependencies under a common vendor prefix (using i.e. humbug/php-scoper).

[schlessera]

This is something we have been discussing internally. There are still some details to figure out. I'll write up an issue with the current status and link it here.

Related: wp-cli/wp-cli-bundle#134

[ju1ius]

This is something we have been discussing internally. There are still some details to figure out. I'll write up an issue with the current status and link it here.

That's good to hear.

Related: wp-cli/wp-cli-bundle#134

Note that while the proposed solution in this issue (shipping the phar in a composer package) would fix dependency conflicts during installation, it would not fix the conflicts during runtime.

In order to be able to install wp-cli either as a phar or a composer package without any conflicts, you would need a build step similar to that of the easy-coding-standard package: this github action pre-processes and builds the code, then push a tag containing only the built artifacts (see for example their 12.1.14 release). The resulting composer package has zero dependency, everything is bundled and prefixed in its own vendor directory.

[schlessera]

Note that while the proposed solution in this issue (shipping the phar in a composer package) would fix dependency conflicts during installation, it would not fix the conflicts during runtime.

Yes, indeed, and that's where the discussions are currently stuck, and why I want to create a detailed issue describing the current state to get feedback from contributors like you. Let me find time to write up a detailed issue and then I'll ping you here to continue the discussion.

[schlessera]

@ju1ius here's the issue with the discussion topics I mentioned: #5920
I'd love to get your insights on this.