Coding Standard Laravel Package

Product Decisions This Supports

• Developer-experience / engineering-enablement roadmap: This is not a product feature; it is a quality lever. Adopting a coding standard is a concrete, low-cost deliverable under a "reduce defect rate / speed up code review" initiative — it gives you something shippable with a measurable outcome (lint findings per PR, review turnaround time) rather than a vague "improve quality" pledge.
• Build vs. buy vs. adopt: The real decision this package informs is whether to publish an internal ruleset at all. vierwd/coding-standard is essentially a company house style (FORWARD MEDIA) extracted into a Composer package. That is a valid pattern — it is how you make standards portable across repos, teams, and CI pipelines — but it is a build decision dressed as a buy. There is no commercial support, no roadmap, no SLA.
• CI/CD gating and PR hygiene: A ruleset like this lets you make style machine-enforced instead of reviewer-enforced. The PM-relevant decision is where it runs (pre-commit hook, PR check, nightly full-repo job) and whether it is a hard gate (blocks merge) or advisory (annotations only). Hard gates on day one against a legacy codebase is a common, avoidable self-inflicted schedule slip; ratcheting gates are the safer product call.
• Onboarding and documentation debt: A published standard is onboarding documentation that cannot drift from reality. This directly supports decisions about time-to-first-PR for new hires and whether conventions live in a wiki (decays) or in tooling (self-enforcing).
• Dependency and supply-chain hygiene decisions: With 0 stars, 0 dependents, and a last release of November 2022, adopting this is a vendored fork decision, not a dependency decision. That has cost implications (ownership, upgrade path, PHP version support) that belong in the same conversation as any other build-vs-buy trade-off.
• Legacy modernization sequencing: If you are migrating a Laravel codebase toward stricter typing and consistency, the standard defines the target state. It supports deciding whether to reformat wholesale (one large, review-hostile PR) or incrementally (changed-files-only linting, which is what most teams actually ship).

When to Consider This Package

Consider it only as a reference implementation or a starting point you intend to own:

• Your team is already standardized on PHP_CodeSniffer and you want a compact, opinionated baseline rather than hand-assembling rules from scratch.
• You are willing to fork and vendor the ruleset into your own repository (or a private Composer package), pin it, and treat it as internal tooling with a named owner.
• You want a worked example of how another agency packaged its conventions — useful input to an RFC for your own standard, even if you never install it.
• Your PHP version floor is conservative and matches what the ruleset was written against; you will verify this before rollout rather than assume it.

Look elsewhere if any of the following are true — and for most teams, several will be:

• You need maintenance. The package has no meaningful community, no recent release, and no visible activity. Undefined PHP 8.2/8.3+ compatibility is a support risk you would be absorbing silently.
• You want a default that already has gravity. For PHP style, the well-trodden paths are PSR-12, slevomat/coding-standard (actively maintained, composable, widely used), doctrine/coding-standard, or — for Laravel specifically — Laravel Pint, which wraps PHP-CS-Fixer and ships with the framework's blessing. Choosing a zero-adoption ruleset over these buys you nothing and costs you community knowledge.
• Your real problem is bug detection, not formatting. A coding standard does not catch type errors, dead code, or deprecations. That is PHPStan/Psalm and Rector territory. Conflating "we adopted a standard" with "we improved code quality" is the most common way this initiative gets quietly abandoned in month three.
• You need to justify the dependency in a review. "Adopt an unmaintained agency house style" is a hard sell to a security or platform team when PSR-12 exists.
• You lack the appetite to own it. Anything with zero dependents and a two-year-old release is your code the moment you install it.

How to Pitch It (Stakeholders)

For executives (30 seconds): We can reduce review friction and onboarding time by making code style a machine-checked convention instead of a matter of reviewer taste. The specific package reviewed here is not something I recommend adopting directly — it is a small, unmaintained, zero-adoption ruleset from another agency, last released in 2022. But it validates a pattern: publish your conventions as a versioned package so every repository and every CI pipeline enforces the same rules. My recommendation is to adopt a maintained, widely used standard (PSR-12 plus Laravel Pint for our Laravel services) and layer our own house rules on top as a thin internal package, with a named owner and a quarterly review. This is a low-single-digit engineering-weeks investment with a clear payback in review time, not a multi-quarter project.

For engineering leadership: Treat the reviewed package as a design reference, not a dependency. It demonstrates a sound approach — conventions as a Composer-installable ruleset consumed by CI — and we should copy the approach while rejecting the artifact: zero dependents and a stale release mean we would inherit maintenance for no benefit. We propose the same architecture built on slevomat/coding-standard (or Laravel Pint where the framework already provides it), pinned in composer.json, run as a changed-files-only advisory check first, then promoted to a blocking PR gate once the baseline is clean. Sequence strictness deliberately; a hard gate against a legacy tree will block delivery and get disabled within a sprint. Pair the standard with a static analysis job (PHPStan) so we can honestly claim quality improvement rather than formatting churn, and track two metrics — lint findings per merged PR and median review time — to prove the investment paid off.

For the engineering team: Adopting this package means we own it. If you want its opinions, fork them into our own ruleset under a license we control, keep the diff small, and document the intent behind each rule so nobody disables it in six months without knowing why it existed.