Add opt-in php-scoper support for vendor dependency isolation

[Copilot]

Scaffolded plugins share vendor namespaces with the host project, causing conflicts and preventing WordPress.org distribution. This adds opt-in php-scoper integration to prefix all vendor namespaces under the plugin's own namespace.

Changes

• scoper.inc.php — New php-scoper config scoping vendor/ to vendor-prefixed/ with the plugin's namespace as prefix (e.g. Acme\MyPlugin\Vendor\Symfony\Console). Prefix is auto-updated by configure.php's existing search-and-replace during scaffolding. WordPress core namespaces (WP, Automattic) are excluded.

• composer.json — Adds humbug/php-scoper ^0.18 as a dev dependency and a scope script:

  composer scope
  # → runs: php vendor/bin/php-scoper add-prefix --force --output-dir=vendor-prefixed

• configure.php — Adds remove_scoper_files() and an opt-in prompt during scaffolding (default: no). If declined or Composer is not in use, removes scoper.inc.php, the workflow, and humbug/php-scoper from composer.json.

• .github/workflows/scoped-tests.yml — New CI job that installs deps, runs composer scope, then executes the PHP test suite against the scoped output on every PR.

• .gitignore — Adds vendor-prefixed/ as a build artifact.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Allow Composer Dependencies to be scoped</issue_title>
<issue_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

1. Plugins can be scaffolded and include php-scoper that will automatically scope the plugin's vendor files for release.
2. 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).
3. A developer can opt to not scope their plugin during the configuration step.
4. 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.</issue_description>

<agent_instructions>after install, we should scope the dependencies. </agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Allow Composer Dependencies to be scoped #309

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.