Right now, the wp-cli/wp-cli has two separate roles:
- It is the framework that provides all the base functionality that commands depend on. Conceptually, this is a library that commands should depend on. As an example, each command needs to pull this in to be able to work and be tested.
- It is the "bundle" that ends up being compiled into a Phar. Conceptually, this is the root package of the "wp-cli.phar" project. It includes all bundled commands as its dependencies.
Having these two roles be included in one single package causes some issues:
- We have circular dependencies, where the bundle requires a command, and that command in turn requires the bundle again.
- The Composer autoloader needs a hack, because we want to load external commands installed through the package manager between the framework autoloader and the bundle autoloader. The implementation of this hack can cause Composer side-effects outside of WP-CLI.
- It is not possible to pull in a single command via Composer, as that command depends on the bundle, which pulls in all bundled commands. Ideally, we'd want to be able to just pull in a single command like
wp-cli/db-command into a WordPress project and have it just work.
- The framework automatically requires all dependencies of the entire bundle, even if only one command is needed. This causes for example
composer/composer and symfony/* to be hard requirements, even though they're essentially only needed for wp-cli/package-command. Pulling WP-CLI through Composer into a project should be possible without including the package manager and all of its dependencies.
The wp-cli/wp-cli package needs to be split up into two separate packages to get rid of these problems.
wp-cli/wp-cli is already being required by all commands, so this would be the package name for the framework. This way, we should be able to split things up without any major BC breaks. Note: Commands that require wp-cli/wp-cli and then make use of bundled commands would break under some circumstances, but not when used through the Phar.
wp-cli/wp-cli-phar (name up for discussion) would be the package that represents the "bundle", and thus the executable Phar file to be built. Note: the release should still be uploaded to wp-cli/wp-cli releases on Github for BC.
Right now, the
wp-cli/wp-clihas two separate roles:Having these two roles be included in one single package causes some issues:
wp-cli/db-commandinto a WordPress project and have it just work.composer/composerandsymfony/*to be hard requirements, even though they're essentially only needed forwp-cli/package-command. Pulling WP-CLI through Composer into a project should be possible without including the package manager and all of its dependencies.The
wp-cli/wp-clipackage needs to be split up into two separate packages to get rid of these problems.wp-cli/wp-cliis already being required by all commands, so this would be the package name for the framework. This way, we should be able to split things up without any major BC breaks. Note: Commands that requirewp-cli/wp-cliand then make use of bundled commands would break under some circumstances, but not when used through the Phar.wp-cli/wp-cli-phar(name up for discussion) would be the package that represents the "bundle", and thus the executable Phar file to be built. Note: the release should still be uploaded towp-cli/wp-clireleases on Github for BC.