Coding Standard Laravel Package

Product Decisions This Supports

• Code style standardisation across the PHP estate. Choosing whether to enforce a single machine-checkable style contract (via PHP_CodeSniffer) instead of relying on reviewer taste. This package is a ready-made ruleset, so the decision reduces to "adopt, fork, or write our own phpcs.xml."
• Build vs. buy vs. borrow. The build cost of a bespoke standard is low in effort but high in ongoing governance (rules drift, disagreements, toolchain upgrades). A published ruleset is a cheap starting reference — the real decision is whether to depend on it or snapshot it.
• Review-capacity reallocation. Style enforcement is the classic low-value review comment. Automating it is a measurable lever on PR cycle time and senior-engineer time, and it is one of the few tooling changes you can quantify before/after.
• Onboarding and consistency for new hires and acquired codebases. A documented, executable standard shortens "how do we write PHP here" conversations and gives a defensible answer in code review.
• Legacy-modernisation roadmap sequencing. PHPCS supports baselining and per-directory rulesets, so this enables a progressive adoption path (new code strict, legacy code exempt) rather than a big-bang reformat that would destroy git blame.
• Toolchain consolidation. Whether the org standardises on PHP_CodeSniffer (this package) or PHP-CS-Fixer/Pint. These are different engines with different rule semantics; picking one is a platform decision, not a per-repo one.
• CI cost budgeting. Every added analysis step is CI minutes and developer wait time; the ruleset's breadth directly trades against pipeline latency.
• Not a product-differentiating dependency. This is internal engineering hygiene, not a customer-facing capability. It should be tracked as tooling debt/health, not on the product roadmap.

When to Consider This Package

Consider it when:

• The team already runs PHP_CodeSniffer and wants a curated, opinionated ruleset rather than assembling slevomat/coding-standard + PSR-12 + custom sniffs from scratch.
• You want a fast starting point to fork and vendor internally — copy the rules into your own repo, own the file, and treat upstream as inspiration.
• You need a reference for what a mature PHP shop considers non-negotiable (strict types, trailing commas, import ordering, etc.) to shortcut internal bikeshedding.
• You are evaluating standards for a polyglot/consultancy context and want to compare Keboola's conventions against Doctrine's or Slevomat's before committing.

Look elsewhere when:

• You are a Laravel shop. Laravel's default is Laravel Pint (PHP-CS-Fixer based). Adopting a PHPCS ruleset means running two style engines or replacing Pint — a migration cost with no product payoff. Prefer Pint unless you have a specific PHPCS-only sniff requirement.
• You need ecosystem validation or support. With ~1 star and 0 dependents, this is effectively a public mirror of one company's internal standard. No community, no issue triage SLA, single-maintainer bus factor. Do not make it a load-bearing dependency in a critical repo without pinning and mirroring.
• You need custom framework rules (Laravel/Symfony-specific sniffs) — use slevomat/coding-standard, doctrine/coding-standard, or framework-specific packages instead.
• Governance requires vendor-backed or widely-adopted tooling (security review, procurement, licence scanning with provenance). MIT is friendly, but adoption breadth is not there.
• You only want formatting, not semantic rules. A formatter (Pint/Prettier-style, auto-fix on save) gives most of the benefit at a fraction of the review friction; PHPCS is better for semantic/style linting that must fail CI.
• Your CI budget is tight and you cannot absorb another full-codebase scan; scope to changed files only.

Practical adoption guardrails if you proceed: pin an exact version, vendor the ruleset into your repo, wire phpcbf for auto-fix and phpcs for the gate, add a .git-blame-ignore-revs entry for the one-time reformat commit, and baseline existing violations so the gate applies to new code only.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, MIT-licensed PHP code-style ruleset that lets us enforce formatting and consistency automatically instead of in code review. It's low-cost, low-risk tooling — no customer impact, no runtime dependency, no licence exposure. The realistic value is a small but durable reduction in review time and onboarding friction, plus fewer style-only diffs. Because the package has essentially no external adoption (1 star, 0 dependents) and a single maintainer, I recommend we treat it as a reference ruleset we copy rather than a dependency we install, and only proceed if we've already committed to PHP_CodeSniffer as our engine — if we're a Laravel shop on Pint, the right answer is to skip it.

For engineering leads: The concrete proposal is a 1–2 day spike: vendor the rules, run phpcs in report-only mode across the main repos, and measure violation volume, auto-fixable ratio, and added CI time. Success criteria before any rollout: >80% of violations auto-fixable by phpcbf, CI delta under ~30s on changed-files-only runs, and no rule that contradicts an existing framework convention. If those hold, adopt with a baseline for legacy code and a single reformat commit excluded from git blame.

For the platform/DevEx owner: The strategic decision isn't this package — it's picking one style engine (PHPCS vs. PHP-CS-Fixer/Pint) for the org. This ruleset is a cheap way to pressure-test the PHPCS path. Recommend we decide the engine first, then either fork these rules as our internal standard or discard them with a documented rationale. Either way the artefact we own is an internal phpcs.xml/pint.json, never an unpinned third-party ruleset.