Php Cs Fixer Config Laravel Package

Product Decisions This Supports

• Build vs. buy (buy, and cheaply): This is a thin, opinionated wrapper that replaces a hand-rolled .php-cs-fixer.dist.php you would otherwise maintain in every repo. The decision isn't "should we adopt a framework" — it's "do we spend engineering days curating ~100 PHP-CS-Fixer rules and re-curating them at every upstream release, or do we consume someone else's curation?" The wrapper tracks upstream friendsofphp/php-cs-fixer and kubawerlos/php-cs-fixer-custom-fixers via Renovate and runs an upstream-check workflow, so rule drift is handled for you.
• Portfolio standardization: The strongest use case is an agency or platform team running many REDAXO installations. Two named presets — Config::redaxo5() and Config::redaxo6() — let you standardize style per major version and migrate branch-by-branch rather than in a big-bang reformat. That is a roadmap-shaping lever: it makes the REDAXO 5 → 6 upgrade cheaper to sequence.
• Platform/dependency posture: v3.0.0 requires PHP >= 8.3. Adoption is therefore a de facto signal that your projects are on a supported PHP baseline — useful as a forcing function when you want to justify a PHP upgrade to stakeholders.
• Developer-experience investment: Style enforcement is a low-glamour, high-leverage line item. Automating it converts recurring PR review friction into a one-time CI configuration cost, which is measurable in review cycle time and onboarding ramp.
• Not a runtime decision: This is a --dev dependency with zero production footprint. It should be treated as a reversible, low-blast-radius experiment rather than a governed platform commitment — which is exactly why it can be approved quickly.

When to Consider This Package

Adopt when:

• The codebase is REDAXO (5.x or 6.x) — this is purpose-built for REDAXO conventions, not a generic PHP style guide wearing a REDAXO label.
• You are already on PHP 8.3+ or are willing to get there, and you have (or want) a php-cs-fixer step in CI.
• You want style decisions made once, centrally, instead of re-litigated per repository or per reviewer.
• You are maintaining REDAXO add-ons/packages and want your style to match the core project's, which reduces friction when contributing upstream.
• You want a fast, cheap proof of value: installation is a single Composer line plus a three-line config, and reverting is deleting a dev dependency.

Look elsewhere when:

• Your stack is Laravel or Symfony and not REDAXO. Laravel teams should default to Laravel Pint; generic PHP teams should use PHP-CS-Fixer's own @PER-CS / @PSR-12 sets directly. Adopting a REDAXO-flavored ruleset outside REDAXO buys you nothing and adds an unnecessary dependency. (Worth stating plainly: despite the framing of this evaluation, this package is not a Laravel package.)
• You need per-team or per-domain rule differentiation that conflicts with the presets. Extensibility exists, but the moment you override heavily you have re-acquired the maintenance burden you were buying your way out of.
• Governance requires vendor assurance. 10 stars, 0 dependents, and a single named maintainer (gharlan) mean there is no external validation and a bus factor of one. If your procurement or security process requires SCA provenance, active maintainer counts, or an SLA, this will not clear the bar.
• Data-quality caveat, verify before committing: the advertised last release date (2026-10-06) is in the future and is inconsistent with the changelog, which tops out at 3.0.0. Treat release metadata as unreliable and confirm the actual latest tag and PHP-CS-Fixer compatibility before you write it into a standard.
• You are on PHP < 8.3 and not planning to move; pin to the 2.x line or skip.

Mitigation if you adopt anyway: lock the php-cs-fixer version (the project itself does this), and note that the entire value proposition lives in one small config class — forking it into an internal package is a few hours of work, not a migration. That caps the abandonment risk at "annoying," not "blocking."

How to Pitch It (Stakeholders)

Executives: "This is a low-cost, easily reversed developer-productivity decision, not a platform bet. It standardizes PHP code formatting across our REDAXO projects with a one-line install and automated CI enforcement, which means fewer review cycles spent on style, faster onboarding of new engineers, and less accumulated formatting debt. It carries no production dependency and no runtime risk — if it stops being maintained, we fork a small config file and move on. The main thing we're buying is engineering hours back."

Engineering: "Drop-in PHP-CS-Fixer preset maintained by a REDAXO core contributor. composer require --dev redaxo/php-cs-fixer-config, point your Finder at it, return Config::redaxo6(), done. Rules are kept current by Renovate and an upstream-check workflow, and parallel execution is enabled, so it's fast in CI. It requires PHP 8.3+ on the 3.x line. Be aware of two things: it's a single-maintainer project with essentially no downstream adoption, and the published release dates look wrong — validate the tag you pin. If it goes stale, the whole ruleset is one class; we own a fork in an afternoon."