Shift Php Cs Laravel Package

Technical Evaluation

Architecture fit. eduarguz/shift-php-cs is a dev-tooling package, not a runtime library: it ships a PHP-CS-Fixer configuration expressing the Laravel Shift team's recommended code style. That means it has zero production footprint — no service provider, no routes, no migrations, no runtime coupling. It sits in require-dev next to PHPUnit/Pest, PHPStan, and Pint. This is the lowest-risk category of dependency we can adopt, because removal is a one-line composer remove with no data or API migration.

The strategic wrinkle is overlap. Laravel's first-party Pint already ships a Laravel preset and is maintained by the framework team. Adopting this package means either replacing Pint or running a second formatter, and running two opinionated formatters on the same tree produces churn loops. The real value here is the ruleset, not the package — and the ruleset is a static PHP array that can be copied into our own config in minutes.

Integration feasibility. Mechanically trivial: composer require --dev, point the config at our source paths, add a composer cs:fix script, wire a CI step. Half a day for a first spike.

Technical risk.

• Staleness (high): last release 2021-12-07, 11 stars, single maintainer. Any php-cs-fixer major bump since then (deprecated/renamed fixers, stricter type handling) is a probable break, and nobody upstream is obligated to fix it.
• Version-lock (medium): a 2021-era package almost certainly constrains friendsofphp/php-cs-fixer to a 3.x minor that may conflict with what our other tooling needs, and may not declare PHP 8.2/8.3 support.
• Verifiability (medium): the repository could not be resolved during this assessment, so I cannot confirm license, constraint ranges, or whether the config is published as a file or a class. Treat everything above the description as an assumption until someone opens the tarball.
• Supply chain (low): dev-only, never deployed, and the payload is config text — worst case we read it and vendor it.

Key questions for the spike owner.

1. What php-cs-fixer constraint does it declare, and does it install cleanly on PHP 8.2/8.3?
2. Is the ruleset a plain array we can extract, or does it depend on package code at runtime?
3. Which fixers differ from Pint's laravel preset, and are those differences we actually want?
4. Is the license compatible with our policy, and is the maintainer reachable?
5. Does it ship CI or pre-commit glue we would inherit or have to replace?

Integration Approach

Stack fit. Fits any Composer-based Laravel/PHP repo. It belongs in the developer-experience lane alongside static analysis and tests, executed in CI and optionally in a pre-commit hook — never in the deploy artifact.

Migration path. Three viable options, in the order I'd evaluate them:

1. Vendor the ruleset (recommended). Extract the rules array into our own .php-cs-fixer.dist.php or translate it into pint.json. We keep the opinion, drop the dependency, and eliminate the staleness and version-lock risks entirely. Given 11 stars and four years of dormancy, this is almost certainly the right answer.
2. Adopt as a dev dependency if it installs cleanly and someone is willing to pin and bump it. Acceptable for a single-repo, short-horizon need.
3. Reject if the ruleset meaningfully conflicts with Pint, since the marginal style value won't justify a second formatter.

Compatibility checks. Composer 2 resolution against our existing require-dev; php-cs-fixer version unification with any PHPStan/Rector/Psalm toolchain; PHP matrix (8.1–8.3); and a Pint coexistence test.

Sequencing.

1. Spike on one mid-sized repo in a throwaway branch.
2. Run the fixer and diff the result — measure files touched and lines changed. If the churn is large, land formatting as a standalone commit and register it in .git-blame-ignore-revs.
3. Decide vendor-vs-depend, then delete the losing path.
4. Add CI enforcement (--dry-run --diff) only after the tree is clean; otherwise the build goes red for unrelated PRs.
5. Add the pre-commit hook last, once the ruleset is stable.

Operational Impact

Maintenance. Effectively unmaintained upstream — we own it the day we adopt it. Budget roughly half a day per year to bump php-cs-fixer majors and fix renamed or removed fixers. Vendoring collapses this to "edit one array when we want to," which is the honest cost either way.

Support. No vendor SLA, no release cadence, no security response. Escalation path is PHP-CS-Fixer's upstream documentation and our own config. This is acceptable for style tooling and unacceptable if anyone proposes extending it beyond style.

Scaling. Negligible. The fixer runs at development and CI time only, with no runtime or data-path involvement. Expect 30–90 seconds added per CI job on a mid-sized repo; cache the fixer cache directory and, in a monorepo, shard by path. Cost scales linearly with changed files, not with traffic.

Failure modes to watch.

• Config silently no-ops because paths are misconfigured — the fixer exits green having changed nothing. Assert on a known-bad fixture in CI.
• A php-cs-fixer bump breaks the config with deprecation errors, blocking all PRs at once. Pin the version and bump deliberately.
• Formatter war with Pint producing alternating diffs in the same files. Pick one owner per path.
• Composer resolution deadlock if the package pins an old fixer that other tooling refuses to unify with.
• Ruleset drift from Laravel's evolving conventions with no upstream to track it — the style slowly becomes idiosyncratic rather than "Shift recommended."

Ramp-up. Near zero: any Laravel developer already knows PHP-CS-Fixer or Pint, and the workflow (fix locally, check in CI) is idiomatic. The documentation burden is one short README section explaining why we chose this ruleset over Pint's default and pointing at the ignore-revs commit — otherwise the next developer will quietly swap it for Pint and generate a large spurious diff.

Verdict. Low technical risk, low operational cost, but low and decaying value given dormancy, tiny adoption, and an unverifiable repository. Approve a one-day spike to extract the ruleset into our own config; do not take a standing dependency on the package itself.