-
Notifications
You must be signed in to change notification settings - Fork 978
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split internal commands into distinct packages #3728
Comments
Does it mean that we will be able to build smaller phar-s? |
No — the Phar will still contain these commands for the foreseeable future. |
It would be nice if, when the time comes to remove those commands from the Phar release, we can make the update processes automatically install any packages necessary for preserving backwards-compatibility. |
Would it make sense to raise separate issues for each package to be split? Thereby allowing different developers to work on different packages. |
They'll be included in the Phar release, actually, for the foreseeable future (treated as Composer dependencies).
After the packages are split out, each will have their own issue tracker. |
Loading WordPress is the slowest part of the test process. To assess which commands to split out based on their impact on the build time:
Here are the results:
Total instances: 1748 |
Is |
|
No, |
I ran #3893 locally.
Here are the test times for each The outliers (greater than 45s) are:
In addition to |
Profile of |
I think continuing to break these commands apart is the most reasonable short-term task, then we can look at optimizing the performance of some features later on. |
Profile of |
Yes, the profiling does not tell us much we don't know yet. |
Sure, but we're not actively maintaining the Yaml parser package. It's basically set it and forget it.
The developer experience ("Now I need to make this change here, this change there, update tests in both places", etc.). It's much easier to have everything for a specific feature in one place. |
The tests that cover the general "dealing with a db object" would be in that separate package. And the command packages would only include their respective, specific tests. I'll think some more about this. I don't see an immediate issue with having small, granular packages per se. But I need to think through how the tests are being done in more detail. In general, I always assume that you should be able to split packages at logical boundaries. If that should not be easily feasible, it might hint to a design flaw somewhere (which we might or might not want to change as a result). |
Is |
It will be the existing |
Thanks. |
Going with https://github.com/wp-cli/entity-command and https://github.com/wp-cli/extension-command |
🚢 🔨 |
WP-CLI has organically evolved into a monolithic codebase that can now be abstracted to a set of discrete packages. In order to better support a future with lots of disparate WP-CLI features, let's split internal commands into a series of distinct packages, beginning with:
wp (cache|transient) *
https://github.com/wp-cli/cache-commandwp checksum
https://github.com/wp-cli/checksum-commandwp config *
https://github.com/wp-cli/config-commandwp core *
https://github.com/wp-cli/core-commandwp cron *
https://github.com/wp-cli/cron-commandwp db *
https://github.com/wp-cli/db-commandwp (eval|eval-file)
https://github.com/wp-cli/eval-commandwp export
https://github.com/wp-cli/export-commandwp (option|post|comment|user|term|site) *
https://github.com/wp-cli/entity-commandwp import
https://github.com/wp-cli/import-commandwp language
https://github.com/wp-cli/language-commandwp media *
https://github.com/wp-cli/media-commandwp package *
https://github.com/wp-cli/package-commandwp (plugin|theme) *
https://github.com/wp-cli/extension-commandwp rewrite
https://github.com/wp-cli/rewrite-commandwp (role|cap) *
https://github.com/wp-cli/role-commandwp scaffold *
https://github.com/wp-cli/scaffold-commandwp search-replace
https://github.com/wp-cli/search-replace-commandwp server
https://github.com/wp-cli/server-commandwp shell
https://github.com/wp-cli/shell-commandwp super-admin *
https://github.com/wp-cli/super-admin-commandwp (widget|sidebar) *
https://github.com/wp-cli/widget-commandWhen we split the packages, we should:
Previously: #3652 (comment)
The text was updated successfully, but these errors were encountered: