Provide a standardized (or even automated) way of working on WP-CLI as a whole

[schlessera]

Development on the WP-CLI "organization" as a whole is currently not well supported, and even less documented/automated.

The best bet so far is to pull in wp-cli/wp-cli and do a composer install --prefer-source. However, this is still far from ideal:

• Your development is now done in the vendor/wp-cli/* subfolders. Most IDEs hide these by default and/or skip them during indexing.
• Running the tests inside of one of these pulled-in commands directly means you need to do a composer install within the command folder again ... pulling in the entire bundle with framework and all commands once again. This wastes a lot of space and slows down indexing unnecessarily.
• When working on multiple commands in this way, using composer install --prefer-source all the time, is a surprisingly quick way of hitting the Github rate limiter.
• Changes that need to be done for multiple commands need to be done manually for each command and then commit/PRed separately. This can of course be shell-scripted, but an automated mechanism would be hugely useful here.

I'd like to start discussing how best to approach the above problems so that there's an efficient and hassle-free way of working across the multiple repositories for all of the usual maintenance/development tasks.

Once wp-cli/wp-cli#4748 is done, we should probably start with a small CLI tool inside of the wp-cli/wp-cli-phar package that allows bulk-operations like get/change command versions and similar.

[swissspidy]

As I'm increasingly using AI to groom our backlog and implement new features, I am hitting limits caused by our separation of packages. Having dozens of different repos makes it very difficult for an AI agent to find the right place to make changes, or to make changes at scale that touch every project.

The repo here is a good helper for local development, but I usually end up not doing the whole symlinking thing because I switch branches all the time, testing new dependencies, etc. And foreach-bundle is nice for automations but still not perfect because there's always one repo not in sync.

Reviving this issue to think out loud about some ideas here.

At the moment I am tinkering with the idea of turning wp-cli-dev into one big monorepo with individual packages in subfolders, and then the individual repositories becoming sole read-only mirrors (so Composer still works). Kinda like https://github.com/Automattic/jetpack and for example https://github.com/automattic/jetpack-crm as a mirror.

[swissspidy]

In the meantime this might help with cross-repo context: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/extend-coding-agent-with-mcp#customizing-the-built-in-github-mcp-server