Coding Standard Laravel Package

Product Decisions This Supports

• Build vs. buy for an internal coding standard. Rather than maintaining a home-grown set of PHP_CodeSniffer sniffs, this package offers a pre-assembled, opinionated ruleset under MIT. The PM decision is whether "our style guide" is a product artifact worth owning or a commodity to consume — this package is a concrete "buy/borrow" option to price against the cost of an engineer maintaining custom sniffs. Release 1.3.0 clarifies the model: the package re-copies the Doctrine coding standard into itself (PR #13), so it is best understood as a vendored, curated derivative of an upstream ruleset rather than an independently authored standard. That makes the build-vs-buy question sharper — you are choosing between maintaining your own sniffs, depending on Doctrine/Slevomat directly, or consuming someone else's periodic copy of them.
• Engineering quality roadmap and CI gate strategy. Coding standards sit on the same roadmap line as static analysis (PHPStan/Psalm), formatters (Laravel Pint, PHP-CS-Fixer), and pre-commit hooks. Adopting, forking, or rejecting this package forces an explicit decision about where style enforcement lives (editor, pre-commit, CI, or code review) and how strict the gate is.
• Developer experience and onboarding investment. A shared standard shortens time-to-first-merged-PR for new hires, contractors, and outsourced teams, and reduces review latency spent on formatting nits. This package is a low-cost lever to test whether standardizing style measurably reduces review cycle time.
• AI-assisted development governance. With more generated code entering the repo, a deterministic, machine-checkable style layer becomes a cheap guardrail. A PHPCS ruleset — this one or a fork — is a candidate component of that guardrail, independent of which specific ruleset wins.
• Vendor and dependency posture for dev-only tooling. Because this is a require-dev dependency, the risk calculus differs from runtime libraries. The PM decision is whether dev tooling is allowed to be single-maintainer, provided it is pinned, vendored, or forked. 1.3.0 shows the maintainer is still active, which mildly reduces — but does not eliminate — the bus-factor concern.
• Fork-and-own as an explicit option. MIT licensing makes "adopt the rules, own the maintenance" a legitimate roadmap item. This package can be treated as a reference implementation to seed an internal standard rather than a long-term dependency. The 1.3.0 change is itself a reminder that a fork inherits the re-copy-and-patch maintenance work, not just the rules.
• What it should not drive. With 1 star, 0 dependents, and only a single PR in its most recent release, this is not evidence of ecosystem consensus. It should not be used to justify a company-wide mandate, a security-relevant control, or a claim that "the community standard is X." Those decisions need PSR-12, Slevomat, Laravel Pint, or your own written guide as the reference point.

When to Consider This Package

Consider it when:

• Your team already writes Patchlevel-style PHP/Laravel and you want a batteries-included phpcs ruleset instead of hand-assembling sniffs.
• You are running PHP_CodeSniffer in CI today and want an additional or alternative ruleset to diff against your current configuration — a cheap, time-boxed spike.
• You need a seed for an internal standard and are comfortable forking under MIT and owning it thereafter. The 1.3.0 "re-copy doctrine standard" commit is a working example of how the ruleset is curated — useful raw material if you fork.
• The dependency can be pinned in composer.lock, scoped to require-dev, and kept out of production and release artifacts.
• You are evaluating tooling for a small or internal codebase where a single-maintainer ruleset is an acceptable trade.

Look elsewhere when:

• You are Laravel-first. Laravel Pint (PHP-CS-Fixer based) is the conventional default and is maintained alongside the framework; adding PHPCS on top is usually redundant toolchain weight.
• You want a broadly recognized baseline. PSR-12 plus Slevomat Coding Standard gives you documented, widely adopted rules with active maintenance and community review. If Doctrine's conventions are what you actually want, depend on Doctrine's standard directly and skip the intermediate copy — you get upstream fixes without waiting for a re-sync.
• Maintenance currency matters. 1.3.0 is the first release since June 2023 and contains one pull request from one contributor; it does not demonstrate verified support for newer PHP language features or PHPCS versions. Treat the release as a heartbeat, not a compatibility guarantee — still verify PHP 8.3/8.4 parsing, PHPCS 3.x compatibility, and PSR-4 autoloading in the spike.
• You need supply-chain assurance. Zero dependents means no downstream validation; a single maintainer means bus-factor risk. A single minor release does not change that. If your policy requires maintained dependencies or provenance review, this still likely fails the bar.
• You expect documentation. There is no evidence of a published rule catalog or rationale. Rules you cannot explain are rules your team will disable ad hoc.
• You need framework-agnostic or non-PHP coverage. This is PHP-only and Laravel-adjacent; it does not address frontend, template, or config-file style.

Adoption gate (recommended): a one-day spike that installs the ruleset in a branch, runs it against the current codebase, and produces a diff of violations versus your existing standard. Adopt only if (a) it materially overlaps your intent, (b) it runs on your PHP/PHPCS versions, and (c) someone accepts ownership if upstream goes quiet. Otherwise fork the parts you like or close the ticket. The 1.3.0 release is a reason to re-run the spike if it was previously blocked on staleness — not a reason to skip it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small, MIT-licensed PHP coding-standard ruleset as a possible replacement for hand-maintained style configuration. The cost is near zero and the lock-in is minimal — it is a development-only dependency that can be pinned or forked. A minor release (1.3.0) shipped recently after a long gap, which tells us the maintainer is still present but the project remains small and single-contributor. The strategic value is reduced code-review friction and faster onboarding, not new customer-facing capability. We propose a short, time-boxed evaluation rather than a mandate. Success looks like fewer style-related review comments and a cleaner CI signal; failure costs us roughly a day.

For engineering leads: This is a require-dev PHP_CodeSniffer ruleset — a configuration layer, not runtime code. Integration is a Composer require plus a ruleset.xml include and a CI step. 1.3.0 is a minor feature release whose only change re-copies the Doctrine standard, so the package is effectively a curated snapshot of upstream Doctrine rather than an independent standard — worth factoring into the comparison. The real question is not "is this good?" but "is this closer to our intent than PSR-12 + Slevomat, Doctrine directly, or Laravel Pint?" We want a diff of violations across a representative service before committing. If upstream is dormant, we fork it, keep the rules we agree with, and delete the rest — the license permits that.

Framing the risk honestly: Low blast radius (dev-only, revertible, no production exposure), moderate ownership risk (single maintainer, thin release cadence, rules that lag an upstream copy), and low switching cost (any PHPCS-compatible ruleset can replace it). That combination supports a pilot, not a policy.

The ask: half a day to one day of engineering time to run the comparison spike, plus a named owner for the ruleset if we adopt. Decision to be made on the diff output, not on the package description or the release note.

Metrics to watch post-adoption: style-related PR comments per review, CI lint failure rate and mean time to fix, and time-to-first-merged-PR for new joiners.

Recommendation summary: Treat as a candidate and reference implementation, not a commitment. Default to Laravel Pint for Laravel codebases, PSR-12 + Slevomat for everything else, and Doctrine's own standard where Doctrine conventions are the target. Revisit this package only if the spike shows it encodes conventions you would otherwise have to write yourselves. 1.3.0 keeps it alive as an option; it does not change the default.