Coding Standards Laravel Package

Product Decisions This Supports

• Build vs. buy on tooling conventions. The package is a maintained, MIT-licensed distillation of TYPO3 Core's PHP-CS-Fixer rule set plus a canonical .editorconfig, shipped as a dev-only Composer dependency with a scaffolding CLI (typo3-coding-standards setup / t3-cs s). Buying this costs one composer require --dev; building an equivalent means owning rule curation, PHP-CS-Fixer upgrades, and editor-config drift forever. For any team that has debated "whose style wins" for more than one sprint, this is a clear buy.
• Scope decision: are we in the TYPO3 business? For a Laravel-first roadmap this is the pivotal question. The package's value is near-zero for a pure Laravel/Symfony codebase and high for teams shipping TYPO3 extensions, maintaining TYPO3 sites, or contributing upstream. It is a cheap signal of ecosystem commitment — relevant if the roadmap includes TYPO3 integrations, extension marketplaces, or agency delivery on TYPO3.
• Developer experience and onboarding as a product metric. The package encodes formatting policy in committed config files rather than in tribal knowledge. That directly moves onboarding time-to-first-merged-PR and review-comment noise — both things a PM can put a number on.
• CI gating and merge hygiene. .php-cs-fixer.dist.php is designed to be committed and invoked from CI (the README points at the project's own GitHub Actions workflow as a template). That's a concrete, low-risk quality gate with a deterministic exit code, and an easy lever for "no style comments in code review."
• Vendor/ecosystem risk assessment. 67 stars and 0 declared dependents reads as low adoption, but the number is misleading: rule sets get copied into consumer repos via the setup command rather than imported as a runtime library, and TYPO3-adjacent tooling rarely declares the dependency. The real risk mitigant is that the output artifacts are plain config files you own and commit — the package is a generator, not a runtime, so exit cost is effectively zero.
• Not a fit for the "static analysis" or "quality platform" line item. This does formatting only. If the roadmap item is "raise code quality," this is one tile in the mosaic, not the mosaic — pair it with PHPStan/Larastan and a test-coverage gate rather than presenting it as a quality solution.

When to Consider This Package

Adopt it when:

• The codebase is a TYPO3 extension or TYPO3 project, or your team regularly contributes to TYPO3 Core — this is the exact rule set Core uses, so PRs stop bouncing on style.
• You want PHP-CS-Fixer configured for you with a documented, opinionated baseline (PSR-1/2/12 plus TYPO3 extras: no leading slashes in use, no trailing comma in single-line arrays, no space before ;, unused-use removal, concatenation spacing, no trailing whitespace on blank lines, no Yoda conditions) instead of hand-assembling rules.
• You need a shared .editorconfig across VS Code / PhpStorm / vim on a mixed-IDE team, and you want it generated rather than argued over.
• You want scaffolding with sane defaults and override points: project vs. extension auto-detection, --target-dir (e.g. Build/), --rule-set=editorconfig|php-cs-fixer for partial adoption, and --force to reset. Partial adoption matters — it lets you pilot .editorconfig first and add the fixer later.
• Your PHP floor is 8.1+ and you're fine pinning to PHP-CS-Fixer 3.x.

Look elsewhere when:

• The codebase is Laravel or plain Symfony. Use Laravel Pint (PHP-CS-Fixer under the hood, Laravel-native defaults, zero config) or a bare friendsofphp/php-cs-fixer config on @PSR12 / @PER-CS. Adopting TYPO3's rule set here imports conventions that will fight your framework and your team, for no benefit.
• You need active rule evolution. The maintainers state plainly that the package "is not meant to be updated regularly" and that rule changes should be pushed to TYPO3 Core; rule sets are synchronized manually. Treat it as a stable artifact, not a living standard.
• You need license-header enforcement. Explicitly not enabled by default due to the namespace/header ordering constraint — plan a custom rule or a separate tool for that.
• You want one tool to cover a polyglot monorepo (JS/TS, SCSS, PHP). This covers PHP plus editor defaults only; the JS linting option was removed early on.
• Governance requires a vendor with SLAs or a broad maintainer bench. Single-maintainer cadence, small contributor pool, no dependents to signal downstream pressure-testing.

How to Pitch It (Stakeholders)

To executives: This is a near-zero-cost, near-zero-risk developer-productivity lever. It's a dev-only, MIT-licensed Composer package that writes two config files — a PHP formatter ruleset and a cross-IDE editor config — so every engineer formats code identically without meetings, and CI can enforce it automatically. There is no runtime dependency, no production footprint, and no lock-in: the files it generates are committed to our repo and remain ours if we ever drop the package, so the exit cost is essentially a git rm. Cost is roughly half a day of one engineer's time plus a few CI minutes per build. The one caveat to state up front: the value is concentrated in TYPO3 work, so this is a scoped bet on that part of the roadmap, not an org-wide standard — pure Laravel services should use Laravel Pint instead.

To engineering: Install with composer require --dev typo3/coding-standards, then run composer exec t3-cs s (or setup project / setup extension if auto-detection misfires) to generate .php-cs-fixer.dist.php and .editorconfig. Commit both — that's the recommended path and it's what makes the standard portable across machines and CI. Use --target-dir=Build --rule-set=php-cs-fixer if you want the config out of the repo root, and --rule-set=editorconfig for a low-friction pilot. Wire composer exec php-cs-fixer into CI as a blocking check; use the project's own GitHub Actions workflow as a reference implementation. Treat composer update typo3/coding-standards as a deliberate, reviewed change — the PHP-CS-Fixer ruleset applies immediately on update, while .editorconfig changes require an explicit manual update command which overwrites local edits, so commit before you run it. Pin the version, and expect to override a small number of rules to match our existing conventions rather than retrofitting the whole codebase in one PR — introducing this across a mature repo generates a large first-pass diff, so sequence it as a single dedicated "style-only" commit that reviewers can skip with git blame --ignore-rev, and add it to .git-blame-ignore-revs. Known gaps: no license-header rule by default, TYPO3-flavored rules that conflict with some Laravel idioms, and a maintainer cadence that is intentionally slow — don't expect fast upstream fixes, and budget for owning any customization locally.