Coding Standard Laravel Package

Technical Evaluation

What it is. codeigniter/coding-standard is the official CodeIgniter 4 coding standard, distributed as a Composer dev dependency. It ships a PHP CS Fixer ruleset class plus a default config, so adoption is composer require --dev + a .php-cs-fixer.dist.php that references the ruleset. There is no runtime code path, no service registration, and no production footprint.

Architecture fit. As a dev-time quality tool, architectural risk is deliberately confined to the toolchain: it cannot affect request handling, autoloading in prod, or deployment artifacts if installed with --dev and omitted from composer install --no-dev. The mismatch to flag is framework intent: this ruleset encodes CodeIgniter 4 idioms, not Laravel idioms. For a Laravel-first estate, the canonical answer is laravel/pint (itself a PHP CS Fixer wrapper with a Laravel preset). This package is a fit only if (a) the estate contains CodeIgniter 4 applications, or (b) we are deliberately cherry-picking its PSR-12-aligned rules into a shared baseline. It is not a drop-in Laravel standard.

Integration feasibility. Mechanically high: single dev dependency, one config file, one CI step. Organizationally medium-to-low for Laravel teams, because it competes with Pint for the same job and the same underlying friendsofphp/php-cs-fixer dependency.

Technical risk.

• Version coupling (primary). The ruleset targets specific PHP CS Fixer majors; Pint pins its own. Installing both in one composer.json is a realistic conflict. Blast radius is CI, not production.
• Ruleset drift. Minor releases can change formatting output, producing large diffs on upgrade. Treat ruleset bumps as scheduled maintenance, not silent patch updates.
• Initial diff volume. First run on a mature repo can touch hundreds of files. Needs an isolated formatting-only commit plus .git-blame-ignore-revs.
• Signal quality. 74 stars and 0 dependents means near-zero ecosystem validation; the high aggregate score should be sanity-checked against that, not trusted as a maturity proxy.

Key questions for the team.

1. Do we actually operate CodeIgniter 4 code, or is this being evaluated for a Laravel-only estate?
2. If Laravel-only: are we prepared to justify a non-default standard over Pint, and who owns that decision?
3. Which PHP CS Fixer major do we standardize on across all repos, and does that intersect with Pint's pin?
4. Who owns ruleset governance — platform team, or per-repo?
5. What is the acceptable initial-diff size and review window for the pilot repo?
6. Is the release cadence/versioning of the package reliable enough to depend on for a blocking CI gate?

Integration Approach

Stack fit. PHP 8.x + Composer, framework-agnostic at the tooling layer. Correct placement is require-dev, executed in CI and optionally in a pre-commit hook. It replaces ad-hoc php-cs-fixer configs; it does not replace static analysis (PHPStan/Psalm) or tests.

Recommended segmentation.

• Laravel applications → laravel/pint as the default.
• CodeIgniter 4 applications → this package, as intended.
• Shared libraries / cross-framework packages → explicit PSR-12 baseline with a documented, minimal rule allowlist; borrow rules from this package only where they are framework-neutral.
• Do not install this package and Pint in the same composer.json. If both standards must exist in one monorepo, run each in its own tooling image/PHAR rather than resolving fixer versions in a shared lockfile.

Migration path (per repo).

1. Inventory repos by framework and current formatter.
2. Pilot on one low-traffic CodeIgniter 4 repo (or one shared library if cherry-picking rules).
3. Add the dependency pinned to a minor range; commit the generated config.
4. Baseline: vendor/bin/php-cs-fixer fix --dry-run --diff and record file/line counts.
5. Land formatting in a single isolated PR with no logic changes; add the SHA to .git-blame-ignore-revs.
6. Add CI in warn-only mode for one sprint, then flip to blocking.
7. Optional pre-commit hook via CaptainHook; keep it non-blocking for the first iteration.

Compatibility checks before commitment.

• PHP version matrix vs. package and fixer constraints.
• PHP CS Fixer major vs. any existing tooling (Pint, PHPStan extensions, IDE plugins).
• Conflict with existing .editorconfig/.php-cs-fixer.php files.
• Confirm the CI image can run the fixer offline (no network at gate time).

Sequencing. Pilot (1 sprint) → governance note documenting where each standard applies (1–2 days TPM/tech-lead effort) → wave rollout by team → quarterly ruleset review aligned with dependency upgrades. Keep the blocking gate off until the baseline commit is merged everywhere it applies.

Operational Impact

Maintenance. Low ongoing effort: Dependabot/Renovate for the fixer and ruleset, plus a scheduled minor bump per quarter. Real cost is the upgrade review, not the day-to-day. Budget roughly 0.5–1 engineer-day per quarter for a mid-size estate.

Support. Maintained by the CodeIgniter core team under MIT; no commercial SLA. With 74 stars and no listed dependents, the bus factor and community backstop are thin. Acceptable for a dev-only tool where a fallback (plain PHP CS Fixer with a checked-in rule array) exists in an afternoon.

Scaling. Effectively free. Runs are seconds-to-low-minutes per repo; use the .php-cs-fixer.cache file in CI, and shard by directory in monorepos. It scales linearly with repo count and does not interact with runtime capacity.

Failure modes.

• Composer conflict with Pint's fixer pin — breaks installs, not builds of the app.
• CI step silently skipped (path filters, cache, missing --dry-run exit handling) — formatting debt accumulates invisibly.
• Ruleset upgrade produces churn that obscures real diffs in review.
• Developers bypassing pre-commit with --no-verify; the CI gate must be authoritative.
• False confidence: formatting is not correctness. Do not let a green formatter gate substitute for static analysis or tests.
• Framework upgrade in CodeIgniter changing conventions faster than the ruleset tracks them.

Ramp-up. Minimal for developers — a short README note and one command. TPM/tech-lead effort is front-loaded: pilot coordination, the segmentation decision (Pint vs. this package), and the governance doc. Estimate 1–2 days of PM time plus one sprint of engineering attention for the pilot and baseline.

TPM recommendation. Do not adopt this as the primary standard for a Laravel codebase; Pint is the lower-risk default there. Adopt it only for CodeIgniter 4 repos, and treat it as a reference ruleset for shared PHP libraries. The package is technically sound and cheap to operate, but its small ecosystem footprint means the decision should rest on "do we run CodeIgniter 4?" rather than on its score.