Coding Standard Laravel Package

Product Decisions This Supports

• Code style as a platform capability (build vs. buy vs. adopt): Provides an already-assembled, opinionated PHP coding-standard preset that a platform/DX team can adopt rather than authoring and maintaining a bespoke php-cs-fixer/Pint ruleset across every repo. The "build" alternative is weeks of config bikeshedding per squad; the "buy" alternative is a commercial linter; this sits in the cheap "adopt/fork" quadrant.
• Standardization roadmap across a polyrepo or monorepo: Informs whether to mandate a single style gate in CI. Relevant use cases: pre-commit hooks, CI lint jobs, editor/IDE presets, legacy-repo migration waves, and new-repo templates ("golden path" scaffolding).
• Developer-experience investment cases: Gives a concrete artifact to attach to metrics like PR review latency, review-comment volume on style nits, time-to-first-PR for new hires, and CI minutes spent on linting. A PM can justify a standardization initiative by tying it to these numbers.
• Tooling consolidation decisions: A dependency-light PHP package with no transitive service dependencies is low-risk to trial; the decision it supports is whether style enforcement lives in the shared preset or in per-repo config, and whether to pin/vendor vs. consume upstream.
• Adoption/risk posture: 16 stars and 0 dependents signal this is a company-origin (Alma Career) standard, not a community standard. That supports a build decision of "pilot internally, vendor the config, keep an exit path" rather than "bet the org on upstream."

When to Consider This Package

Consider it when:

• You run multiple PHP/Laravel repositories and want one enforceable, versioned source of truth for code style.
• You want a low-ceremony starting point: an MIT-licensed preset you can wire into php-cs-fixer or a comparable runner and gate in CI within a day.
• Your team has no dedicated tooling owner and would otherwise re-litigate formatting rules per squad.
• You value a small dependency footprint and predictable, fast lint runs in CI.
• You're comfortable pinning a version and treating the upstream as a reference implementation you may fork.

Look elsewhere when:

• You need a maintained, widely adopted community standard with an SLA or active roadmap — the adoption signals here (low stars, no dependents, single-organization origin) imply bus-factor and support risk.
• Your need is correctness, not cosmetics: this is a style ruleset, so pair it with static analysis (PHPStan/Psalm) and tests rather than expecting defect detection.
• You're not on PHP, or you've already standardized on another preset (e.g., framework-default Pint/PSR-12 configs) — migrating introduces churn and re-formatting diffs with little marginal value.
• You need vendor support, security-response commitments, or license review beyond MIT — MIT is permissive, but governance still needs an owner internally.
• Your repos are highly heterogeneous in style and you can't absorb a large one-time reformat commit.

How to Pitch It (Stakeholders)

For executives: This is a free, permissively licensed (MIT) PHP style preset that can be dropped into our CI in days, not quarters. The business case is reduced review friction and faster onboarding: engineers stop spending cycles on formatting debates and reviewers stop commenting on style. Cost is near zero (no license, no vendor, minimal CI time) and the risk is contained — we pin a version, pilot on one or two repos, and can revert without touching product code. It is not a security or quality guarantee; it complements our testing and static analysis, it does not replace them.

For engineering leadership and staff engineers: Treat it as a pre-built, opinionated ruleset we can adopt, fork, or ignore. It is maintained by Alma Career and open-sourced under MIT, but it is a small project — do not assume upstream responsiveness. Recommend: (1) pin a version and evaluate on a single repo behind CI; (2) run it in report-only mode for a sprint to size the diff before enforcing; (3) decide between consuming upstream vs. vendoring the config into our own internal package so we control the upgrade cadence; (4) pair it with PHPStan/Psalm so "standard-compliant" is never conflated with "correct"; (5) measure the outcome — review latency, style-comment volume, CI minutes — and kill it if the numbers don't move.

For the platform/DX team: This is a candidate dependency for a "golden path" repo template. Success criteria: new repos ship with the gate pre-wired, existing repos migrate on a scheduled wave, and no squad needs to own a ruleset locally. Keep the internal fork seam clean — a thin wrapper package with our pinned config and overrides — so an upstream stall or divergence is a one-day swap, not a migration.