Coding Standard Laravel Package

Technical Evaluation

Architecture fit

• This is not an application package; it is a require-dev PHP_CodeSniffer ruleset. There is no runtime coupling to Laravel, no service provider, no config publish, no migrations. Blast radius in production is effectively zero, which is the single strongest argument for evaluating it at all.
• Note what it actually is: a meta-ruleset aggregating doctrine/coding-standard, slevomat/coding-standard, and squizlabs/php_codesniffer, registered via dealerdirect/phpcodesniffer-composer-installer. Original code surface is small; the dependency surface and thus the behavioral surface is large.
• The repo shows a thin project: README is a title and one line, zero stars, zero dependents. There is no published rationale for which sniffs are enabled beyond the diff history (e.g., 4.0.0 dropped @api from forbidden annotations). We would be adopting someone's personal preferences as an organizational standard without documented intent.

Integration feasibility

• Mechanically trivial: add to require-dev, drop a phpcs.xml referencing the standard, run phpcs/phpcbf in CI or a Composer script.
• The real friction is overlap with Laravel Pint. Pint (PHP-CS-Fixer) is the Laravel-native formatter and is already in most Laravel CI pipelines. Running both produces conflicting auto-fixes and duplicate, differently-worded failures. A TPM decision is required up front: PHPCS as the sole gate, Pint as the sole gate, or a split (Pint for style, PHPCS for structural/semantic sniffs only).
• Doctrine/Slevomat rules are opinionated in ways that collide with idiomatic Laravel: strict typing declarations, alphabetical use ordering, early-exit requirements, forbidden annotations, and requirements around declare(strict_types=1) in every file. Expect meaningful false-positive triage on Eloquent models, facades, magic methods, and Blade-adjacent service classes.

Technical risk

• Concentration risk: single maintainer, no co-maintainers visible across releases, no issues resolved in any recent release. Bus factor of one.
• Adoption risk: 0 stars / 0 dependents / score 26 means we would be the first substantive consumer. No downstream bug reports means unknown edge cases and no community signal that the ruleset is usable at scale.
• Version churn: the release history is almost entirely Renovate bot bumps plus two PHP-minimum raises (8.2, then 8.4) and a PHPCS v4 major bump in 3.0.0. A ruleset that tracks upstream within days is good hygiene upstream but means our CI output can change without our code changing.
• PHPCS v4 maturity: moving to PHPCS 4 changes configuration semantics and sniff behavior; IDE and tooling integrations lag majors.

Key questions to resolve before committing

1. What is the violation count and false-positive rate on a representative Laravel service, run in report-only mode?
2. Does the ruleset overlap or conflict with our existing Pint config, and which one owns style?
3. Which PHP and PHPCS versions does 4.0.0 actually pin, and is PHPCS 4 acceptable to our IDE/CI tooling?
4. Are we willing to own this ruleset (fork, pin, or wrap) if upstream goes quiet?
5. What is the organizational goal — code review load reduction and onboarding consistency — and would extending an existing standard (PSR-12 + selected Slevomat sniffs) achieve it with less dependency risk?

Integration Approach

Stack fit

