Phpstan Typo3 Laravel Package

Technical Evaluation

Framing correction (material to any decision): despite the request framing this as a Laravel/PHP package, saschaegerer/phpstan-typo3 is TYPO3 CMS–specific. It contributes a TYPO3-aware class reflection provider to PHPStan plus a ruleset encoding TYPO3 framework conventions (DI container resolution, XClass/$GLOBALS['TYPO3_CONF_VARS'] overrides, Extbase conventions). For a Laravel estate it delivers zero value. Evaluate it only if the portfolio contains TYPO3 v11/v12/v13 installations.

Architecture fit. The extension is architecturally clean: it hooks PHPStan's extension API rather than patching it, so it composes with existing PHPStan baselines, level settings, and other extensions. That is the right integration surface for a static-analysis add-on. The constraint is that it presumes a functioning PHPStan pipeline and a TYPO3 codebase whose class resolution is non-trivial — which is precisely where TYPO3's DI container and legacy class overrides cause PHPStan to emit false positives. This package addresses a real, narrow pain point rather than inventing one.

Integration feasibility. Low mechanical effort: a dev-only Composer dependency, an includes: line in phpstan.neon, and paths for typo3/ and Configuration/. The real work is version triangulation — PHPStan major line, TYPO3 major line, and PHP version must all be mutually compatible. Expect to spend more time on the compatibility matrix than on installation.

Technical risk.

• Bus factor. 51 stars, 0 dependents, effectively a single-maintainer project. No downstream consumers means no de facto compatibility testing from the ecosystem.
• Upstream churn. PHPStan has historically broken extension internals across majors; a lagging extension can block your PHPStan upgrade, or vice versa.
• TYPO3 coupling. Reflection behaviour shifts between TYPO3 majors (and with v14 on the horizon); the extension must track both TYPO3 and PHPStan release trains simultaneously.
• Bootstrap weight. TYPO3-aware reflection generally needs a bootstrapped environment, which raises CI runtime and introduces a class of failure that is environmental rather than code-related.
• Release-date anomaly. The listed last release of 2026-07-30 is in the future relative to any current evaluation. Treat the registry metadata as unverified and confirm against Packagist tags and commit history before relying on maintenance signals.
• Score context. A composite score of ~18/100 against an opportunity score of ~59 is the classic "high relevance, low maturity" profile — real gap, thin supply. That argues for adoption with containment, not adoption on faith.

Key questions to resolve before committing.

1. Which PHPStan major/minor and TYPO3 major versions are actually supported, and what is the maintainer's demonstrated lag on prior PHPStan majors?
2. Does analysis require a fully bootstrapped TYPO3 instance, and what does that add to CI wall-clock and memory?
3. How many findings does the extension surface on our codebase at baseline level, and what share are false positives?
4. What is the maintainer's release cadence and issue-response history over the last 12 months?
5. If the project stalls, can we vendor/fork the reflection provider internally — and who owns that?

Integration Approach

Stack fit. Applies only to TYPO3 services. Within those, it fits the standard quality stack: Composer (dev), PHPStan (analysis engine), CI (GitHub Actions/GitLab), and optionally a baseline file for debt suppression. It has no runtime footprint — nothing ships to production.

Migration path.

1. Install PHPStan alone at a low level; generate a baseline to freeze existing debt.
2. Add phpstan-typo3 to the same phpstan.neon include chain; re-run against the frozen baseline and diff the new findings.
3. Triage new findings into: genuine bugs, false positives (report upstream or ignore with ignoreErrors and a comment), and framework-noise to suppress permanently.
4. Ratchet the level upward one step per sprint; keep the baseline monotonically shrinking rather than regenerating it wholesale.
5. Only then enable the framework-specific rules as a separate CI job if they prove too noisy for the default gate.

Compatibility. Maintain an explicit, documented matrix: TYPO3 major × PHPStan major × PHP minor. Pin the extension to an exact version in composer.json ("saschaegerer/phpstan-typo3": "x.y.z"), not a caret range, so a routine composer update cannot silently change analysis semantics. Re-evaluate the pin on each TYPO3 LTS upgrade.

Sequencing. Do not bundle this with a TYPO3 upgrade. Land PHPStan and the baseline first (one change), the extension second (one change), and level ratcheting third (continuous). If the extension is introduced during a framework upgrade, you cannot distinguish new framework breakage from new rule findings — that ambiguity is the single most likely way this initiative loses credibility with engineering.

Operational Impact

Maintenance. Low run-rate cost for consumers, moderate for the owner. Budget: one dependency-review pass per PHPStan major, one per TYPO3 LTS, plus monitoring of the upstream repo for abandonment signals (no release across a PHPStan major, unanswered issues, archived status). Keep an exit plan: the reflection provider is the only genuinely non-trivial piece; if abandoned, the pragmatic fallback is to drop to plain PHPStan with targeted ignoreErrors and a documented exception list.

Support. Community-only, MIT, no vendor SLA. Internal escalation path must terminate at a named engineer, not at the upstream issue tracker. Expect to file or self-patch fixes for TYPO3-version-specific reflection gaps.

Scaling. Analysis time grows with codebase size and with bootstrap overhead. For large TYPO3 monorepos, plan for parallelised PHPStan runs (--memory-limit, process concurrency) and cache the Composer/TYPO3 bootstrap layer in CI. The extension itself does not scale horizontally; the pipeline around it must.

Failure modes to instrument for.

• Silent degradation: reflection provider fails to load, extension is skipped, pipeline still goes green while analysing less than intended. Guard with a canary file containing a known TYPO3-specific violation that must be reported.
• False-positive cascade: a ruleset change floods CI and engineers start ignoring the gate. Guard with baseline discipline and a hard cap on new findings per PR.
• Upgrade deadlock: PHPStan security update blocked by extension incompatibility. Guard with a quarterly dependency review and a pre-agreed "drop the extension" decision threshold.
• Bootstrap fragility: environment drift (missing TYPO3 config, DB dependency) causes intermittent CI failures. Guard by pinning the CI image and caching the bootstrap artefacts.

Ramp-up. Developers: under a day — it is a linter; the output is familiar. The build/DevEx owner: one to two weeks to establish the compatibility matrix, baseline policy, canary check, and escalation path. That owner investment is the actual cost of adoption; the Composer install is trivial by comparison. Given the maturity profile, staff it as a single-owner, contained bet with a written fallback — not as a platform-wide standard.