- How do I install ergebnis/phpstan-rules in a Laravel project?
- Install it as a dev dependency with composer require --dev ergebnis/phpstan-rules. If phpstan/extension-installer is already present, the package's rules.neon is included automatically; otherwise add the vendor/ergebnis/phpstan-rules/rules.neon include to your phpstan.neon. No service provider, config publishing, or application code change is required because the package is only used at analysis time.
- What rules does this package add on top of PHPStan's own checks?
- The documented set includes NoNamedArgumentRule for calls, FinalRule and NoExtendsRule for classes, and NoParameterWithNullDefaultValueRule for closures, with the full list defined in rules.neon. They are opinionated architectural and code-quality conventions rather than replacements for PHPStan's core analysis. The intended setup is to layer them on top of phpstan/phpstan, phpstan-strict-rules, and phpstan-deprecation-rules.
- Do I have to use phpstan/extension-installer, or can I include rules.neon manually?
- The extension installer is optional but convenient: when it is installed, rules.neon is picked up automatically with no configuration. Without it, you add the include line for vendor/ergebnis/phpstan-rules/rules.neon to your phpstan.neon and PHPStan loads the rules from there. Both approaches produce the same rule set, so choose based on whether your other PHPStan extensions already rely on the installer.
- Which PHPStan and PHP versions are supported, and does Laravel version matter?
- Support floors follow PHPStan itself, so confirm that your installed PHPStan major matches the package's documented support matrix; the 2.14.2 patch does not change any PHP or PHPStan minimum. There is no Laravel version constraint because the package never touches framework code, service containers, or runtime behavior. It fits any Laravel or plain PHP codebase that already runs PHPStan.
- Why did new PHPStan errors appear after upgrading to 2.14.2?
- The 2.14.2 patch contains a single fix: Closures\NoParameterWithNullDefaultValueRule was previously not registered in rules.neon and is now active. As a result, closures with implicitly nullable signatures such as ?Type $param = null that were silently unchecked before may now be reported. There are no breaking changes, API changes, or new rules, so the effect is CI noise rather than a structural change.
- Should I pin ergebnis/phpstan-rules or float within ^2.14?
- Floating within ^2.14 picks up patch fixes automatically, but each patch can activate or correct rules and surface new findings in CI. Pinning gives reproducible builds across the team and a deliberate upgrade step. A practical middle ground is to commit composer.lock, float in the constraint, and review the analysis delta whenever the lock file changes.
- How do I disable or exclude a specific rule, such as FinalRule, for certain paths?
- Rules are registered through rules.neon, so you can skip that include and register only the individual rule classes you want in phpstan.neon, or override parameters in your own config. Use PHPStan's standard excludePaths and ignoreErrors settings to scope findings to specific directories or files. Regenerating the baseline is often simpler than per-path excludes when you only want to defer pre-existing violations.
- Does this package affect production runtime or only CI?
- It is a build-time and CI-time concern only. Nothing is autoloaded during requests and there is no service provider, so production behavior, performance, and deployment artifacts are unaffected. The failure mode of an upstream regression is a noisy or failing analysis job, never a runtime error in the application.
- How is this different from phpstan-strict-rules or Larastan?
- It is complementary rather than a competing tool: the README explicitly recommends using it on top of phpstan/phpstan, phpstan-strict-rules, and phpstan-deprecation-rules. Larastan adds Laravel-aware analysis of framework APIs, while this package contributes opinionated conventions such as final classes, no class extension, and no named arguments. You can run all of them together without conflicts with Laravel Pint or PHP-CS-Fixer, since those operate on formatting rather than static analysis.
- How do I roll it out incrementally on an existing Laravel codebase?
- Add the include, run PHPStan and generate a baseline so pre-existing findings are recorded rather than failing the build. Commit that baseline, then fix and shrink it over time while keeping the ruleset active for new code. Because adoption is a single rules.neon include plus per-path excludes, you can enable it on one module or directory first and expand once the team is comfortable with the findings.