Php Cs Fixer Config Laravel Package

Technical Evaluation

Architecture fit

This is a developer-tooling package, not an application dependency. It ships a single configuration class (Redaxo\PhpCsFixerConfig\Config) that returns a pre-tuned PhpCsFixer\Config for friendsofphp/php-cs-fixer, with presets for REDAXO 5 and REDAXO 6. For a Laravel codebase it is not an architectural fit: the ruleset encodes REDAXO conventions (element ordering, phpdoc policy, PER-CS 2.0 base, PHPUnit call style), not Laravel's own conventions, and Laravel's sanctioned tool is Pint, which vendors its own php-cs-fixer preset. The realistic value to a Laravel team is twofold: (a) zero, if there is no REDAXO footprint; (b) moderate, as a reference implementation for the "shared org-wide style config as a Composer package" pattern we may want to copy internally.

Integration feasibility

High mechanical effort, low strategic value. The documented path is two lines: composer require --dev redaxo/php-cs-fixer-config and return Config::redaxo5()->setFinder($finder); in .php-cs-fixer.dist.php. Because it is a --dev dependency it never reaches production artifacts, which removes most deployment risk. The friction points are version coupling (the package pins/locks php-cs-fixer — release 2.8.0 explicitly "Lock php-cs-fixer version"), and the v3.0.0 PHP >= 8.3 floor. A Laravel app on PHP 8.1/8.2 with a CI matrix below 8.3 will fail composer install --dev unless --ignore-platform-req is used — an ugly workaround for a style linter.

Technical risk

• Adoption signal is near-zero: 10 stars, 0 dependents. No third-party validation, no ecosystem to lean on for answers.
• Bus factor of one: effectively a single maintainer (dominant committer across releases).
• Metadata integrity: the "last release 2026-10-06" is future-dated and inconsistent with other dates in the release history. Treat release cadence and maintenance status as unverified; do not plan around it.
• Upstream churn is high by design: nearly every release is a Renovate bump of php-cs-fixer or the custom-fixers package, and rule-set changes (deprecated set names, PhpdocLineSpanFixer replacing PhpdocSingleLineVarFixer, single_line_throw disabled then re-tuned) can produce large one-off diff storms.
• Pint collision: running both Pint and this config in the same repo will produce conflicting fixes and a CI loop. Pick one.
• No security surface: dev-only, no runtime code paths, MIT licensed.

Key questions

1. Do we have any REDAXO footprint at all, or is this purely a pattern to emulate?
2. What is our PHP floor across the fleet? If any pipeline runs < 8.3, this cannot be a shared dev dependency.
3. Are we standardizing on Pint or on raw php-cs-fixer? This decision gates everything else.
4. Does Laravel's own style (Pint laravel preset) conflict with the REDAXO/PER-CS ruleset in ways that would require a fork?
5. Who owns rule upgrades and the resulting diff PRs, and what is the accept-able blast radius per upgrade?
6. Is the release metadata trustworthy, or should we vendor/pin a commit hash?

Integration Approach

Stack fit

Poor for Laravel application code. If we adopt anything, it is the pattern: a small internal package (acme/php-cs-fixer-config) exposing Config::laravel() built on Pint's preset plus our house rules. If a REDAXO project exists in the portfolio, this package is the correct and near-zero-effort choice there — Laravel and REDAXO should be governed by separate config packages, not one shared ruleset.

Migration path

1. Do not migrate existing repos wholesale. A full-repo php-cs-fixer fix on a mature Laravel codebase will generate a thousand-file diff that destroys git blame and stalls review.
2. Pilot on a new or small repo: add the dev dependency, create .php-cs-fixer.dist.php, scope the Finder to app/, config/, database/, routes/, tests/, and explicitly exclude bootstrap/cache, storage, vendor, public/build.
3. Run in audit mode first: php-cs-fixer fix --dry-run --diff in CI as non-blocking, publish the diff as a build artifact, measure file churn for one sprint.
4. Then ratchet: enable --using-cache=yes and enforce only on changed files (or an incremental path allowlist), expanding coverage repo by repo.
5. Fork instead of depend if we go beyond the pilot: a fork gives us control over the pinned php-cs-fixer version and lets us drop REDAXO-specific rules.

Compatibility

• Hard requirement: PHP >= 8.3 for the v3 line; pin ^2.x only if we are stuck on 8.1/8.2, which forfeits current rules.
• php-cs-fixer version is coupled by the package; any project needing a different php-cs-fixer major will conflict on composer update.
• Mutually exclusive with Pint in the same repo and same CI job.

Sequencing

Decision on Pint-vs-php-cs-fixer → decide build-vs-buy for an internal config package → pilot one repo non-blocking → publish churn metrics → ratchet to blocking → roll out repo-by-repo. Roughly 2–3 engineer-days for the pilot, plus ongoing review time for upgrade diffs. This should be scoped as a platform/DX chore, not a roadmap item.

Operational Impact

Maintenance

Low absolute cost but non-zero and externally owned. The upstream releases are almost entirely automated dependency bumps, meaning the maintenance burden is diff review, not code. If we adopt as-is we inherit the upstream maintainer's cadence and judgement. If we fork, we own the rules and the php-cs-fixer upgrade treadmill — realistically a few hours per quarter.

Support

No commercial support, no SLA, no vendor. Internal support means reading the source (small) or the upstream php-cs-fixer docs. Documentation is a README of ~15 lines; there is no rule-by-rule rationale, so "why did this reformat my file?" will be answered by whoever owns the config. Budget for one named owner.

Scaling

Scales fine technically — it is a static config, parallel runner is enabled (2.11.0), and cost is CI minutes only. It does not scale organizationally: one shared ruleset across heterogeneous PHP stacks (Laravel + REDAXO + legacy) creates an upgrade blast radius where a single dependency bump reformats every repo at once. Keep rulesets per-stack, with a shared base.

Failure modes

• Version deadlock: package pins php-cs-fixer, blocking a project that needs a newer/older version — resolution is a fork or composer alias.
• PHP floor breach: CI matrix below 8.3 fails at install time, not at lint time — confusing failure for engineers.
• Pint/php-cs-fixer fight: two formatters, oscillating diffs, red CI.
• Diff storm on upgrade: a preset change reformats hundreds of files across many repos simultaneously; mitigate with incremental/changed-files enforcement.
• Upstream abandonment: no dependents and one maintainer means the package could go quiet; because it is dev-only, the blast radius is CI breakage, not production. Acceptable.
• Zero production failure modes — this is the single strongest point in its favour.

Ramp-up

Very low: a mid-level engineer is productive in under an hour. The setup is copy-paste, and the mental model (Finder + Config) is standard php-cs-fixer. The real ramp-up cost is organizational — agreeing on the ruleset, agreeing on Pint-vs-php-cs-fixer, and sequencing adoption to avoid a formatting PR avalanche.

Recommendation for a TPM: Do not adopt for Laravel applications — score 27.9 and 0 dependents reflects that this is a single-org utility with no cross-ecosystem relevance. Do mine it as a template if we decide to build an internal style-config package, and do adopt it as-is for any REDAXO project that appears in the portfolio.