Phpstan Laravel Laravel Package

Product Decisions This Supports

• Quality gates and CI policy: Decide whether Laravel-aware static analysis should block merges, run nightly, or start as advisory. This package extends PHPStan so Laravel-specific behavior—container bindings, facades, Eloquent models, config, validation, and package conventions—is understood during analysis.
• Build vs. buy: Avoid building and maintaining custom PHPStan stubs, rules, and Laravel type-resolution glue. Adopt an MIT-licensed extension instead, with the tradeoff of a small community and limited maintenance signal.
• Roadmap sequencing: Prioritize adoption before major Laravel/PHP upgrades or refactors, because stronger static analysis reduces upgrade risk and catches integration regressions earlier.
• Engineering productivity: Reduce review time spent on preventable type errors, undefined methods/properties, and misuse of Laravel APIs. This supports feature delivery predictability and lower defect leakage.
• Package/product ecosystem decisions: If the product includes Laravel packages, use the extension to validate package code against Laravel conventions and consumer expectations.
• Use cases: Laravel applications, Laravel packages, monorepos with shared Laravel code, teams already using PHPStan, and teams planning incremental static-analysis adoption via baselines and level ratchets.

When to Consider This Package

• Consider it when the product is a Laravel application or package and the team already uses—or plans to use—PHPStan in local development and CI.
• Strong fit when Laravel magic and framework conventions cause false positives with vanilla PHPStan, or when the team wants better analysis of facades, containers, Eloquent, config, and package service providers.
• Consider it for incremental adoption: start with a baseline, run at a low PHPStan level, and ratchet rules over time.
• Evaluate carefully if the team needs commercial support, SLAs, or a large maintainer community; 34 stars and an unknown repository are maturity risk signals. Pin versions and verify compatibility with the Laravel and PHPStan versions in use.
• Look elsewhere when the codebase is not Laravel, when PHPStan is not part of the quality strategy, when the team cannot own PHPStan configuration and baseline maintenance, or when the dependency’s supported Laravel/PHPStan matrix does not match the product.
• Avoid adopting it as the only quality mechanism for highly dynamic legacy code; pair it with tests, runtime monitoring, and targeted refactors.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, MIT-licensed quality improvement for Laravel products. It helps catch framework-specific defects before release, makes Laravel and PHP upgrades safer, and reduces engineering time spent on preventable bugs and review churn. The main caveat is maturity: the package has a small community footprint, so we should pilot it, pin the version, and measure defect and review impact before making it a required gate.

For engineering: The package extends PHPStan with Laravel-aware analysis, reducing false positives and improving coverage for framework conventions. Adopt it incrementally through CI, baseline existing errors, and ratchet PHPStan levels over time. Treat it as a build-vs-buy shortcut that avoids maintaining custom stubs and rules, while documenting version compatibility and fallback options in case maintenance slows.