Description
Description
I would like to see our plugins not conflict with code in a project and act more isolated. When requiring a create-wordpress-plugin
-based plugin, you're also including all the Composer dependencies that come with the plugin (especially if you require it with Composer!). This shouldn't be the case (and won't work if you're pushing to WordPress.org).
Plugins that are scaffolded from create-wordpress-plugin
should have the option of a build step that will scope the plugin's dependencies and prune any dependencies from composer.json
(we don't want to have them added back when you require the plugin). When a plugin is installed, the plugin will use the scoped plugin dependencies instead (My_Plugin_Vendor\Symfony\Console
vs Symfony\Console
).
h2. Acceptance Criteria
- Plugins can be scaffolded and include
php-scoper
that will automatically scope the plugin's vendor files for release. - A plugin's
src
files should not be modified, only changed to reference and use the newly scoped classes (we don't want to scope the plugin's file, only vendor). - A developer can opt to not scope their plugin during the configuration step.
- When a project is scoping its code, a test should be performed against pull requests that scope the project's code and then test against the plugin using the scoped-code.
Some prior art:
- https://github.com/humbug/php-scoper
- https://gatographql.com/blog/graphql-api-for-wp-is-now-scoped-thanks-to-php-scoper/#heading-php-scoper-the-easy-way
- https://github.com/Yoast/wordpress-seo/
Use Case
When a user scaffolds a plugin they can optionally scope their vendor files to prevent any potential conflicts.