Coding Standard Laravel Package

Product Decisions This Supports

• Codifying "house style" as executable policy instead of a wiki page. A shared PHP-CS-Fixer config + PHP_CodeSniffer ruleset turns style debates into a CI gate — the decision to standardize becomes a dependency, not a document nobody reads. As of 1.0.0 this is now genuinely consumable as a dependency (Config::create(__DIR__)), not just a config file to copy.
• Build vs. buy for internal standards — now with a real "buy" option. 1.0.0's programmatic config makes adoption a composer require plus one line, rather than a forking exercise. That sharpens the decision: adopt-and-pin (fast, low effort, upstream's opinions), fork-and-own (control, maintenance burden), or assemble from PER-CS 3.0 + slevomat/coding-standard (most work, best fit).
• Toolchain consolidation — with a caveat. It now bundles three tools with a defined division of labour: PHP-CS-Fixer owns formatting (PER-CS 3.0), PHP_CodeSniffer owns structural/semantic/Laravel/convention checks, Rector handles typed rewrites. This is consolidation if you already run these tools; it is toolchain expansion if you currently run only one. Be honest about which case you're in before pitching it as a simplification.
• Scope-of-standardization roadmap. Still the core scheduling decision: new code only, changed lines (diff-based), or repo-wide reformat. 1.0.0 makes the repo-wide option materially bigger for existing adopters — the upgrade path explicitly says "review the (large, mostly mechanical) diff" — and the new rules (global_namespace_import, fixed class member ordering, snake_case test method names, single-quote strings, nowdoc conversions) are individually small but collectively touch nearly every file.
• A deliberate lowering of adoption friction. Line length went from a hard 120 error to 180 warn / 220 error; arrow functions are not forced; php_unit_strict's assertEquals→assertSame rewrite was removed from the fixer and delegated to Rector because the blanket rewrite could break object/array comparisons. These are all "reduce the number of arguments and the blast radius" decisions — evidence the maintainer is optimizing for adoptability, which is exactly what you want from a standard you're considering inheriting.
• CI process governance. The single auto-fix workflow runs Rector + PHP-CS-Fixer + phpcbf and commits fixes back to the branch. This is a real product decision, not a detail: it requires answers on branch protection, bot identity, commit signing, required-review interaction, and whether automated pushes to contributor branches are acceptable in your org.
• Review-time and onboarding investment case. Unchanged and still the strongest argument: eliminating a recurring class of PR comments is measurable (review turnaround, first-PR-to-merge for new hires) for a small, one-time cost.
• Use cases where it genuinely fits: a Laravel team already on PHP 8.4 with no codified standard; a greenfield 8.4 service wanting a sane day-one baseline; or a team writing its own standard that wants a curated, now-documented starting point (including the custom sniff catalogue, previously partly undocumented).

When to Consider This Package

Adopt (or vendor/fork) it when:

• You are already on PHP 8.4. This is now a hard gate, not a preference. 1.0.0 requires PHP ^8.4 and PHP_CodeSniffer ^4.0. If you're on 8.2/8.3 with no upgrade scheduled, this release is not for you — full stop.
• You are willing to run two tools, not one. PHP_CodeSniffer alone is explicitly no longer a complete standard; you must run both (composer cs). Teams that wanted "one formatter, done" should look at Pint instead.
• You accept PHP_CodeSniffer 4.x, which is a major version. If you have custom sniffs of your own, or depend on a ruleset package that hasn't shipped PHPCS 4 support, budget for that work before committing.
• Your team's style preferences are close to the IxDF's — and note the defaults have moved: snake_case test methods (not PHPUnit's usual camelCase), use function imports, enforced member ordering, aggressive PHPDoc cleanup that strips @author/@package/@since. Read the ruleset; a standard you disable rule-by-rule is no longer a standard.
• The cost of a two-week internal standard-setting exercise exceeds the cost of accepting reasonable defaults, and you can absorb the initial reformat commit now rather than later.
• You want it as a template: consume Config::create() and the slimmer ruleset, but keep the ability to fork. That remains the sane path given the maintenance profile.

Look elsewhere when:

• You are not on PHP 8.4. This single fact disqualifies the package for most Laravel estates today.
• You are on Laravel and already using Pint. Still the sharpest conflict, and arguably sharper now: Pint wraps PHP-CS-Fixer, and this package makes PHP-CS-Fixer primary. Layering an org-specific fixer config over Pint's laravel preset gives you two competing sources of truth for the exact same tool. Pick one.
• Your org does not allow CI to push commits to branches. The recommended workflow is auto-commit-and-push. If branch protection, signed-commit policy, or audit requirements block that, you're manually re-implementing the workflow, which is most of the ergonomic benefit gone.
• Maintenance and bus-factor risk is unacceptable. 1.0.0 signals intent to keep semver and stable APIs, which is a genuine improvement over 0.x — but this is still effectively an internal package published publicly, with a single-organization maintainer. A 1.0 tag is a promise, not a governance model. If you need community backing or LTS guarantees, use PSR-12 / PER-CS 3.0 as baseline plus slevomat/coding-standard.
• You have heterogeneous PHP versions or frameworks. This ruleset now hard-encodes PHP 8.4, PHPUnit 10 migration presets, and Laravel conventions. It will fight non-Laravel or pre-8.4 services in the same estate harder than 0.x did.
• Your team is large enough that the standard is the product. Own it internally with named maintainers.

Before pinning: confirm the release cadence is real and that 1.0.0 has had a point release or two of follow-up. A first stable major with a breaking reorganization is the release most likely to have rough edges, and this one changes tool roles, PHP version, and PHPCS major simultaneously.

How to Pitch It (Stakeholders)

To executives: This is cheap developer-productivity infrastructure, not a product dependency. It encodes "how our PHP should look" as an automated check so style stops consuming human review time and new engineers stop guessing. The 1.0.0 release is meaningfully better than what we evaluated before: it's now a stable, semver-versioned 1.0, adopts the community PER-CS 3.0 formatting baseline instead of house invention, and made deliberate tradeoffs to reduce churn (softer line limits, no forced arrow functions, no risky test-assertion rewrites). The cost is a one-time reformat and a CI step; the return is less rework and faster reviews. Two constraints to be explicit about: it now requires PHP 8.4, so it's gated on our upgrade schedule, and it requires PHP_CodeSniffer 4.x, so it may force other tooling forward too. Risk stays low because the standard is configuration, not runtime code — it cannot break production — and because we can fork it in-house and own it.

To engineering: Treat it as a curated dependency with an escape hatch, not a permanent commitment. Read the ruleset, delete what we disagree with, wire it into CI as a non-blocking check first, then make it blocking for changed lines. Concretely: replace any hand-rolled PHP-CS-Fixer config with Config::create(__DIR__), keep <rule ref="IxDFCodingStandard"/> in phpcs.xml, and run composer cs (it chains fixer + phpcbf, so local and CI stay identical). Expect a large, mostly mechanical first diff — schedule it, don't spring it. Two hard rules: do not run this alongside Laravel Pint, and do not adopt unless we're on PHP 8.4. Watch the snake_case test-method rule (it diverges from PHPUnit convention) and the global_namespace_import rule (it adds use function lines everywhere). Before enabling the auto-commit workflow, get security/DevOps sign-off on bot commits to contributor branches. Success looks like: zero style comments in code review, and a .php-cs-fixer.php nobody has to argue about.