- How do I install sidz/phpstan-rules in a Laravel project?
- Run composer require --dev sidz/phpstan-rules. If you use phpstan/extension-installer, the rules register automatically; otherwise add the line vendor/sidz/phpstan-rules/rules.neon under includes in your phpstan.neon. It is a dev-only dependency, so nothing changes at application runtime. Then run your usual PHPStan or Larastan analysis command.
- Does sidz/phpstan-rules work alongside Larastan?
- Yes. These are ordinary PHPStan rules loaded through phpstan.neon, so Larastan's extension and this ruleset coexist in the same configuration file. Include Larastan first, then the sidz rules, and keep the parameters block at the top level. With phpstan/extension-installer both packages register without any manual includes.
- How do I ignore extra magic numbers like 100 or 255?
- Use the sidzIgnoreMagicNumbers parameter in phpstan.neon. Each rule ignores 0 and 1 by default, and you can whitelist more with a list such as [0, 1, 100, 255]. The setting applies to every rule in the package, so tune it once instead of per rule. Keep the list small, otherwise you lose most of the benefit of the analysis.
- How do I disable just one rule, for example the comparison operator rule?
- Use PHPStan's built-in ignoreErrors parameter with the exact message the rule emits. For NoMagicNumberInComparisonOperatorRule, add '#^Do not use magic number in comparison operations\. Move to constant with a suitable name\.$#' to ignoreErrors. You can attach a path key to that entry if you only want to silence it in one folder. All the other magic number rules stay active.
- Which rules does sidz/phpstan-rules provide?
- The package ships rules for magic numbers used in comparison operators, passed as function arguments, assigned to properties, and used in arithmetic operators. Each rule raises its own distinct message, which is why you can suppress them individually. Check the README rule list for the exact class names and message texts before writing ignore patterns.
- Does sidz/phpstan-rules support PHP 8.6, and which PHPStan version do I need?
- Release 0.5.3 adds PHP 8.6 support, an additive change that widens the supported runtime matrix without altering rule behaviour. Real compatibility depends on the PHPStan major version you run, so check the composer.json constraint before bumping either one. Projects on PHP 8.2 to 8.5 see no behavioural difference from that release.
- Will adding these rules flood my CI with existing violations?
- Very likely on first adoption, because strict magic number rules surface a backlog of pre-existing code. Generate a PHPStan baseline and commit it before enabling the rules so CI stays green while you fix violations incrementally. Only re-baseline after confirming the current run is clean, otherwise genuine regressions get masked.
- How do I exclude tests, fixtures or a folder from all the rules?
- Add an ignoreErrors entry with a message matching every rule in the package, for example '#Do not (use|return|assign) magic number (.)#', and list the paths such as src/DataFixtures/* and tests/*. One entry with a paths key covers multiple directories, while the singular path key targets a single location. Excluding tests and fixtures first is the quickest way to reduce noise.
- What does the sidzIgnoreNumericStrings parameter do?
- By default the rules also flag numeric strings such as '12' in comparisons, arguments, assignments and arithmetic. Setting sidzIgnoreNumericStrings to true in your phpstan.neon parameters stops those reports so only real numeric literals are caught. This helps when your code legitimately passes string identifiers or config values that look like numbers.
- Is sidz/phpstan-rules safe in production and how is it maintained?
- It is a require-dev dependency consumed only by the static analysis stage, so it never loads on a production request and adds no deployment surface. The package is community maintained with no SLA, but removal is trivial: drop the ruleset include and you are back to stock PHPStan. Group it with your other static-analysis dependencies under an automated update policy and review it monthly rather than per release.