• Install as require-dev only; never in production autoload. Composer plugin registration means the standard name becomes globally available to PHPCS in that project.
• Configure via a project-owned phpcs.xml that extends the upstream standard rather than consuming it wholesale. This gives us a seam to disable noisy sniffs without forking.
• Wire into three surfaces: CI job (authoritative), local Composer script (composer lint), and IDE inspection (PhpStorm's PHPCS quality tool) so developers see failures before pushing.

Migration path

• Start with report-only, non-blocking in one repository. Collect the violation inventory and classify into: (a) mechanically fixable by phpcbf, (b) legitimately fixable by hand, (c) framework-idiom false positives to be excluded.
• Run phpcbf on the mechanical subset in a single isolated commit — this is the bulk of the value and the cheapest win.
• Move to diff-based enforcement (changed files only) before whole-repo enforcement. This avoids a freeze-the-codebase moment and avoids the "one big reformat commit destroys git blame" problem.
• Decision point after the spike: adopt as-is, adopt-with-overrides, or recommend staying on Pint and porting only the specific semantic sniffs worth having. Given zero adoption upstream, "no" is a defensible, low-cost outcome.

Compatibility

• PHP 8.2 minimum per 2.15.0; 8.4 targeted as of 2.21.0. Fine for Laravel 10/11/12, but verify against whatever PHP version the oldest service in the fleet runs.
• PHPCS 4 support landed in 3.0.0; any project still on PHPCS 3 will need to be aligned before adopting v4 of this standard.
• Pin exactly. Do not accept floating ranges. Renovate-driven upstream means ^4.0 could pull a rule change mid-sprint; treat this dependency like a compiler, not a library.

Sequencing

1. Spike in one low-risk service (0.5–1 engineer-day).
2. Triage report; quantify noise ratio and confirm the Pint-vs-PHPCS ownership decision.
3. Codify the chosen config in a shared CI template / internal base ruleset.
4. Enforce on new and changed code across services.
5. Backfill whole-repo enforcement opportunistically, per service, in a quiet sprint. Only after step 3 does this become a stated standard that new hires are taught.

Operational Impact

Maintenance

• Near-zero runtime maintenance; the cost is dependency currency. Expect to evaluate PHPCS majors, Slevomat minors, and Doctrine majors roughly quarterly. Each bump is a potential surprise CI failure across every consuming repo simultaneously.
• Assume we will need a small internal wrapper (our-coding-standard extending this one) so that a single upstream surprise can be neutralized in one place rather than N repositories.

Support

• No SLA, no observed issue triage, no commercial backing. Internal ownership is mandatory, not optional: name a DRI, and budget for the possibility of vendoring or forking if upstream stalls. The fork cost is genuinely low given the small original surface.
• Onboarding cost is low for engineers with PHPCS experience and moderate for Pint-only teams — two formatters with different mental models is a real source of confusion worth a short internal doc.

Scaling

• Technically scales at the cost of CI minutes only; PHPCS on a large Laravel monorepo is slow, so plan for parallel runs and cached results, and prefer diff-scoped runs in pre-commit hooks over full runs.
• Organizationally, a centrally-pinned standard means one upstream bump breaks every pipeline at once. Mitigate with staged rollout: bump in a canary repo, then propagate.

Failure modes to plan for

• Silent gate change: upstream rule added/changed turns previously green builds red with no code change on our side. Mitigation: exact pinning + Renovate PRs surfaced to the DRI, not auto-merged.
• Fixer conflict: phpcbf and Pint rewriting each other in pre-commit loops. Mitigation: single owner of style, enforced in config.
• False-positive erosion: engineers adding blanket phpcs:ignore to silence framework idioms until the gate is meaningless. Mitigation: maintain a curated, reviewed exclusion list for Laravel patterns.
• Abandonment: upstream stops publishing compatible releases for a future PHP version, blocking a PHP upgrade. Mitigation: fork-ready posture, and treat this as a removable dev dependency if pressure mounts.
• Adoption stall: report-only mode never becomes blocking, so no value is realized. Mitigation: set an explicit deadline to promote the gate or kill the initiative.

Ramp-up estimate

• Spike and triage: 0.5–1 engineer-day.
• Shared config + CI template: 2–3 engineer-days.
• Fleet-wide enforcement with diff-gating: 1–2 sprints for a mid-size Laravel estate, dominated by triage and socializing the change, not by tooling.

TPM bottom line: cheap to trial, cheap to abandon, and low technical risk because it never touches production. The decision is a process-and-ownership decision, not an architecture one. The 26/100 score and zero dependent count argue against mandating it organization-wide on faith; run the report-only spike, and if the noise ratio is poor or the Pint overlap proves messy, porting a handful of Slevomat sniffs into an internally-owned ruleset is the better long-term bet.