Coding Standard Laravel Package

Product Decisions This Supports

• Build vs. buy for code-quality tooling. This package is the "buy" option for a PHPCS ruleset: MIT-licensed, drop-in, named standard PhpMyAdmin, installable as a dev dependency in one command. The decision it forces is not should we enforce style (settled) but do we adopt someone else's opinionated rulebook or own ours. A PM should frame this as a buy-with-a-fork-escape-hatch decision, not a permanent platform commitment — the ruleset is a few hundred lines and cheap to internalize later.
• Tool-chain consolidation roadmap. The highest-value product decision this surfaces is which tool is the source of truth for code style. Laravel ships Pint (auto-fixing, PHP-CS-Fixer based); this package reports but only partially fixes. Adopting both without a declared authority creates a reformat/re-flag loop. The roadmap item is "one formatter, one static style gate" — this package is a candidate for the gate role only, never the formatter role.
• Feature-vs-tooling prioritization. Adoption is not free: baseline run, override triage, CI wiring, docs, and an ongoing owner. Estimate one sprint to land, a few hours per quarter to maintain, plus unplanned churn whenever upstream bumps Doctrine and new sniffs fire across the codebase. A PM should compare that cost against shipping features — for a greenfield Laravel service already served by Pint, the honest answer is usually "defer."
• Scoping the use cases where it is genuinely the right buy:
  • Teams already on PHPCS with a phpcs.xml.dist who want stricter-than-PSR-12 without authoring sniffs.
  • Repos that contribute to or interoperate with phpMyAdmin and benefit from matching its conventions.
  • Services pursuing audit/compliance evidence of a documented, enforced standard (weak but real support — the gate is demonstrable, the rationale must be written down).
  • Explicitly not for: greenfield Laravel services on Pint, Blade/JS-heavy monorepos, or orgs needing trend dashboards (that's SonarQube/Qodana).
• Governance as a product requirement. A ruleset that changes quarterly with undocumented overrides gets routed around via phpcs:ignore comments and becomes theatre. The PM decision is to treat the standard as a product with a changelog and an owner, with a documented 24-hour path for override requests. No owner, no adoption.
• Sequencing decision that changes the cost by an order of magnitude. Baseline-file adoption (gate green on day one, block only new violations) plus changed-files-only PR enforcement converts a potentially multi-sprint cleanup into a one-sprint change. That is a PM-level call, not an engineering detail — it determines whether the rollout is a background track or a feature freeze.
• Dependency-risk posture. 19 stars, 0 dependents, single-project origin, and a release date (2026-08-13) that is future-dated and therefore useless as a maintenance signal. The roadmap is phpMyAdmin's backlog, not ours. The PM decision is to pin the version, commit the lockfile, and require human review on standard bumps — never auto-merge a coding-standard upgrade, or every open PR turns red at once.

When to Consider This Package

Consider it when most of the following are true:

• The codebase is PHP/Laravel 10–11 and already PHPCS-based, with an existing phpcs.xml.dist and CI step.
• You want a stricter-than-PSR-12 gate without writing sniffs yourself, and you are comfortable inheriting Doctrine's conventions as the base.
• You have someone who will own the standard — review upstream diffs, document every override, and run an override-request path.
• You accept "report, then fix" rather than "run one command and it's clean." Auto-fix coverage is materially lower than Pint's.
• Your override budget is under roughly 20% of sniffs. If you'll disable more than that, you're building your own standard — do it explicitly in your own repo rather than layering on this one.
• You can adopt incrementally: baseline file, new violations only, changed-files-first, soak period.

Look elsewhere when:

• Pint or php-cs-fixer is already your formatter. The formatting need is covered; this becomes a redundant second opinion and a conflict loop waiting to happen. Default answer: defer.
• You want a Laravel-native opinion — laravel-shift/php-coding-standards is maintained for this exact context and should be priced before committing. Benchmarking both on ~20 representative files is a 1–2 day exercise and should gate any decision.
• The codebase is greenfield, or mostly Blade/JS, or the team is 3+ squads and needs a stable, explainable, org-wide standard rather than a phpMyAdmin-tuned one.
• You need dashboards, trend reporting, or defect prevention rather than style consistency. This package credibly solves formatting consistency; it only weakly supports audit evidence and does not prevent defects.
• You require vendor support or a predictable release cadence. There is no support channel; the escalation path is read the XML → read the Doctrine sniff → open an upstream issue → fork.
• You're unwilling to pin the dependency and review upstream bumps. Unpinned, a transitive Doctrine upgrade can add sniffs mid-sprint and break CI on an unrelated PR.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a free, MIT-licensed PHP code-style checker — a ruleset for PHP_CodeSniffer maintained by the phpMyAdmin project, built on top of Doctrine's standard. It cannot affect production: it's a dev-only tool with no runtime footprint, so the technical risk is near zero. The decision it forces is narrower than it looks — it's not "should we have code standards" but "should we borrow someone else's rulebook or write our own." Adoption costs roughly one sprint if we sequence it correctly (turn it on for new code first, not a big-bang cleanup), plus a few hours a quarter to track upstream changes. The real caveats are organizational: the project is small (19 stars, zero downstream dependents), its roadmap serves phpMyAdmin rather than us, and it overlaps with Laravel's built-in formatter, Pint. My recommendation is to spend 1–2 days benchmarking it against Pint and the Laravel-native alternative before committing; if we proceed, we pin the version, assign a named owner, and treat the standard as a product with a changelog. If we don't have an owner, we shouldn't adopt.

For engineering (the short version): It's a PHPCS ruleset named PhpMyAdmin, layered on doctrine/coding-standard. Install as a dev dependency, add <rule ref="PhpMyAdmin"/> to phpcs.xml.dist, run vendor/bin/phpcs --standard=PhpMyAdmin. One engineer can prove it out in under a day.

Three things must be settled before rollout, not during:

1. Pint vs. PHPCS ownership. Pint formats, PHPCS reports. Nominate one authority for formatting and scope phpcs to non-formatting sniffs, or drop one of them. The top support ticket will be "Pint and phpcs disagree" — solve it up front.
2. Baseline, not big-bang. Generate .phpcs-baseline.xml so the gate is green on day one and only new violations block. Enforce on changed files in PRs first, then widen after a two-week soak.
3. Pin and review. ^4.1.0, lockfile committed, Renovate opens the PR, a human reads the sniff diff. Upstream releases here are largely "bump Doctrine," and each one can add sniffs across the whole codebase at once.

Also: exclude resources/views/, storage/, bootstrap/cache/, public/, and generated code; apply a relaxed ruleset to tests/. Expect the most common objection to be "this rule is wrong for Laravel" — hence the documented 24-hour override path, or the gate becomes theatre. And decide the fork trigger now: if upstream diverges from our needs in more than a handful of places, we copy the ruleset into our repo and drop the dependency. Lock-in is lower than it feels.