Weave Code
Phpstan Strict Rules Laravel Package
phpstan/phpstan-strict-rules
Extra strict, opinionated PHPStan rules for defensive, strongly typed PHP: require booleans in conditions, strict function-call flags, numeric arithmetic operands, matching switch types, no useless casts, and safer loop variable handling.
Extra strict and opinionated rules for PHPStan
Frequently asked questions about Phpstan Strict Rules
- How do I install phpstan/phpstan-strict-rules in a Laravel project?
- Install it as a dev dependency with composer require --dev phpstan/phpstan-strict-rules. If you already use phpstan/extension-installer, the rules.neon file is registered automatically and no further setup is needed. Otherwise, add an includes entry pointing at vendor/phpstan/phpstan-strict-rules/rules.neon in your phpstan.neon. There is no service provider or Laravel configuration to publish, since it is a static-analysis extension only.
- Does phpstan/phpstan-strict-rules 2.1.0 require PHPStan 2.3 or can I still use PHPStan 1.x?
- Version 2.1.0 requires PHPStan 2.3.0 or newer, so projects pinned to PHPStan 1.x cannot use this release at all. On those projects Composer will either resolve an older strict-rules release or force a PHPStan major upgrade mid-stream. The PHPStan upgrade is the dominant integration cost here, far larger than curating rule configuration. Treat the upgrade as an isolated change before adopting strict rules.
- How do I enable phpstan-strict-rules without phpstan/extension-installer?
- Add an explicit include to your phpstan.neon: includes: - vendor/phpstan/phpstan-strict-rules/rules.neon. This is the recommended path when you want the rules wired in deterministically rather than through automatic extension discovery. Keep the include after your own parameters block if you plan to override strictRules toggles. The same file can be included from a shared config used by multiple repositories.
- How can I enable only a few strict rules instead of all of them?
- Set parameters.strictRules.allRules to false and then turn on individual toggles such as strictFunctionCalls, booleansInConditions, or uselessCast. This incremental mode lets you adopt one or two high-value rules first and expand coverage module by module. It also keeps early CI noise manageable while developers learn the semantics of each rule. Teams typically reach for allRules: true only after the baseline has been cleaned up.
- Does phpstan/phpstan-strict-rules work with Larastan?
- Yes, it composes cleanly with PHPStan and Larastan because it is just a rule set plugged into the same analysis run. The caveat is version alignment: confirm the Larastan version you use supports PHPStan 2.3+, since Larastan historically lags PHPStan majors. If Larastan is not yet compatible, hold off on strict-rules 2.1.0 rather than mixing incompatible PHPStan versions. The package is orthogonal to Pint and PHP-CS-Fixer, so it belongs in the quality gate, not the formatter.
- Why did my baseline or ignoreErrors entries stop matching after upgrading to strict-rules 2.1.0?
- In 2.1.0 the arithmetic operand rules now name the node types they target in their messages, so ignoreErrors patterns and baseline fingerprints that referenced the old text no longer match. That can surface as unexpected CI noise or as silently stale ignore entries. Regenerate the PHPStan baseline and explicitly audit any ignores that mention arithmetic operands. The same release narrowed loop-variable-overwrite reporting to variables still in use, which is a genuine false-positive reduction and may let you drop some ignores entirely.
- Why does PHPStan now complain that only booleans are allowed in a condition, and how do I fix it?
- The booleansInConditions rule requires a strict boolean in if, elseif, the ternary condition, after a negation, and on both sides of && and ||. Fix violations by making the intent explicit, for example $value !== null, count($items) > 0, or $items !== [] instead of relying on truthiness. A (bool) cast or a bool-returning method also satisfies the rule when that is genuinely what you mean. The related booleansInLoopConditions rule applies the same requirement to while and do while.
- What exactly does the strictFunctionCalls rule check?
- It forces the $strict flag to true on functions that expose one: the third parameter of in_array and array_search, and the second parameter of base64_decode. It also requires the third parameter of array_keys when the search value argument is provided. This prevents loose comparisons such as in_array('1', $ids) matching an integer by accident. Setting the flag explicitly is usually a one-line fix per call site.
- How do I exclude legacy, generated, or vendor code from the strict rules?
- Use excludePaths in phpstan.neon to skip whole directories such as generated clients, migrations, or third-party code, and rely on the baseline for legacy files you cannot fix yet. Targeted ignoreErrors entries with a paths key let you suppress a specific message in a specific file rather than globally. Vendor code is excluded by default, so you rarely need to configure that. Ownership matters here: someone should review these exclusions periodically so they do not become permanent blind spots.
- Is phpstan/phpstan-strict-rules actively maintained, and what are the alternatives?
- It is MIT-licensed, maintained under the PHPStan organization, and community-supported with no commercial SLA, so expect it to track PHPStan releases closely rather than on a fixed schedule. Alternatives include simply raising your PHPStan level and baseline, using third-party opinionated rule sets such as ergebnis/phpstan-rules, or relying on Psalm's stricter defaults. Pint and PHP-CS-Fixer are not substitutes because they handle formatting, not type-level analysis. It is a dev-only dependency, so it never ships to production.
Weaver
How can I help you explore Laravel packages today?