Phpstan Strict Rules Laravel Package

Product Decisions This Supports

• Roadmap: type-safety and modernization initiatives. This package is the cheapest lever for moving a Laravel codebase toward strict typing. It directly supports decisions like "do we invest a sprint in hardening the legacy monolith before the PHP 8.x upgrade / framework upgrade?" by making the cost of loose comparisons and implicit casting visible and countable.
• Build vs. buy for quality tooling. Building bespoke static-analysis rules in-house is a recurring cost with no product differentiation. This is the buy answer: MIT-licensed, first-party-maintained by the PHPStan organization, one Composer line, no runtime footprint.
• Release-gating policy. Because each rule is individually toggleable, it supports a phased rollout decision: advisory in CI first, then blocking on changed files, then blocking repo-wide. That sequencing is a policy choice a PM can own with engineering rather than an all-or-nothing flag flip.
• Technical-debt quantification. Violation counts per rule (disallowedLooseComparison, strictFunctionCalls, booleansInConditions, arithmeticOperandTypes, etc.) become a debt inventory you can chart sprint over sprint — far more defensible in a roadmap conversation than "the code feels fragile."
• Risk prioritization for high-consequence domains. In billing, permissions, entitlement checks, coupon/discount math, and ID lookups, == vs ===, in_array without strict mode, and empty() are classic sources of production incidents. This package converts those idioms into build failures in exactly those modules first.
• Prioritizing where "defensive programming" is worth the friction. Use it to decide which services/domains get the strict ruleset and which stay on baseline — an explicit, reviewable scope decision instead of an implicit cultural one.
• Onboarding and standards codification. Encodes "how we write PHP here" executably, reducing review nitpicks and giving new hires a machine-checked definition of done.
• Explicitly not a product differentiator. It ships no user-visible capability. Frame it as reliability/quality-of-service investment, not a feature line item.

When to Consider This Package

Adopt when:

• The team already runs PHPStan (or has committed to it) — this is an extension, not a standalone tool, and delivers zero value without it.
• You are on PHPStan 2.3.0 or newer — as of 2.1.0 this is a hard floor, not a soft guideline. If you're pinned to PHPStan 2.0–2.2 (common in codebases that haven't touched their static-analysis config since a framework upgrade), the PHPStan bump is a prerequisite project, not a same-day install.
• There is CI with a PHP job; the value comes from enforcement, not local convenience.
• The codebase is new, recently refactored, or being modernized — the migration window is when strictness is cheapest to introduce.
• The domain is high-consequence (money, auth, entitlements, identifiers) where a loose comparison is a real incident class.
• Engineering has bandwidth to fix findings. Adding it while producing hundreds of permanently-suppressed errors is negative value: it trains the team to ignore the linter.
• You want opinionated, curated rules rather than authoring and maintaining your own PHPStan rule set.

Look elsewhere / deprioritize when:

• No static analysis and no appetite to adopt it. Start with PHPStan itself at a sensible level; this package is step two.
• The need is style and formatting — that is Laravel Pint, PHP-CS-Fixer, or Slevomat; strict-rules is semantic, not cosmetic, and won't format anything.
• The need is runtime input validation or type coercion safety at the API boundary — that is request validation, DTOs, and value objects, not static analysis.
• A very large legacy codebase with no baseline mechanism and no owner for the findings. If nobody owns the burn-down, the rules become noise. Consider per-directory adoption instead of repo-wide.
• A team that intentionally relies on PHP's loose-comparison semantics (rapid prototyping, throwaway internal tools, thin admin CRUD). You will spend the budget disabling most of the ruleset, and a mostly-disabled ruleset delivers a fraction of the benefit while carrying the maintenance cost.
• You are not on PHP/PHPStan, or you cannot move to PHPStan ≥ 2.3.0 — the 2.1.x line will not install against older PHPStan majors, so this is a gating constraint to check before promising a timeline.
• You expect static analysis to replace tests. It catches type and idiom mistakes, not wrong business logic or missing authorization.

Adoption caveats to validate before committing: confirm the PHPStan version pairing (now ≥ 2.3.0 for this release line — budget the PHPStan upgrade as its own line item if you're behind); note that installing it also changes some PHPStan core defaults (so behavior shifts even with allRules: false); and confirm the rules you actually want — not all of them — map to your domain risk.

What changed in 2.1.0 and why it matters to the plan: the PHPStan floor moved to 2.3.0, and two refinements reduce the "linter noise" objection that most often kills this kind of adoption. Loop-variable-overwrite findings are now reported only for variables still in use, cutting a known false-positive class out of the baseline; arithmetic-operand-rule messages now name the node types involved, which shortens triage and lowers the per-finding fix cost. Net effect: slightly higher entry cost (the PHPStan upgrade), materially better signal-to-noise once you're in — which strengthens the read-only spike case rather than weakening it.

How to Pitch It (Stakeholders)

For executives (one paragraph): A free, MIT-licensed, dev-only extension that makes our existing static analysis stricter about the specific PHP idioms that cause production bugs — loose comparisons, missing strict flags on in_array/array_search, empty(), mismatched switch types, and arithmetic on mixed operands. It ships nothing to production and adds no runtime dependency or performance risk; it only turns classes of defects into CI failures before release. It is maintained by the same organization that maintains PHPStan, so abandonment risk is low despite the modest star count. Cost is roughly one Composer line plus a timeboxed cleanup sprint — and, if we're behind, a PHPStan upgrade to 2.3.0 first. Benefit is fewer type-related incidents in our highest-risk code paths and an audit-ready, per-rule count of our technical debt.

For engineering leads: Drop-in via Composer with phpstan/extension-installer, or a one-line rules.neon include. Requires PHPStan ≥ 2.3.0 from the 2.1.x line onward, so sequence the PHPStan upgrade ahead of it. Every rule has a named config toggle and its own error identifier, so we can enable rules one at a time, write baselines per directory, and scope the strict ruleset to the modules that carry real risk first. 2.1.0 also tightens the loop-variable-overwrite rule to only flag variables still in use and makes arithmetic-operand errors state which node types are expected — both reduce baseline noise and review churn. It composes with — doesn't replace — PHPStan levels, Pint, and our test suite.

For the sponsor / decision ask: Approve a timeboxed spike — install in a branch (including the PHPStan 2.3.0 bump if needed), run it read-only against the codebase, and report violation counts per rule and per module. Those numbers turn this from a tooling preference into a scoped, costed cleanup proposal with a defensible priority order. Low downside: if the findings aren't worth the churn, we remove one dev dependency and revert the config.