Php Cs Fixer Config Laravel Package

Product Decisions This Supports

• Coding-standard governance: package-pinned rules vs. in-repo config. The core decision this artifact informs is whether style rules live in a shared, versioned dependency or in a committed .php-cs-fixer.php in each repo. This package is a single-file "extend and go" config (romanzipp\PhpCsFixerConfig\Config), so it represents the "shared dependency" end of that spectrum.
• Toolchain-version coupling as an adoption cost. Release 3.0.0 is explicitly a PHP-CS-Fixer v3.0 alignment, delivered as a breaking major bump. That is the whole content of the release: it confirms the package's compatibility ceiling is the v3 config API and rule names, and it tells us nothing about v4 readiness. Any adoption decision therefore doubles as a pin on our fixer version — a decision we would rather make deliberately than inherit from a dev dependency.
• Build vs. buy vs. borrow for developer tooling. Weighs a zero-cost third-party ruleset against writing ~40 lines of config ourselves. Here "borrow" is the right framing: it is one maintainer's personal preferences published as MIT, not a product with a support commitment.
• CI gating and formatting enforcement. Adopting any shared ruleset is a prerequisite for making a style check a required status check. The decision to gate merges on style is separable from which ruleset we gate on — this package only answers the second question.
• Onboarding and repo proliferation. A pinned, named ruleset lowers the per-repo setup cost when spinning up new services or splitting a monolith. Relevant to a roadmap that adds repositories faster than it adds platform engineers. Note the counterweight: a dependency pinned to a superseded fixer major version raises that cost again at the next upgrade.
• Dependency-risk budgeting. With 0 dependents, low visibility, a single maintainer, and this 3.0.0 release (2021-08-06) as the most recent, this is a textbook case for a "no new low-signal dev dependencies" policy. Useful as a calibration example when we set adoption thresholds for internal tooling — particularly the rule that a major-version release with a one-line changelog is not evidence of maintenance.
• Fork-and-own vs. depend. If the rule choices are genuinely desirable, the decision is whether to vendor the config into our own standards package rather than depend on an unmaintained upstream. The 3.0.0 notes reinforce this: the maintainer did the v3 migration once and published nothing since, so the next migration is ours either way.

When to Consider This Package

Consider it only when all of the following hold:

• You are already committed to php-cs-fixer 3.x (this package adds nothing to Pint, ECS, or PHP_CodeSniffer workflows, and 3.0.0 does not extend reach to 4.x).
• You specifically want romanzipp's opinionated rule set — PSR-12 plus strict typing, ordered imports, no unused imports, and similar — rather than the upstream @PSR12 / @PhpCsFixer / @Symfony sets, which are maintained and versioned with the tool itself.
• You accept that 3.0.0 is a breaking release relative to 2.x: rule names and the config API moved to the php-cs-fixer v3 shapes, so any existing 2.x pin must be migrated deliberately rather than floated.
• The cost of pinning a bus-factor-one dev dependency is acceptable — i.e., dev-only, no runtime blast radius, and a one-line removal if it breaks.

Look elsewhere when:

• You are on Laravel. Laravel Pint is first-party, wraps php-cs-fixer, ships a laravel preset, and is maintained by the framework team. For any Laravel application this is the default answer, and this package does not compete on maintenance, preset coverage, or ecosystem fit.
• You need a support commitment or a release cadence. The v3 alignment shipped in August 2021 with a one-line changelog and no releases since; no downstream dependents. Nothing here signals an intent to track future fixer majors.
• You are on, or planning to move to, php-cs-fixer 4.x. 3.0.0 targets v3.0 specifically. Expect to validate rule-name compatibility and config-API changes before pinning, and expect none of that work to arrive from upstream.
• You need rules coverage beyond formatting — static analysis, type coverage, architecture rules. Different tools entirely (PHPStan/Larastan, Deptrac).
• Your organization has more than a handful of repos. At that scale you want an internally owned standards package where we control the release train, not a personal config we cannot patch upstream.

Net: unchanged. For a Laravel codebase the recommendation is do not adopt; standardize on Pint, and if specific rules from this config are attractive, copy them into a committed config rather than taking the dependency.

How to Pitch It (Stakeholders)

To executives: This is a developer-only formatting configuration with no runtime footprint in the product. A new major version (3.0.0) has appeared, and it is worth being precise about what it is: a compatibility update for a single major version of the underlying formatting engine, described in one line, and the first such release since August 2021. It does not add capability, support, or a maintenance commitment. Our assessment is that it carries effectively zero strategic upside and a small but non-zero maintenance liability: one maintainer, no release cadence, no downstream dependents, and a hard ceiling on the engine version it supports. We are not recommending adoption. The underlying business need — consistent code style so reviews focus on logic rather than whitespace — is real and worth solving, but we should solve it with Laravel's first-party Pint, which is maintained by the framework team and already standard in the ecosystem. Net cost of the recommended path is near zero and it removes a future migration risk that this release does nothing to retire.

To engineering: Treat this as a reference, not a dependency. It is a thin subclass of PhpCsFixer\Config that returns one maintainer's rule array — genuinely useful as a curated starting point, and MIT-licensed so we can lift the rules verbatim. The 3.0.0 release is the php-cs-fixer v3 migration and nothing more: it confirms the config API and rule names are v3-shaped, and it is breaking against 2.x. That is useful if we were pinned to 2.x, and irrelevant if we are on 4.x — which 3.0.0 says nothing about. We should still not require-dev it: single author, no test matrix, one-line changelog, and it constrains us to the php-cs-fixer 3.x config API. Instead, commit a .php-cs-fixer.php (or adopt Pint's laravel preset) that reproduces the rules we actually want, then make the style check a required CI gate. If we later want a shared standard across repos, we own it in-house and version it ourselves — the v3 bump is exactly the kind of migration we would end up doing in our own repo anyway, so better to own the config from the start.