Phpstan Strict Rules Laravel Package

Technical Evaluation

Architecture fit. Unchanged in kind: this is a dev-only static-analysis extension for PHPStan, not a runtime library. It fits teams already running PHPStan as a CI gate and wanting an opinionated policy layer for strictly typed PHP. No application architecture footprint, no production dependency, no Laravel service-provider registration. The architectural question remains cultural: does the codebase tolerate "extremely defensive" rules, or will teams suppress them locally? Release 2.1.0 does not change this positioning.

Integration feasibility. Still low effort to install: composer require --dev phpstan/phpstan-strict-rules, then either phpstan/extension-installer or an explicit includes: vendor/phpstan/phpstan-strict-rules/rules.neon. Rules remain controlled through parameters.strictRules, with individual toggles and an allRules: false mode for incremental adoption. However, the dependency floor has moved materially: 2.1.0 requires PHPStan 2.3.0+. Teams on PHPStan 1.x cannot adopt this release without a major-version PHPStan upgrade, which is the dominant integration cost for this version — far larger than config curation.

Technical risk. Moderate adoption risk, low security risk. The primary risk in 2.1.0 is the hard PHPStan 2.3.0 requirement. This is effectively a breaking change for any team pinned to PHPStan 1.x or to PHPStan 2.0–2.2, and it means Composer will either resolve an older strict-rules release or force a PHPStan upgrade mid-stream. Secondary risk: 2.1.0 contains rule-behavior refinements — arithmetic operand rules now name the node types they target, and loop-variable-overwrite reporting is narrowed to variables still in use. The narrowing is a genuine false-positive reduction (good), but the arithmetic message change can invalidate existing ignoreErrors entries and baseline fingerprints, producing either unexpected CI noise or silently stale ignores. The package remains tightly coupled to PHPStan versions, MIT-licensed, maintained under the PHPStan org, and community-supported with no commercial SLA.

Key questions.

• Which PHPStan major/minor is pinned in each repo, and is a PHPStan 2.3+ upgrade already on the roadmap?
• Does the team run PHPStan 1.x anywhere? If so, strict-rules 2.1.0 is out of scope until that migration lands.
• Do existing baselines or ignoreErrors patterns match arithmetic-operand message text, and will they need regeneration?
• Is the goal organization-wide strictness or a targeted pilot on one service?
• What is the tolerance for CI noise and remediation work in the first quarter?
• Who owns rule configuration, exceptions, and ignore comments?
• How will vendor, generated, and legacy code be excluded or baselined?
• Are developers trained on the semantics of the rules, or will they just disable them?

Integration Approach

Stack fit. Strong fit for Laravel/PHP shops on Composer and CI, but conditional on PHPStan 2.x. It composes cleanly with PHPStan and Larastan; the TPM must confirm the chosen Larastan version supports PHPStan 2.3+, since Larastan historically lags PHPStan majors. It remains orthogonal to Pint/PHP-CS-Fixer. Treat it as part of the quality gate, not a formatting tool.

Migration path. Use a phased rollout, now gated on the PHPStan major upgrade:

1. Inventory existing PHPStan config, version, level, baseline, and CI behavior per repo.
2. If on PHPStan 1.x, complete the PHPStan 2.x upgrade first as an independent, isolated change — do not bundle it with strict-rules adoption.
3. Validate Larastan (or other PHPStan extensions) against PHPStan 2.3+ before adding strict rules.
4. Add strict-rules 2.1.0 with strictRules.allRules: false; enable one or two high-value rules (e.g., strictFunctionCalls, disallowedLooseComparison).
5. Regenerate or extend the PHPStan baseline; explicitly audit ignoreErrors entries that reference arithmetic-operand messages, which changed in 2.1.0.
6. Expand rule coverage module-by-module; remove baseline entries over time; only then consider allRules: true.

Compatibility. Pin phpstan/phpstan to ^2.3 and phpstan/phpstan-strict-rules to ^2.1 as a coordinated pair. Verify PHP runtime support in the CI matrix against both. Prefer extension-installer to reduce config drift, documenting the manual rules.neon include as a fallback. Note that 2.1.0's branch activity (2.1.x opened, 2.0.x merged forward) signals continued minor releases; expect further PHPStan-minor coupling and keep upgrade sequencing owned by one person.

Sequencing. Order of operations matters more than in the prior assessment: PHPStan major upgrade → extension compatibility validation → strict-rules install with minimal rule set → baseline → expansion. Pilot on a single bounded service or module for one sprint and measure violation count, remediation effort, and developer sentiment. Avoid big-bang enablement and avoid stacking the PHPStan upgrade and strict-rules adoption in the same change window.

Operational Impact

Maintenance. Low but non-zero, and slightly higher than before given the PHPStan 2.3 floor. No production patching burden, but maintenance now includes staying current on PHPStan minors, since strict-rules minors can raise the floor. Assign an internal owner for PHPStan config and version alignment to prevent silent drift.

Support. Community-supported via GitHub issues; no vendor SLA. PHPStan org backing provides credibility but no contractual response times. Internal triage capability for rule behavior remains a prerequisite; do not depend on upstream for urgent fixes, particularly during a PHPStan major transition.

Scaling. Analysis time grows with codebase size, and PHPStan 2.x rule changes plus strict rules can increase CI duration. Use result caching, parallel analysis, and path scoping. For monorepos, prefer per-package configs and incremental adoption over a single global ruleset. Track CI minutes and failure rate as adoption scales, and expect a one-time CI cost spike during the PHPStan 2.3 upgrade.

Failure modes.

• Composer resolves to an older strict-rules release, or the PHPStan 2.3 requirement blocks the intended upgrade.
• Bundling the PHPStan major upgrade and strict-rules adoption into one change, obscuring the cause of new failures.
• Changed arithmetic-operand messages invalidate ignoreErrors patterns, causing stale ignores or unexpected failures.
• CI breaks on pre-existing violations due to missing or un-regenerated baseline.
• Larastan or another PHPStan extension is incompatible with PHPStan 2.3+.
• Developers suppress rules with inline ignores instead of fixing code.
• Rules silently disabled during config refactors.
• False positives on framework magic, dynamic calls, or generated code (partially reduced in 2.1.0 for loop-variable overwrites).
• Baseline grows unchecked and becomes permanent debt.

Ramp-up. Budget one to two sprints for pilot setup, baseline creation, and developer education — plus dedicated effort for the PHPStan 2.x upgrade if not already complete. Organization-wide rollout remains a quarter-scale change when remediation is included. Provide short guidance on why each rule exists, how to fix common violations, and when an exception is legitimate. Appoint a "rules champion" to review exceptions. Measure success by new-violation catch rate, baseline shrinkage, CI stability, and developer feedback — not by rule count alone.