Add ResultCacheMetaExtension so the result cache tracks the Drupal site

[mglaman]

Part 9 of 9 in the legacy-code audit stack. The highest-impact finding from the audit: PHPStan's result cache never invalidated when the analyzed Drupal site changed.

Why

PHPStan hashes its bootstrap files, but knows nothing about the Drupal extensions, services.yml files, and config schemas our bootstrap discovers. Enabling a module, editing a services.yml, or upgrading core silently reused stale analysis results until the user ran --no-result-cache or the cache expired.

What changed

BootstrapResultCacheMetaExtension implements PHPStan's ResultCacheMetaExtension (phpstan.resultCacheMetaExtension tag). Its hash covers:

• the discovered extension inventory — info-file path and content per module/theme/profile,
• every consumed services.yml (path and content),
• all *.schema.yml files in the collected schema directories,
• \Drupal::VERSION, which catches tarball core upgrades (composer-managed upgrades are already covered by PHPStan's own composer.lock hashing).

Any change invalidates the whole result cache. The hashing runs once per analysis over a few hundred small YAML files — well under 50ms. Discovered PHP files are deliberately not hashed; PHPStan hashes analyzed files itself.

To feed the extension, ServiceMap::setDrupalServices() gains an optional second parameter recording the consumed yml paths (backwards compatible), and ConfigSchemaData exposes its schema directories.

Testing

New unit tests assert the hash is deterministic, and changes when the extension list, a services.yml's content, or a schema directory changes. The tests run in separate processes because the underlying state is static. Full suite, self-analysis, and phpcs are green.

🤖 Generated with Claude Code