Php Cs Fixer Config Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin configuration wrapper: it ships a PHP-CS-Fixer Config subclass plus a curated rules array targeting Laravel conventions (PSR-2 lineage plus Laravel-specific rules such as ordered imports, unary operator spacing, concat spacing, blank-line grouping).
• It is a dev-only, build-time dependency. It has no runtime footprint, no service provider, no facade, no config publishing, no migrations. It cannot affect production request paths, autoloading, or container bindings.
• Fit for a Laravel codebase is therefore architecturally trivial — but the value is entirely contained in a rules array that a team could copy into its own .php-cs-fixer.php in under an hour. The dependency boundary adds nothing functional.

Integration feasibility

• Mechanically easy: composer require --dev arubacao/php-cs-fixer-config, reference its Config class, add a CI step. Low effort, low blast radius, reversible in one commit.
• The blocker is version archaeology. Last release 2019-09-19 targets PHP-CS-Fixer 2.x, which predates the 3.x line (config file rename .php_cs → .php-cs-fixer.php, large rule renames, @PSR12/@PhpCsFixer rulesets, PHP 8 requirement). PHP-CS-Fixer 2.x does not run reliably on PHP 8.1+, and many of its rules do not understand PHP 8 syntax (attributes, enums, readonly, first-class callables, promoted constructor properties). Adopting this package on a modern Laravel stack means either pinning a dead toolchain or fighting constant composer constraints.
• Superseded by Laravel Pint. Pint is first-party, ships with Laravel 9+, wraps PHP-CS-Fixer 3.x, and encodes the same Laravel preset. For plain PHP, @PhpCsFixer + @PSR12 plus a handful of overrides covers the gap. There is no capability this package provides that is not now available from maintained sources.

Technical risk

• Archived + abandoned package in the dependency graph. Composer 2.2+ surfaces "Package is abandoned" warnings and composer audit --abandoned=report (or --strict) will fail CI. That is a recurring, low-severity but permanent tax on every build.
• Correctness risk is real, not theoretical. A stale fixer rule applied to modern syntax can silently rewrite code incorrectly, not just fail. Any mass --fix run against a mature codebase with an unmaintained ruleset is a code-integrity risk.
• No safety net. 7 stars, 0 dependents, no maintainer, no issue triage. There is no one to patch a rule or cut a release when PHP 8.4/8.5 lands.
• Opportunity score of 0.94 should be discounted. With 7 stars and 0 dependents, a high "opportunity" figure is almost certainly a low-adoption/undiscovered-repo heuristic, not a signal of latent quality. Treat it as noise for a decision like this.

Key questions

• Which PHP-CS-Fixer major version does the 2019 release constrain, and does it install cleanly against our PHP and Laravel versions at all? (Expect: no.)
• Does the ruleset differ materially from Laravel Pint's laravel preset or @PhpCsFixer? If the delta is a handful of rules, the dependency is unjustifiable.
• Is our intent standards enforcement (CI gate) or one-time reformatting? The latter is a script, not a package.
• Do we have any legacy Laravel 5/6/7 service still on PHP 7.x where the 2.x toolchain is still viable? That is the only scenario where adoption makes sense.

Integration Approach

Stack fit

• Dev-tooling layer only: require-dev, CI lint job, optional pre-commit hook. Never in require, never in the production image.
• Do not treat this as a library to depend on. Treat it as a reference ruleset to vendor — copy the rules array into a first-party .php-cs-fixer.php committed in-repo, and depend directly on friendsofphp/php-cs-fixer (or laravel/pint) at a supported version. This keeps the intent, drops the abandoned edge in the graph, and restores upgrade control.

Migration path

