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.
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-cliand do acomposer install --prefer-source. However, this is still far from ideal:vendor/wp-cli/*subfolders. Most IDEs hide these by default and/or skip them during indexing.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.composer install --prefer-sourceall the time, is a surprisingly quick way of hitting the Github rate limiter.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-pharpackage that allows bulk-operations like get/change command versions and similar.