Phpstan Typo3 Laravel Package

Product Decisions This Supports

• Whether to adopt PHPStan as a quality gate for TYPO3 codebases. This package is the enabling dependency for that decision — without TYPO3-aware reflection, PHPStan produces false positives on dependency injection, GeneralUtility::makeInstance(), Extbase conventions, and XCLASS overrides, which is usually what kills a static-analysis rollout in a TYPO3 shop. So the real decision is "PHPStan + this extension" vs. "no static analysis," not "this package vs. nothing."
• Upgrade and migration planning (v11 → v12 → v13). Framework-specific rules surface deprecated APIs, removed constants, and legacy patterns before an upgrade sprint starts. This converts an unbounded "how bad is our debt?" question into a scoped, ticketable worklist — directly feeds roadmap sizing and release-date commitments.
• Build vs. buy for internal tooling. The alternative is writing and maintaining your own TYPO3 reflection stubs and rule set. At 51 stars and MIT licensing, this is a clear "buy" (i.e., adopt) for all but the largest agencies; a custom ruleset is a recurring maintenance tax with no product differentiation.
• Third-party extension portfolio triage. Running the analyzer across vendor extensions gives a cheap, objective signal on which extensions are actively maintained vs. rotting, informing replace/extend/fork decisions in the dependency roadmap.
• Definition-of-done and CI investment. Adding this to the pipeline is the concrete mechanism behind "no new tech debt" policies. It also justifies CI runtime budget and PR-blocking gates.
• Onboarding and hiring. TYPO3's magic (DI, Extbase, Fluid, XCLASS) is a known ramp cost for generalist PHP hires. Framework-aware rules act as an always-on reviewer, reducing the senior-reviewer bottleneck — a people-cost argument, not just a code-quality one.
• Where to spend the tech-debt budget. Rule-level findings let you rank remediation by frequency and severity instead of by opinion, which is what makes a debt-reduction proposal defensible to a CFO.

When to Consider This Package

Adopt when:

• You are running, or have a funded plan to run, PHPStan on a TYPO3 CMS codebase (roughly v11+; confirm the supported matrix against your version).
• Your team is a TYPO3 agency or in-house TYPO3 team with more than one active site/extension, where false positives would otherwise consume review time.
• You want framework-specific rules, not just baseline PHP analysis — that is the differentiating value here.
• You can pin versions in composer.json (dev dependency) and tolerate the PHPStan major-version cadence; PHPStan extensions are tightly coupled to the analyzer's AST/reflection API.
• You accept single-maintainer, small-community risk and can mitigate it: version pinning, an internal fork (MIT permits it), or a maintainer relationship. Note the 51 stars / 0 dependents figures understate real usage — PHPStan extensions are require-dev and rarely appear in Packagist's dependency graph — but they are still not evidence of a large support ecosystem.

Look elsewhere or defer when:

• The codebase is not TYPO3 (Neos, Laravel, Symfony, Drupal) — this is framework-specific and irrelevant.
• The team standardizes on Psalm or PhpStorm inspections rather than PHPStan; there is no equivalent value here.
• You need a vendor support contract or SLA; this is community OSS with no commercial backing.
• The project is small or frozen — a handful of templates and one extension doesn't justify another CI stage and another dependency to upgrade.
• You are on an unsupported/legacy TYPO3 version; verify before committing, since reflection stubs track framework internals.
• You have no CI and no intention of building one — the package pays off only inside an automated feedback loop.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can raise code quality and de-risk our next TYPO3 upgrade for effectively zero licence cost. This is a small, MIT-licensed add-on that makes our static-analysis tooling understand TYPO3 specifically, so it flags real framework-level problems instead of drowning reviewers in false alarms. It is a development-time dependency only — it does not ship to production and cannot affect runtime or customer-facing behaviour. Expected return is fewer upgrade-surprise defects and less senior-developer time spent on manual review. The main risk is that it is a small community project, which we contain by pinning versions, running a timeboxed pilot on one codebase, and retaining the option to fork it since the licence permits that.

For engineering leadership: This plugs the known gap that makes PHPStan impractical on TYPO3 — without it, DI, makeInstance, Extbase and XCLASS patterns generate noise. Adoption is composer require --dev, a phpstan.neon include, and a CI stage. Success is measurable: baseline error count, false-positive rate, and count of deprecated-API findings resolved per sprint. Plan for version lockstep with PHPStan majors and budget a small amount of maintenance time per upgrade cycle.

For the engineering team: Treat it as the TYPO3 adapter for a tool we already want, not a new tool. Start advisory (non-blocking) on one repository, publish the baseline, then ratchet to blocking on changed files only. Do not enable the full rule set on day one on a legacy codebase — that produces a number nobody will fix and burns credibility for the next attempt.