Restructure packages to improve developer experience

[schlessera]

There's a lot of unnecessary friction to development on WP-CLI right now, which I think can be greatly improved through some restructuring of the packages.

Goals:

• A - Development on the following components should be isolated vs each other: commands, framework, bundle. This means that we want to both get rid of the circular dependencies we currently have, as well as the need for manually syncing of code, like for the test suite.
• B - Every single package should conform to a basic, unified development flow that is easy to use as well as to maintain.
• C - Requirements and dependencies should be isolated to the proper components where they belong, and should be kept to a minimum.

Here's the current checklist of tickets to make this happen (with more to come, probably):

• Split wp-cli/wp-cli into separate framework + bundle packages (A, C) Split wp-cli/wp-cli into separate framework + bundle packages #4748
• Get rid of Symfony dependencies in the framework (C) Get rid of Symfony dependencies in the framework #4749
• Convenience access to contributor "actions" (B) Convenience access to contributor "actions" #4167
• Provide a standardized (or even automated) way of working on WP-CLI as a whole (A, B) Provide a standardized (or even automated) way of working on WP-CLI as a whole #4750
• Reduce the need for re-running scaffold package-* commands (A) Reduce the need for re-running scaffold package-* commands #4751

[danielbachhuber]

Can you produce a list of the breaking changes and their impact (either in this issue or another)?

[schlessera]

There's only two foreseeable breaking changes I can think of so far:

1. Split wp-cli/wp-cli into separate framework + bundle packages #4748 will cause a breaking change if a third-party command is being pulled-in via Composer AND that third-party command relies on running bundled commands as well. This will seldom be the case and will be an easy fix. Installations using the Phar will not be impacted.
2. Get rid of Symfony dependencies in the framework #4749 will cause a breaking change if a third-party command relies on one of the removed Symfony packages AND hasn't declared that requirement in its own Composer configuration. This will seldom be the case and will be an easy fix. Installations using the Phar will not be impacted as the package manager still comes with these requirements included.

[schlessera]

All items not yet solved for v2.0.0 have open issues milestoned to v2.1.0.
Closing this one now.