Phpstan Drupal Laravel Package

Product Decisions This Supports

• Build vs. buy for static analysis: Adopting mglaman/phpstan-drupal is the "buy" (well, MIT-license "adopt") answer to the question "do we write our own PHPStan rules for Drupal?" — it encodes Drupal-specific knowledge (hooks, plugins, services, entity types, annotations, Form/Entity APIs) that vanilla PHPStan cannot reason about, so building equivalent rules in-house is almost never justified.
• Roadmap sequencing for quality gates: Informs when to introduce or tighten static analysis in CI, which PHPStan levels to target per release, and whether to gate merges on analysis results.
• Drupal upgrade planning: Deprecation and API-usage detection makes Drupal 10/11 readiness a tractable, measurable workstream rather than a big-bang migration; results can size upgrade epics and prioritize module remediation.
• Use-case prioritization: Strongest ROI on custom and contributed module development, large multi-module sites, and platform teams with many contributors — less so on one-off brochure sites.
• Onboarding and knowledge debt: Codifies "Drupal magic" that normally lives in senior developers' heads, reducing ramp time and review load — a lever for team scaling decisions.
• Contrib/OSS strategy: If the org maintains contributed modules, this supports decisions about publishing quality baselines and CI templates for those projects.

When to Consider This Package

Consider adoption when:

• The codebase is Drupal 8/9/10/11 and predominantly PHP custom/contrib code.
• PHPStan is already in the toolchain, or there is appetite to add it; this package is an extension, not a standalone analyzer.
• You have a CI pipeline where analysis can run per-PR and a baseline can be tolerated during initial rollout.
• You are planning or actively executing a Drupal major-version upgrade and want early deprecation signal.
• Multiple developers (or contractors) touch the same modules and review consistency matters.

Look elsewhere when:

• The stack is not Drupal, or is Drupal 7-only with no realistic upgrade path.
• The team has no static-analysis culture and no owner to triage findings — the tool will produce noise and be disabled.
• You need runtime/behavioral analysis (performance, security dynamic testing) rather than compile-time checks; pair with other tooling instead.
• The project is very small and single-maintainer, where setup and baseline cost outweigh defect-prevention value.
• A hard requirement exists for vendor support/SLA — this is community-maintained (MIT), so plan for internal ownership.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, MIT-licensed extension that makes our Drupal code checkable automatically before it ships. It reduces defect escape to production, de-risks and sizes our Drupal upgrade work, and shortens onboarding for new engineers — with no licensing spend and incremental rollout. The main cost is engineering time to adopt and triage, not procurement.

For engineering: It teaches PHPStan how Drupal actually works — hooks, plugins, services, entity annotations, Form API — so we stop getting false positives and start catching real mistakes: deprecated API calls, wrong service signatures, broken plugin definitions. It installs via Composer, plugs into existing PHPStan config, and supports a baseline so we can adopt gradually and ratchet levels over time. It does not replace tests or runtime monitoring; it complements them by shifting cheap checks left into CI.