Repository navigation
Provide a standardized (or even automated) way of working on WP-CLI as a whole #67
Closed as not planned
Description
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 installwithin 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-sourceall 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.
Activity
swissspidy commentedon Feb 18, 2026
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-bundleis 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-devinto 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 commentedon Feb 19, 2026
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
swissspidy commentedon Apr 29, 2026
Working with Antigravity on wp-cli-dev as a whole is not too bad at the moment for my taste. I stopped doing all the dependency symlinking though.
1 remaining item