Getting Started

Install the package via Composer:

composer require --dev sidz/phpstan-rules

Extend your phpstan.neon config by including the ruleset:
```
includes:
  - vendor/sidz/phpstan-rules/rules.neon
```
Run PHPStan for immediate effect:
```
vendor/bin/phpstan analyse src
```
Expect actionable messages for style/architecture violations (e.g., forbidden method calls, inconsistent type hints, or non-PSR-12 naming) without needing custom rule implementations.

Implementation Patterns

Layer-specific enforcement: Enable/disable rule groups per project layer (e.g., disallow doctrine queries in domain layer) by combining with parameters > phpstan.rules overrides.
Gradual adoption: In large codebases, pair with errorMessages to selectively exclude legacy issues while enforcing rules only on new code (via paths + ignore blocks).
CI guardrails: Add a dedicated phpstan.ci.neon layer that strictly enables all rules without ignoring errors—ideal for failing builds when standards regress.
Team coordination: Share rule configurations across repos by publishing your own phpstan-team-rules.neon that extends sidz/phpstan-rules and adds custom project rules.

Rule naming conflicts: This package extends PHPStan—do not override built-in rules unless explicitly documented. Prefer new rule classes (e.g., Sidz\PHPStan\Rules\NoPublicPropertyRule) to avoid confusion.
Cache invalidation: Rules may rely on internal symfony/dependency-injection services—always rm -rf phpstan/cache after upgrading to avoid stale errors.
Opt-in strictness: Some rules (e.g., NoDefaultArgumentsRule) may break BC in libraries. Use ignore in phpstan.neon for vendor code or legacy projects.
Customization hooks: Rules are defined as services—override them by adding your own services: block in phpstan.neon to tweak severity (errorLevel: 2 → warning, 1 → error).
Diagnosis clarity: When debugging, run with --debug to see which rule class triggered an error—this helps triage misfired warnings orfalse positives.