Php Cs Fixers Laravel Package

Technical Evaluation

Architecture fit. This is dev-only tooling, not application architecture. It ships PHP-CS-Fixer custom fixers plus preconfigured rule sets, installs via Composer, and belongs in require-dev. It has zero runtime footprint: no service provider, no container bindings, no config publishing, no database, no queue, no HTTP surface. That makes architectural risk near-zero — a bad day with this package produces a red CI lint job or a noisy diff, not an incident. Its actual value proposition is standardization leverage: one opinionated style definition shared across N repositories instead of N drifting .php-cs-fixer.dist.php files.

Integration feasibility. Mechanically simple, structurally uncertain. Wiring it in means composer require --dev wucdbm/php-cs-fixers, then in .php-cs-fixer.dist.php registering its custom fixers (->registerCustomFixers(new ...())) and naming its rule set. The feasibility question is not how but whether it resolves at all:

• PHP-CS-Fixer major-version coupling. Custom fixers implement PHP-CS-Fixer's FixerInterface, and that contract changed between 2.x and 3.x (notably getName() → getDefinition() returning a FixerDefinitionInterface). A last release of June 2020 places this squarely in the 2.x era. If it pins friendsofphp/php-cs-fixer: ^2.x, its fixers will not load against 3.x without a rewrite.
• PHP version wall. PHP-CS-Fixer 2.x does not support PHP 8. If that constraint holds, this package cannot install on a Laravel 10/11 stack (PHP 8.1/8.2/8.3) — Composer will refuse, and there is no workaround short of forking.
• Direct conflict with Laravel Pint. Pint is first-party, maintained, and pins its own PHP-CS-Fixer 3.x. Two dev dependencies crossing fixer majors cannot coexist in one composer install. For most Laravel shops this is the decisive constraint: adopting this package likely means not using Pint.
• Abandonment signal. 3 stars, 0 dependents, one maintainer, no releases in ~5 years. Low scrutiny also means low supply-chain risk (small, MIT, auditable surface), but you should assume you are the de facto maintainer.

Key questions to answer before any decision:

1. What is the exact friendsofphp/php-cs-fixer constraint, and does the package resolve on PHP 8.1+? Prove with composer why-not in a throwaway branch, not by reading the README.
2. Which fixers here are genuinely not available in Pint / stock PHP-CS-Fixer? If the answer is "very few," the package's value collapses to a copyable ruleset.
3. Are the rule sets close enough to PSR-12 / Laravel conventions that adoption is a small diff, or would it trigger a repo-wide reformat?
4. Does the CI lint job run in a Docker image or a shared pipeline where the PHP version is pinned — and can we pin it independently of the app runtime?

Caveat on the supplied material: the accompanying developer assessment describes service providers, config publishing, env()-in-config footguns, and queueing — none of which apply to a static-analysis tool. Treat that as a reminder to validate package-specific facts rather than inheriting generic Laravel-package assumptions.

Integration Approach

Stack fit. Correct layer: require-dev, excluded from production builds by composer install --no-dev, executed in three places — CI lint job, an optional pre-commit hook, and editor save-actions. It touches source files, so the only real integration hazard is uncontrolled mass reformatting.

Three viable paths — evaluate in this order:

1. Port the ruleset into Pint (recommended default for Laravel). Read the package's rule sets, express them as pint.json presets and/or a custom php-cs-fixer config consumed by Pint. You keep the opinionated standard, keep the maintained first-party tool, and eliminate the dependency entirely. Cost: half a day of translation and a diff review.
2. Vendor the ruleset and custom fixers. Copy the fixer classes and rule definitions into a small internal dev-tools package or a tools/php-cs-fixer/ directory. Requires porting fixers from the 2.x to 3.x interface if the package targets PHP-CS-Fixer 2. Cost: hours to a day, and you own ~200 lines of stable code.
3. Adopt the dependency directly. Only sensible if it resolves cleanly on your PHP version, you are not on Pint, and you want the custom fixers verbatim. Pin exactly (0.3.1, not ^0.3.1) given 0.x semver and no maintenance cadence.

