Discover contrib plugins via Composer metadata; custom from .polymer/plugins (PWT-115)

[lpeabody]

Summary

Makes plugin discovery independent of where plugins are installed, so contrib plugins can live in the normal vendor/ location and project-local custom plugins live under .polymer/plugins — no per-project installer-path configuration required.

Refs PWT-115.

What changed

ExtensionDiscovery::findExtensions() now merges two sources:

• Contrib plugins — located via Composer\InstalledVersions::getInstalledPackagesByType('polymer-plugin') + getInstallPath(), then reading each package's *.poly_info.yml. They're discovered wherever Composer installs them (vendor/ by default), so no installer-paths/extender machinery is needed.
• Custom plugins — the existing fixed-depth glob scan of <repo>/.polymer/plugins for project-local, committed plugins.

Local (custom) entries take precedence by extension id. Guarded when the Composer runtime API (getInstalledPackagesByType) is unavailable.

Context

PWT-115 originally aimed at remappable installer paths. While implementing, two heavier approaches were explored and rejected after verification:

• Auto-injecting installer-paths from the Composer plugin's activate() — doesn't work (composer/installers-extender reads installer-types at its own activation; plugin ordering means the injection is too late and the package falls back to vendor/).
• A configurable extension_paths discovery key — dropped, since managing install locations turned out not to be desired.

The accepted design above is simpler and removes the need to manage install locations at all.

Testing

• PHPUnit: 14/14; PHPStan (level 6) and phpcs clean.
• End-to-end in the consuming project: with the polymer installer-paths removed from the project composer.json, composer install places contrib plugins in vendor/digitalpolygon/*, and polymer plugin:list discovers them from there; all extension commands register; plugin:enable/disable gating still works (0 ↔ 7 commands).

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request refactors extension discovery in ExtensionDiscovery.php by separating the logic into two methods: findComposerInstalledExtensions(), which leverages Composer's InstalledVersions metadata to locate plugins, and findLocalExtensions(), which scans local directories. Feedback suggests using the union operator (+) instead of array_merge to prevent key reindexing and enforce precedence, checking for the existence of getInstallPath to ensure compatibility with older Composer versions, and using basename() with a suffix parameter to safely extract extension names.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.