Typo3 Debug Dump Pass Laravel Package

Product Decisions This Supports

• Static analysis investment (build vs. buy). This package is a small, dev-only compiler pass that makes the compiled TYPO3/Symfony DI container legible to PHPStan and TYPO3-Rector. It is a build-vs-buy decision at the smallest possible scale: an afternoon of a platform engineer's time to replicate, versus adopting a 3-star dependency. The decision it really informs is how far up the PHPStan level ladder we can push on a container-heavy codebase before type noise (object, mixed from makeInstance() and injected services) blocks us.
• CI quality-gate roadmap. If we want static analysis as a merge gate rather than a suggestion, we need tooling that resolves container types. This package is a candidate enabler for that roadmap item, not a feature in itself.
• TYPO3 upgrade planning. Because it explicitly targets TYPO3-Rector, it belongs in the decision set for v12/v13 migrations — do we invest in automated upgrade tooling (Rector + PHPStan + container typing) or budget manual refactor time? This tilts the math toward automation.
• Prioritizing developer-experience work. Useful as a concrete, low-cost line item when a platform team argues for DX/CI budget against feature work: it is measurable (type errors caught pre-merge, time-to-merge, refactor blast radius) and cheap to trial.
• Dependency policy calibration. With zero dependents and a single maintainer, adopting it forces an explicit stance on how much low-maturity, dev-only tooling we tolerate in the build — a reusable precedent.

When to Consider This Package

• The codebase is TYPO3 with the Symfony DI container, and service resolution is a significant source of PHPStan failures or suppressions.
• You are already running PHPStan at a meaningful level and/or TYPO3-Rector for upgrades; this package only pays off as part of that stack.
• You accept it as a dev-only, pinned dependency — never in production autoload, always behind CI.
• You are willing to read the source. It is small and single-purpose; the pass is the whole product.

Look elsewhere when:

• The project is not TYPO3/DI-container-based, or the container is not the typing bottleneck.
• You need runtime container introspection or validation — Symfony's debug:container, lint:container, and ContainerDebugDumpPass already cover that.
• Your dependency policy forbids low-maturity, single-maintainer packages in the build pipeline, or supply-chain review cost exceeds the benefit.
• The codebase is small enough that a handful of PHPStan stubs or typed factory wrappers solve it faster.
• You need guaranteed maintenance and release cadence — 3 stars, 0 dependents and one maintainer is a real risk signal, not a formality.

How to Pitch It (Stakeholders)

To executives: This is a near-zero-cost developer tooling addition, not a product change. It does not ship to customers, adds no runtime footprint, and is confined to our build pipeline. The return is indirect but real: fewer type-related defects escaping refactors, faster and safer TYPO3 upgrades, and less engineering time lost to static-analysis noise. The main caveat is maturity — it is a small, single-maintainer package, so we should treat it as a trial with an exit ramp rather than a load-bearing dependency.

To engineering: It's a compiler pass that dumps container debug information so PHPStan and TYPO3-Rector can resolve service types instead of falling back to object/mixed. Registration is a dev-only Services.yaml entry; removal is one line. It complements, not replaces, lint:container and debug:container. Treat it as pinned, dev-only, and reviewed-on-upgrade — the source is small enough that vendoring the pass is a legitimate fallback if the package stalls. Success looks like: higher PHPStan level with fewer ignores, and cleaner Rector diffs during the next major upgrade.