Coding Standards Laravel Package

Technical Evaluation

Architecture fit. This is a dev-only Composer tooling package, not a library: it ships two artifacts — a PHP-CS-Fixer ruleset template and an .editorconfig template — plus a Symfony Console binary (typo3-coding-standards / t3-cs) that scaffolds them. It has no runtime footprint, no service dependency, and no framework coupling at execution time. That means it installs cleanly into a Laravel app, but it was not designed for one: the generated .php-cs-fixer.dist.php for project type scans src/, whereas a Laravel app keeps PHP almost entirely in app/, routes/, database/, config/, and tests/. The auto-detection of "project vs. extension" is TYPO3-shaped and will not detect a Laravel layout correctly. Expect to hand-edit the generated config regardless.

Integration feasibility. High for install, moderate for useful adoption. composer require --dev typo3/coding-standards is a one-line change and PHP 8.x / PHP-CS-Fixer 3 are satisfied by any current Laravel stack. The real integration work is not installing the package — it is reconciling it with Laravel Pint, which is itself a PHP-CS-Fixer wrapper and ships its own pinned fixer version. Running both means two fixers with overlapping scope and potentially two friendsofphp/php-cs-fixer versions in the dependency graph. That is the decision point: this package is either a source of rules to port into pint.json, or a replacement for Pint, not both.

Technical risk.

• Maintainership and cadence. 67 stars, 0 dependents, effectively single-maintainer with community PRs. The README explicitly states the package "is not meant to be updated regularly," and the changelog shows the automated core-sync workflow was disabled (v0.5.3). Rule changes are made in TYPO3 Core first, then manually ported. We are adopting a rule set whose upstream evolution is on someone else's discretionary schedule.
• Silent rule drift. Rules arrive via composer update typo3/coding-standards, which changes behavior on a patch/minor bump. An untracked dependency update can produce a mass-reformat diff.
• Destructive scaffolding. setup --force and update overwrite .editorconfig and reset it to TYPO3 defaults, discarding local customization.
• Major-version coupling. v0.4.0 was gated on PHP-CS-Fixer 3.0; future fixer majors will gate this package, which gates our CI image.
• Opinionated deltas. The rules include TYPO3-specific taste (no leading slashes in use, no trailing comma in single-line arrays, no yoda conditions). These are policy choices our team has to consciously accept, not neutral PSR-12.

Key questions for the requesting engineer. (1) Is Pint already enforced anywhere? If yes, why is this package being proposed — what gap does Pint not cover? (2) Do we want to adopt the rule set or harvest it? (3) Which repos are in scope, and is there a shared config repo or is each repo self-scaffolding? (4) Who owns re-syncing on TYPO3 Core changes, and on what cadence? (5) Are we willing to accept TYPO3's opinionated rules verbatim, or is this a starting point for a house standard?

Integration Approach

Stack fit. Composer 2, PHP 8.1+, PHP-CS-Fixer 3.x — all satisfied by Laravel 9/10/11. The friction is entirely at the configuration layer, not the platform layer.

Recommended path — harvest, don't adopt. Extract the PHP-CS-Fixer rule array from the package's template into a pint.json, drop the package from composer.json once harvested, and keep the dependency graph clean. This gets the TYPO3 rule set (which is a genuinely well-curated, PSR-12-aligned superset refined since 2015) without inheriting maintenance, the destructive scaffolder, or the Pint collision. If the team later wants the .editorconfig, run t3-cs s --rule-set=editorconfig once as a one-shot and then own the file.

Alternative path — full adoption. Only justified if we are also standardizing on PHP-CS-Fixer directly and retiring Pint. In that case: composer exec t3-cs s project, hand-edit the finder block to Laravel paths (app, config, database, routes, tests), commit the generated config, and pin the package to an exact version.

Compatibility constraints. Do not run Pint and PHP-CS-Fixer as blocking gates in the same repo — they will fight over the same files and produce a ping-pong of revert PRs. Pick one. Also verify the friendsofphp/php-cs-fixer version resolved by this package against the version Pint bundles before any side-by-side evaluation.

Sequencing.

1. Week 1 — evaluate on one service. Install as dev dependency in a single non-critical repo. Run php-cs-fixer fix --dry-run --diff and count offending files and rule hits. This is the cost estimate for the whole program.
2. Week 2 — decide adopt vs. harvest based on that diff volume and on the Pint question above.
3. Week 3 — land .editorconfig separately. Lowest-risk artifact, immediate team value, no code churn. Treat it as a standalone win independent of the fixer decision.
4. Week 4 — CI in warn mode. Add the fixer as a non-blocking CI step; publish the violation count trend.
5. Week 5+ — flip to blocking, but only after a single formatting-only commit lands during a quiet window, with branches rebased first.
6. Ongoing — quarterly re-sync, with the package version pinned and bumps treated as reviewable changes, not routine composer update.

Operational Impact

Maintenance. Dev-only means no runtime patch obligation, no CVE surface in production, and no deployment coupling — the whole thing can be removed by one composer remove. The ongoing cost is rule-file ownership: if we adopt rather than harvest, someone must periodically diff our ruleset against TYPO3 Core and decide whether to absorb changes. Budget roughly one engineer-day per quarter, plus a review cycle for each resulting reformat.

Support. MIT, no vendor, no SLA. With 0 dependents and 67 stars, we are effectively the support organization for our own usage. This is acceptable for a formatter and unacceptable if the team starts treating the ruleset as a governance artifact with expectations of responsiveness.

Scaling. The tool itself scales trivially — it is static and stateless. The organizational scaling is the problem: with N repos, N scaffolds drift. Mitigate with a shared template repo (or a single pint.json published internally) so the rule set has exactly one source of truth and repos consume it rather than each running the scaffolder.

Failure modes to instrument for.

• Mass-reformat event: an unpinned composer update changes a rule and produces a thousand-file diff, destroying git blame and invalidating open branches. Mitigation: pin exact version, run the fixer in --dry-run in CI on every dependency-update PR.
• Config clobber: update or setup --force resets .editorconfig and silently drops team customizations. Mitigation: commit .editorconfig before any update; prohibit --force in scripts.
• Pint collision: two fixers, contradictory output, engineers disabling both. Mitigation: single-fixer policy enforced by CI.
• Path misconfiguration: the default src/ finder on a Laravel app means the fixer scans nothing and the gate passes vacuously — a false green. Mitigation: assert a nonzero file count in the CI step.
• Bus factor: upstream sync stalls (already evidenced by the disabled daily sync). Mitigation: harvest path removes the dependency entirely; adopt path requires us to accept we may need to fork.

Ramp-up. Technically trivial — half a day for one engineer to install, scaffold, and produce a violation report. The actual cost is social: getting the team to agree on opinionated rules (no yoda conditions, no trailing commas in single-line arrays, no leading slashes in use). That conversation, not the tooling, is the schedule risk. Recommend framing the rollout as "here is the diff volume and here are the five rules we'd be adopting" rather than "here is a TYPO3 package."