Phpstan Rules Laravel Package

Technical Evaluation

Architecture fit: PHPStan is standard in modern PHP projects for static analysis, and this package extends it with opinionated rules. It integrates seamlessly into existing PHPStan setups without altering core architecture. Ideal for enforcing strict coding standards in Laravel applications where type safety and code quality are priorities.

Integration feasibility: High. The package is consumed as a Composer dev dependency and activated by including its rules.neon in a project's PHPStan configuration — no application code, service container, or runtime changes are required. It is a build/CI-time concern only, so it can be adopted incrementally (single ruleset include, per-path excludes) and rolled out behind a baseline file.

Technical risk: Low-to-moderate. Version 2.14.2 is a patch release containing a single fix — Closures\NoParameterWithNullDefaultValueRule was previously not registered in rules.neon and is now active. The practical consequence is behavioral, not structural: after upgrading, projects may report new violations for closures with ?Type $param = null signatures that were silently unchecked before. There are no breaking changes, no API changes, no deprecations, and no new rules introduced. The main risk is CI pipeline noise at upgrade time rather than runtime or architectural risk.

Key questions:

• Do we pin the package version, or float within ^2.14 for automatic patch uptake?
• Are our PHPStan baselines regenerated on upgrade, or do we let newly surfaced violations fail the build?
• Is NoParameterWithNullDefaultValueRule a rule we intend to enforce (it flags implicitly-nullable parameters), or should it be excluded to match our existing conventions?
• What is the team's tolerance for CI churn on patch upgrades?

Integration Approach

Stack fit: Fits any Laravel or plain PHP codebase already running PHPStan. Composer-managed, PHP-version-constrained only by PHPStan itself. No conflict with Laravel Pint, PHP-CS-Fixer, or existing static analysis tooling, since it operates strictly as a PHPStan extension.

Migration path: Add ergebnis/phpstan-rules to require-dev, include vendor/ergebnis/phpstan-rules/rules.neon from phpstan.neon, then run analysis and generate a baseline for pre-existing findings. For this specific upgrade, the migration step is to run PHPStan against the codebase after bumping 2.14.1 → 2.14.2 and review the delta attributable to the newly registered closure rule.

Compatibility: Patch-level release; compatible with the 2.14.x line and the PHPStan versions already supported by 2.14.1. No PHP or PHPStan version floor changes are implied by the notes. Confirm only that the installed PHPStan major matches the package's documented support matrix.

Sequencing: (1) Bump to 2.14.2 on a non-blocking branch; (2) run full analysis and diff the findings against 2.14.1; (3) decide per-finding whether to fix the closure signatures or extend the baseline; (4) merge; (5) only then consider promoting the package to a strictly pinned version for reproducibility across the team. Do not bundle this bump with PHPStan major upgrades, so any regressions are attributable to a single change.

Operational Impact

Maintenance: Minimal. Single-maintainer, actively released package with semantic versioning and generated changelogs. Patch upgrades are cheap to evaluate; the only recurring cost is re-running analysis and reviewing the findings delta.

Support: Upstream support is via GitHub issues; no commercial SLA. Because the failure mode is confined to CI, an upstream regression degrades pipeline reliability but never production behavior. Pinning the version provides a sufficient escape hatch.

Scaling: Scales linearly with codebase size in analysis time only. Adoption can be scaled across teams by centralizing the phpstan.neon ruleset in a shared internal package so rule configuration stays consistent and upgrades are coordinated rather than per-repo.

Failure modes: (a) Newly activated rules surface previously hidden violations and block merges — the exact risk introduced by 2.14.2; (b) over-broad rule activation generates false positives that teams suppress by disabling rules wholesale, eroding value; (c) version drift across repositories leading to inconsistent enforcement; (d) upstream patch releases changing rule registration without a minor version bump, as happened here.

Ramp-up: Low. Engineers need only understand how to read PHPStan output and how to write a baseline entry or inline ignore with justification. Budget a short onboarding note documenting the ruleset include, baseline policy, and the review step for patch upgrades — the 2.14.2 case is a good worked example of why that review step exists.