Coding Standards Laravel Package

Product Decisions This Supports

• Build vs. buy (adopt) for code standards. Writing and maintaining an in-house PHP_CodeSniffer ruleset is a recurring tax; this package is a composed, opinionated ruleset (WordPress Coding Standards + modern PHP conventions) you can adopt as a dev dependency instead of authoring one.
• Whether to gate merges on lint. It makes a "block CI on style violations" experiment cheap enough to run as a spike rather than a roadmap item — one afternoon to wire up, then measure.
• Technical-debt investment sizing. Running it once against an existing repo produces a violation baseline, which is the number you need to argue for (or against) a cleanup initiative and to define an incremental-enforcement policy (new/changed files only vs. whole repo).
• Scope boundary between linting and static analysis. This covers style and convention enforcement; it does not replace PHPStan/Psalm. That distinction drives a separate budget line rather than a false expectation that one tool covers code health.
• Use cases to prioritize: WordPress plugin/theme repos, agency multi-client codebases where consistency across handoffs matters, and onboarding checklists for new PHP engineers.

When to Consider This Package

Adopt when:

• The codebase is WordPress-based or WP-adjacent PHP (this is the package's center of gravity).
• You are on PHP 7.4/8.x and can keep Composer dependencies current.
• You want an opinionated, maintained ruleset rather than hand-assembling WPCS + PHPCompatibility + PSR rules and their excludes.
• Your team accepts a third party's conventions as the default and will resolve disagreements by configuration, not by forking.

Look elsewhere when:

• The project is Laravel/Symfony/general PHP — use Laravel Pint, PHP-CS-Fixer, or Slevomat Coding Standard; the WordPress-specific sniffs are noise here.
• Autofix-first developer experience is the priority (Pint/php-cs-fixer are stronger there).
• You need type-level correctness or bug-finding — that is PHPStan/Psalm territory, and treating this package as a substitute is a misread of what it does.
• You are on legacy PHP or need vendor support/SLAs. At ~161 stars this is a single-vendor ruleset with a small contributor base; budget for version pinning and periodic upgrade churn when upstream WPCS/PHPCS ship breaking changes.

How to Pitch It (Stakeholders)

To executives: A low-cost, low-risk way to raise code consistency and cut review cycle time. Adoption is a dev dependency plus a CI step — reversible in a day if it doesn't pay off. The real output is a measurable baseline of convention violations you can trend quarter over quarter.

To engineering: One Composer dev dependency that wires up phpcs with a maintained WordPress + modern-PHP ruleset and sane defaults. Expect roughly a day to integrate and triage the baseline, then enforce incrementally on changed files so the team isn't blocked by legacy debt.

Set expectations honestly: this is a lint/convention layer, not a security or type-safety guarantee. It requires a suppression strategy for the baseline, a pinned version, and scheduled upgrade work when upstream standards change. Given the small maintainer base, treat it as a well-chosen default rather than a long-term platform commitment — and keep the config in-repo so swapping the ruleset later is a contained change.