Compatibility gate. Run the resolution check first; everything else is wasted effort if it fails:

composer why-not wucdbm/php-cs-fixers 0.3.1
composer show wucdbm/php-cs-fixers --all

Then confirm you can run the fixer binary at the pinned version on your target PHP in CI.

Sequencing:

1. Spike (1 day). Throwaway branch, current PHP, resolve + run the fixer in dry-run mode against the smallest real repo.
2. Quantify churn. php-cs-fixer fix --dry-run --diff and count files/lines. If the number is large, schedule reformatting as standalone work — never mixed with feature work.
3. Decide adopt vs. port. Driven by the answers to the fixer-overlap and PHP compatibility questions above.
4. Pilot on one repo. Add the CI job (fail on --dry-run diff), add a composer fix script, land one reformat commit.
5. Propagate to remaining repos. Each gets the same config and the same CI job.
6. Record an ADR. Which standard, which tool, who owns rule changes, how upgrades are validated.

Reformat hygiene. Land the formatting commit alone, on a quiet day, and add the commit SHA to .git-blame-ignore-revs so git blame stays useful. Announce before, not after.

Operational Impact

Maintenance. Near-zero runtime maintenance, non-trivial ownership maintenance. The abandoned dependency means the practical plan is: vendor or port within the first year, and never let an unattended composer update cross a minor boundary. Budget a few hours per PHP-CS-Fixer major upgrade to re-validate rules and fixer interfaces. The cheapest durable outcome is that the style standard outlives the package.

Support. There is no community: 3 stars and 0 dependents means no issue response, no security process to lean on, and no one else hitting your bugs first. Internal support model should be explicit — the developer-experience/tooling owner answers "why did lint fail," and the rule set is treated as internal policy, not as an upstream artifact you defer to.

Scaling. Effectively free and linear in repository size, not in users or traffic. PHP-CS-Fixer caches results and finishes in seconds to a couple of minutes on mid-size repos. Two scaling notes: in a monorepo, ensure the fixer cache path is scoped per branch/worktree or you will get stale cached verdicts; and in CI, cache the tool's cache directory keyed on the config file hash so rule changes invalidate it.

Failure modes to watch:

• Resolution failure on PHP 8 — install or CI breaks outright. Highest-probability failure; caught at step 1.
• Coexistence failure with Pint — two dev dependencies demanding incompatible PHP-CS-Fixer majors. Surfaces as a confusing composer update conflict; why-not names it.
• Silent rule drift — the package's idea of "consistent style" diverges from team expectation, or a minor bump changes formatting, producing a surprise mass reformat mid-sprint. Mitigate by pinning, reviewing changelogs, and running --dry-run in CI so drift fails loudly on a PR rather than locally.
• Stale CI cache → false green. Lint passes because the cache says so. Key the cache on config hash and PHP-CS-Fixer version.
• Pre-commit bypass. Developers use --no-verify under deadline, drift accumulates. CI is the enforcement point; the hook is only ergonomics.
• Noise in the log. PHP-CS-Fixer 2.x on modern PHP emits deprecation warnings that obscure real output. Another reason to port rather than adopt.
• Explicitly out of scope: the runtime concerns in the generic Laravel checklist — config caching, container resolution, queue retries, database migrations — do not apply here. Don't spend review cycles on them.

Ramp-up. For working developers: minutes. One composer fix habit and a CI failure they will see once. For the owning engineer: roughly half a day to read the rule sets, map them against PSR-12 and Pint equivalents, and write down the deltas. The organization-level ramp-up is the real item — getting N repositories onto one standard requires a short internal announcement, the ADR, and a clear answer to "who do I ask to change a rule."

Bottom line for the roadmap: this is a low-value, low-risk convenience dependency with a material maintenance question mark (2020 release, PHP 8 / PHP-CS-Fixer 3 uncertainty) and a probable conflict with Pint. Treat it as a source of an opinionated style definition to port, not as a dependency to adopt. Do not schedule integration work until the resolution spike answers the PHP-version question; if it fails there, close the evaluation and harvest the rulesets into Pint.