Php Cs Fixer Config Laravel Package

Product Decisions This Supports

• Engineering quality gates / definition of done — whether automated code-style enforcement runs in CI and blocks merges, and what rule set defines "done."
• Build vs. buy (here: build vs. adopt) — this package represents the "adopt an existing config" option for code style. Because it's a dev-only config wrapper around friendsofphp/php-cs-fixer, the real decision is build a small in-repo config vs. depend on someone else's. The evidence pushes hard toward build.
• Onboarding and cross-team consistency — one shared style config means new engineers lint correctly on day one instead of inheriting per-repo snowflakes; relevant for multi-service and monorepo standardization.
• Tech-debt / dependency-risk register — a dev dependency with 0 stars, 0 dependents, and a release history consisting of an original 2017 publish plus a single one-line commit in v1.0.2. Useful as a worked example when writing a vendor-diligence policy: a lone release after a multi-year silence is a pulse, not maintenance — it does not reset the 24-month clock unless accompanied by tests, CI, a supported PHP matrix, or a maintainer commitment.
• DX investment sizing — quantifying that "consistent formatting" is an hours-not-sprint item, which keeps it out of roadmap negotiations and in engineering hygiene.
• Roadmap de-prioritization — no user-facing feature, no revenue path, no adoption. It supports the decision to not spend product capacity here and to delegate to a platform/DX owner with a small budget.

When to Consider This Package

Consider it only in narrow, legacy circumstances:

• You are maintaining a LIN3S-authored PHP codebase and want rule parity with the upstream team's conventions.
• You are pinned to a PHP 7.0/7.1-era stack with php-cs-fixer v2.x, and upgrading the toolchain is genuinely out of scope this quarter.
• You want a structural reference for what a thin shared config package looks like (a single config class plus a Composer constraint) — read it, don't install it.

Look elsewhere when:

• PHP 8.x / php-cs-fixer 3.x — the fixer's config API changed materially since this was published. v1.0.2 dropped the self_accessor rule (a fixer that was renamed to self_static_accessor in the 3.x line), which is a one-rule gesture toward 3.x, not a verified 3.x-compatible config: there is no changelog entry, CI signal, or PHP version-matrix change accompanying it. Treat it as unproven until you test it yourself.
• You're a Laravel shop — Laravel Pint is first-party, zero-config, ships in step with new Laravel releases, and is the obvious default. Adopting a third-party config with an eight-year gap and one follow-up commit instead would be a deliberate downgrade.
• You need broader analysis — PHPStan/Larastan or Psalm for static analysis, Rector for automated upgrade refactors; code style alone is a floor, not a quality strategy.
• You want a community-maintained ruleset — slevomat/coding-standard, symplify/easy-coding-standard, or doctrine/coding-standard all have real user bases and active release cadence.
• Any review requires support expectations, CVE response, or a security sign-off — 0 stars, 0 dependents, and a release history of roughly one commit per eight years means no maintainer on call, no community fallback, and no upgrade path. Note the security blast radius is genuinely small (dev/CI only, never shipped to production), but the maintenance blast radius is not: stale Composer constraints can pin or block your PHP and fixer upgrades.

How to Pitch It (Stakeholders)

Executive summary. This package is not a product dependency — it's a 2017 internal convenience wrapper that stores one company's PHP code-style rules. It has zero adoption (0 GitHub stars, 0 dependent packages). Its entire release history is the original publish plus v1.0.2, a single one-line change that removes the deprecated self_accessor rule. That is the first sign of life in roughly eight years, and it is not maintenance: no changelog, no tests, no CI, no supported PHP matrix, no maintainer commitment. There is no feature value to capture and no user-facing impact either way. The security exposure is minimal because it would only ever run in development and CI, never in production. The real cost is maintenance debt: its constraints can block PHP and php-cs-fixer upgrades, and there is nobody upstream to ask for a fix. Recommendation: do not adopt. The underlying need — consistent formatting across our PHP services — is real and worth solving, but it's a sub-one-day engineering task, not a roadmap item.

For engineering. Take the ruleset as inspiration and vendor it: keep the config in-repo so rule changes go through code review like any other change. If we're on Laravel, use Laravel Pint and stop there — it's first-party and maintained in lockstep with the framework. Otherwise, pin php-cs-fixer to v3, run --dry-run --diff in CI as a required check, and add a pre-commit hook so violations are caught before review. If you read v1.0.2 as a signal that upstream might revive the package, wait for evidence — a supported PHP constraint, a CI badge that actually runs, and a second release within a normal cadence — before treating it as a candidate again. Budget hours, not a sprint. File it under developer-experience hygiene, assign a platform owner, and revisit the ruleset annually rather than treating it as a standing dependency.