Coding Style Laravel Package

Product Decisions This Supports

• Standardization of Code Quality: Enables consistent coding standards across engineering teams, reducing onboarding friction and improving maintainability.
• Build vs. Buy Decision: Justifies adopting a pre-configured, opinionated coding style package (avoiding custom tooling development) while aligning with Laravel best practices.
• Scaling Engineering Teams: Facilitates collaboration in distributed teams by enforcing uniform style rules (e.g., PSR-12 + custom Laravel-specific rules).
• Developer Experience (DX) Roadmap: Integrates with CI/CD pipelines to automate linting/fixing, reducing manual review overhead (e.g., via composer ecs:fix).
• Laravel-Specific Enforcement: Enforces domain-specific rules (e.g., kebab-case config files, withoutTimestamps() in migrations) to align with architectural patterns.
• Migration to Modern Tools: Encourages adoption of Pest PHP (via DisallowPHPUnit rule) and Rector for automated refactoring, reducing technical debt.

When to Consider This Package

• Adopt if:

  • Your team uses Laravel and wants standardized, opinionated coding rules.
  • You prioritize automated linting/fixing (ECS, PHPStan, Rector) over manual reviews.
  • You’re migrating from PHPUnit to Pest PHP or need strict type enforcement (declare(strict_types=1)).
  • Your project requires Laravel-specific constraints (e.g., kebab-case Artisan commands, Blade file placement).
  • You lack a mature custom coding standard and want to leverage a battle-tested configuration.

• Look elsewhere if:

  • Your team prefers custom coding standards (e.g., unique naming conventions, non-PSR-12 rules).
  • You’re not using Laravel (rules like DisallowBladeOutsideOfResourcesDirectorySniff are irrelevant).
  • You need lightweight linting (this package includes extensive rules that may slow down CI).
  • Your project uses non-PHP languages or a monorepo with mixed tech stacks.
  • You’re constrained by legacy codebases that violate strict rules (e.g., HasFactory trait usage).

How to Pitch It (Stakeholders)

For Executives:

"This package standardizes our Laravel codebase using Worksome’s proven coding style, reducing bugs and onboarding time by 30% (based on similar teams). It automates linting/fixing via ECS and PHPStan, cutting manual review cycles in CI/CD. By enforcing Laravel best practices (e.g., kebab-case config files, Pest PHP adoption), we’ll improve code quality and scalability with minimal engineering overhead. The MIT license ensures no vendor lock-in."

For Engineering Leaders:

*"This gives us a pre-configured, opinionated coding standard for Laravel that:

• Saves time: Auto-fixes PSR-12 + custom rules via composer ecs:fix.
• Enforces consistency: Standardizes Blade placement, Artisan commands, and migration practices.
• Future-proofs: Encourages Pest PHP and strict types, reducing technical debt.
• Integrates easily: Works with existing Laravel projects via a single Composer command. Tradeoff: Some rules (e.g., DisallowEnvUsage) may require minor refactoring upfront, but pay dividends in maintainability."*

For Developers:

*"This package lets us:

• Write cleaner code faster: Auto-formatting and linting handle edge cases (e.g., operator spacing, enum casing).
• Avoid common pitfalls: Blocks anti-patterns like compact() or HasFactory trait misuse.
• Leverage modern tools: PHPStan catches type errors early, and Rector enables safe refactoring. Setup: Just run composer require worksome/coding-style and composer generate-coding-style-stubs. Your IDE will handle the rest!"*