1. Install PHP-CS-Fixer 3.x (or Pint) directly as a dev dependency; pin it.
2. Extract the package's rules array from the 2019 tag on GitHub (MIT-licensed, so copying with attribution is clean).
3. Translate v2 rule names to v3 equivalents — most are unchanged, a subset renamed, a few removed. Diff against @PhpCsFixer/@PSR12 and keep only the intentional Laravel deltas.
4. Commit the resulting .php-cs-fixer.php or pint.json as first-party config with a comment noting provenance.
5. If a PHP 7.x legacy app genuinely needs the 2.x toolchain, isolate it: separate CI job, separate composer context, no shared tooling image.

Compatibility

• Target PHP-CS-Fixer 3.x on PHP 8.1+. Verify rule-by-rule against our actual syntax surface — attributes, enums, readonly properties, named arguments. Run --dry-run --diff on a representative branch before any write.
• Keep the fixer version pinned and bumped deliberately; treat fixer upgrades as code-affecting changes requiring review.

Sequencing

1. Week 1 — evaluate & decide. Confirm the delta versus Pint; almost certainly conclude "vendor the rules, drop the package." Record the decision.
2. Week 1 — baseline. Stand up the fixer in CI in report-only mode (no writes) across the repo; capture the violation count to size the reformat.
3. Week 2 — reformat. One mechanical, isolated commit (style: prefix, added to .git-blame-ignore-revs) on a quiet branch. Land it fast to minimize rebase pain.
4. Week 2 — enforce. Flip CI to blocking. Scope initial enforcement to changed files if the repo is large and churn is high (--path-mode=intersection against the diff).
5. Week 3+ — developer tooling. Pre-commit hook or editor integration, plus a short standards doc. Then the topic is closed.

Operational Impact

Maintenance

• As a dependency: unbounded, low-grade maintenance debt — abandoned-package warnings, composer constraint drift, no upstream releases. As a vendored ruleset: near zero. The rules array is effectively static; it changes only when the team changes its mind.
• Ongoing cost sits with the fixer itself, not this package: pin the version, review its changelog on upgrade, re-run against the codebase.

Support

• None. No maintainer, no issue response, archived read-only. Any breakage is ours to fix. Acceptable only because the artifact we actually need — a list of rule names — is static and MIT-licensed. Unacceptable if we depend on the package's code paths.

Scaling

• Trivial. Linting cost is linear in file count and parallelizable; PHP-CS-Fixer's cache file (.php-cs-fixer.cache) makes incremental runs cheap. At monorepo scale, run per-package with --path-mode=intersection in CI so PR feedback stays under a minute.
• The only scaling concern is organizational: enforcement across many teams needs a single shared, versioned config — which argues further for a first-party pinned config over an unmaintained external one.

Failure modes

• Silent misformatting — stale rule rewrites modern syntax incorrectly. Mitigation: dry-run diff review, never auto-merge a fix commit without a human skim.
• CI breakage from abandonment warnings — composer audit --strict or --abandoned=fail fails the build. Mitigation: don't take the dependency.
• Upgrade deadlock — project moves to PHP 8.4, fixer constraint can't move. Mitigation: same.
• Diff noise / blame pollution — one large reformat commit obscures history. Mitigation: .git-blame-ignore-revs and an isolated commit.
• Split standards — two apps adopt different configs. Mitigation: one vendored config, shared via an internal composer package or a synced file.

Ramp-up

• Minimal for engineers: formatting is automatic; the only learning is "run the fixer before pushing." Half a day of onboarding friction at most, concentrated in the one-time reformat.
• For whoever owns the config: roughly a day to do the v2→v3 rule translation once, then minutes per quarter. The TPM cost is dominated by the decision write-up, not the implementation.

TPM recommendation Do not integrate the package. Adopt Laravel Pint (Laravel) or @PhpCsFixer + @PSR12 with a small override block (plain PHP), vendoring any genuinely useful rules from this repo's MIT-licensed config with attribution. The functional benefit is identical and available in an afternoon; the dependency buys an archived, zero-dependent, seven-year-stale supply-chain edge in exchange for nothing. Close the evaluation with a documented "vendored, not depended" decision so it isn't re-litigated.