## Problem drupal-rector registers phpstan-drupal via `$rectorConfig->phpstanConfigs([… /extension.neon])`, but Rector only *builds* the PHPStan DI container from that config — it never runs the extension's declared `bootstrapFiles:` (`drupal-autoloader.php`). That autoloader is what calls `DrupalAutoloader::register($container)`, which scans every `*.services.yml` and populates phpstan-drupal's `ServiceMap`. The consequence: under Rector the ServiceMap is **empty**, so `\Drupal::service('renderer')` resolves to bare `object` (its declared return type) instead of `Drupal\Core\Render\Renderer`. Every type-guarded rector keyed on a `service()` receiver silently skips real code (`isSuperTypeOf` → MAYBE). Our own bootstrap (`config/drupal-phpunit-bootstrap-file.php`) only ever set up test-namespace autoloading — it never populated the ServiceMap. The historical workaround (`bootstrapFiles([drupal-autoloader.php])`) could not work because phpstan-drupal's autoloader hard-requires a `$container` that Rector did not provide, throwing *"The autoloader did not receive the container."* ## What changed upstream [rectorphp/rector#8190](https://github.com/rectorphp/rector/pull/8190) ("Make PHPStan DI-Container available in bootstrap files", in `dev-main`) now injects the PHPStan container into every file registered via `$rectorConfig->bootstrapFiles()` as a `$container` variable — exactly what phpstan-drupal's `drupal-autoloader.php` needs. (Note: rectorphp/rector#9782 — auto-running an extension neon's *own* `bootstrapFiles:` — is still open; #8190 is the narrower enabling change, so we still list the bootstrap file explicitly.) ## Proposed fix Make `config/drupal-phpunit-bootstrap-file.php` container-aware: - When `$container instanceof PHPStan\DependencyInjection\Container` (Rector ≥ #8190), delegate to phpstan-drupal's own `drupal-autoloader.php`, which does the test-namespace autoloading **and** populates the ServiceMap. - Otherwise (older Rector, phpstan-drupal absent, or the hand-off throws), fall through to the existing legacy autoloading — byte-for-byte today's behaviour. This is purely additive and backward compatible across Rector versions, so **no composer constraint bump** is required. Users on a Rector release containing #8190 automatically get accurate `\Drupal::service()` type inference; everyone else is unchanged. ## Validation Sandbox: Drupal 11.4.4, `rector/rector:dev-main`, `mglaman/phpstan-drupal:2.1.1`, drupal-rector as a path repo. | Scenario | ServiceMap size | `service('renderer')` | Rule fires | |---|---|---|---| | Baseline (extension.neon loaded, autoloader not run) | 0 | bare `object` | — | | Current fork bootstrap | 0 | bare `object` | — | | Delegate branch (Rector #8190 injects `$container`) | **2025** | `Drupal\Core\Render\Renderer` | yes | | Fallback branch (no `$container`) | n/a | n/a | identical to fork: 737 test namespaces registered, no throw | `BlockContentTestBaseStringToArrayRector` produces an identical diff under the legacy fork and the new delegate path, confirming parity for the autoloading concern; the delegate path additionally fixes the empty-ServiceMap gap. GitHub PR: (to be linked).