Phpstan Rules Laravel Package

Product Decisions This Supports

• Enforce Clean Architecture & Best Practices: Aligns with roadmap goals to standardize code quality, reduce technical debt, and enforce consistent patterns (e.g., namespace conventions, dependency injection, and naming rules). Reduces friction for onboarding new engineers by automating checks for Symfony/Doctrine/PHPUnit conventions.
• Shift Left on Quality: Integrates static analysis into CI/CD pipelines to catch issues early, reducing runtime bugs and manual code reviews. Supports a "build vs. buy" decision by avoiding custom rule development.
• Symfony/Doctrine Modernization: Enables stricter validation for legacy codebases migrating to Symfony 6+/Doctrine 3+, ensuring compliance with modern frameworks (e.g., attribute-based routing, constructor injection).
• Test Quality Improvements: Reduces flaky tests by enforcing rules like NoTestMocksRule, improving test reliability and maintainability.
• Developer Experience (DX): Automates tedious manual reviews (e.g., ForbiddenNewArgumentRule, NoDynamicNameRule), freeing engineers to focus on feature development.

When to Consider This Package

• Adopt if:

  • Your team uses Symfony, Doctrine, or PHPUnit and wants to enforce framework-specific best practices.
  • You’re maintaining a large codebase (legacy or modern) and need scalable static analysis.
  • Your roadmap includes clean architecture (e.g., DDD, hexagonal) or migration to Symfony 6+/Doctrine 3+.
  • You prioritize reducing ignored PHPStan errors (via MaximumIgnoredErrorCountRule) or enforcing naming/convention consistency.
  • Your CI/CD pipeline lacks strict static analysis (e.g., no PHPStan or custom rules).

• Look elsewhere if:

  • Your stack is non-PHP (e.g., Node.js, Python) or uses Laravel without Symfony/Doctrine.
  • You need performance-critical rules (this package adds overhead; prioritize only essential rules).
  • Your team resists strict conventions (e.g., namespace suffixes, forbidden patterns) due to legacy constraints.
  • You already have a mature custom PHPStan setup with equivalent or stricter rules.
  • Your focus is on runtime behavior (not static analysis; consider Pest or PHPUnit instead).

How to Pitch It (Stakeholders)

For Executives: "This package automates 80+ code quality checks for our Symfony/Doctrine stack, reducing bugs and onboarding time. For example, it enforces proper dependency injection (no new calls), clean architecture (namespace conventions), and test reliability (no mocks). Early adoption could cut manual code reviews by 30% and align with our modern tech stack goals. Low risk—MIT-licensed and maintained by the Symplify team (creators of Rector)."

For Engineering Leaders: *"Symplify’s PHPStan rules let us enforce best practices at scale without writing custom logic. Key wins:

• Symfony/Doctrine: Catches anti-patterns like manual new RepositoryService() or misplaced #[Entity] classes.
• Tests: Eliminates flaky mocks with NoTestMocksRule.
• Conventions: Standardizes naming (e.g., *Command suffixes) and visibility rules.
• CI/CD: Reduces ignored PHPStan errors with hard limits, forcing us to fix issues. Start with 2–3 rules (e.g., ForbiddenNewArgumentRule, NoDynamicNameRule) and expand. Minimal setup—just add to phpstan.neon."*

For Developers: *"This is like a linter for PHPStan—it catches stuff your IDE misses. For example:

• Symfony: Flags controllers without #[Route] names.
• Doctrine: Ensures entities live in App\Entity\.
• Clean Code: Bans array_map with callables (use arrow functions instead).
• Tests: Blocks mocks of complex classes. Run it locally first (phpstan analyse), then add to CI. Start small—pick rules that annoy you most!"*