Mo4 Coding Standard Laravel Package

Technical Evaluation

What this package actually is: a dev-only Composer package that registers a PHP_CodeSniffer "standard" named MO4. It contains no runtime code — it is a ruleset.xml that composes ~7 custom sniffs with rules pulled from Symfony Coding Standard, Slevomat Coding Standard, PSR-12 and PHPCS core. The custom sniffs are mostly cosmetic/structural (aligned => in arrays, multiline array formatting, @var docblocks, alphabetical use ordering, {$var} interpolation, const spacing, single blank lines).

Architecture fit

• Fits the "lint/static analysis" layer of a Laravel stack, alongside Pint, PHPStan/Larastan, and Rector. It has zero runtime coupling and cannot affect production behavior — the blast radius of adopting or dropping it is limited to CI and developer tooling.
• It is a ruleset, not a checker engine: it inherits PHPCS's architecture, which means it competes for the same job as Laravel Pint (a PHP-CS-Fixer wrapper). The primary architectural decision is not "should we install this" but "who owns formatting — Pint or PHPCS/MO4." Running both without an explicit boundary produces ping-pong diffs and pre-commit hook churn.
• Registration relies on dealerdirect/phpcodesniffer-composer-installer, which mutates PHPCS's global installed_paths. That is a Composer plugin, requiring allow-plugins allowlisting on Composer 2.2+, and it behaves differently in Docker/CI vs. a developer machine. A manual phpcs --config-set installed_paths or a phpcs.xml.dist with explicit <rule ref="vendor/mayflower/..."> paths is more predictable.

Integration feasibility

• Mechanically trivial: composer require --dev mayflower/mo4-coding-standard, then vendor/bin/phpcs --standard=MO4 app/. Most violations are auto-fixable with phpcbf.
• Effort is entirely a function of legacy violation volume, not of integration complexity. A greenfield Laravel service: hours. An existing monolith with hundreds of files: a multi-sprint remediation or a permanently baselined/partial ruleset.
• The order property on AlphabeticalUseStatements (dictionary default vs. string/string-locale/string-case-insensitive) is the one knob most likely to conflict with an existing project convention; it must be pinned explicitly in a project ruleset so behavior doesn't change under you.

Technical risk

• Version coupling is the dominant risk. v11 requires PHPCS 4.0+ and PHP 8.1+. PHPCS 4 is a major with sniff-API breaks; any other PHPCS standard, plugin, or tool in the repo pinned to the 3.x line will not coexist cleanly. It also depends on a minimum Symfony CS and Slevomat CS release, so a single composer update can move three coupled dependencies at once.
• Adoption signal is weak. 17 stars, 0 dependents, single-vendor origin (Mayflower). No commercial SLA, no evidence of broad production usage. Bugfix releases in the changelog are of the "uninitialized string offset", "invalid property case (runtime error with PHPCS 3.8.0+)", "trait use statement sorting" variety — i.e., sniffs can crash on new syntax, and a crashed sniff is a hard CI failure, not a style warning.
• Opinionated cosmetic rules generate organizational friction. Forcing => alignment and multiline array layout conflicts with Pint's defaults. This is a people risk, not a technical one, but it lands on the TPM.
• Lock-in risk is low, which is the good news. The ruleset is a thin composition over upstream standards plus a handful of sniff classes. Worst case, fork the repo or vendor the seven sniffs into the repo — days of work, not quarters.

Key questions

1. Does the team standardize on Pint (PHP-CS-Fixer) already? If yes, is MO4 additive (semantics: unused imports, unnecessary namespaces, ReferenceUsedNamesOnly) or redundant (formatting)? We should not run two formatters.
2. What PHPCS major is pinned across the repo today, and does anything else (IDE inspections, IDE plugins, other standards) require 3.x?
3. Does PhpStorm's CodeSniffer inspection support PHPCS 4.x yet? If not, developers lose in-editor feedback and this becomes CI-only — a measurable adoption tax.
4. Which MO4-specific sniffs do we actually want, and which do we exclude? Default assumption: keep UnnecessaryNamespaceUsage, AlphabeticalUseStatements, PropertyComment; consider excluding ArrayDoubleArrowAlignment and MultiLineArray if Pint owns layout.
5. Is there a named owner for the ruleset and its version bumps, or does it become orphaned tooling?
6. Are we willing to take a dev dependency with ~0 downstream users, and what is the exit plan?

Integration Approach

Stack fit

• Treat MO4 as the standards layer, not the formatting layer: PHPStan/Larastan for type and correctness analysis, Pint for layout, MO4 selectively for the namespace/import/docblock sniffs Pint doesn't cover. If leadership wants a single tool, choose Pint and skip this package — it is not worth a formatting war.
• If MO4 is chosen as the standard of record, disable Pint's conflicting fixers or drop Pint entirely. Do not leave both enabled.

Migration path

1. Add the package as a dev dependency with an exact-ish version constraint (^11.0) and pin PHPCS, Slevomat, Symfony CS, and the composer-installer plugin in composer.lock. Commit the lockfile.
2. Create a project-level phpcs.xml.dist that references MO4, sets the AlphabeticalUseStatements.order property explicitly, and <exclude>s any sniffs that collide with Pint or the team's existing style.
3. Run non-blocking first: vendor/bin/phpcs --standard=phpcs.xml.dist --report=summary app/ in a dedicated CI job, continue-on-error: true, for one sprint. Use --cache and scope to app/, src/, tests/ — never vendor.
4. Enumerate the backlog: phpcs --standard=MO4 -e to list every active sniff, and --report=source to rank violations by sniff. Decide fix vs. baseline per sniff, not per file.
5. Remediate in one of two ways: a single timeboxed phpcbf branch (review it — autofixers on VariableInDoubleQuotedString and ArrayDoubleArrowAlignment can produce large, low-signal diffs), or a diff-aware gate that only enforces on changed lines/files.
6. Flip to blocking once the violation count is at an agreed floor. Keep the floor visible in a dashboard or a checked-in baseline artifact.

Compatibility

• Hard floor: PHP 8.1+, PHPCS 4.0+. Verify the CI base image, local dev containers, and any shared tooling image meet both before scheduling the work.
• Verify phpcs -i lists both MO4 and Symfony after install; the README's troubleshooting note ("MO4 not installed" / installed_paths) is the most common first-day failure and should go in the onboarding doc.
• Confirm IDE support for PHPCS 4 before rollout; if PhpStorm lags, sequence CI-first and editor-second, and accept a temporary developer-experience gap.
• Check whether the repo's Composer allow-plugins policy permits dealerdirect/phpcodesniffer-composer-installer; if not, register the standard path manually.

Sequencing

1. Decision memo: formatter ownership (Pint vs. PHPCS) — this gates everything else.
2. Spike (½–1 day) in a throwaway branch: install, generate violations summary, sanity-check phpcbf diff size.
3. Non-blocking CI job + ruleset pinning; one sprint of observation.
4. Remediation or baseline; publish the exclusion rationale.
5. Blocking gate; add to the PR checklist; add Renovate/Dependabot grouping for the PHPCS/Slevomat/Symfony/MO4 cluster.

Operational Impact

Maintenance

• Low surface area: one dev dependency, one ruleset file, a lockfile. But it is a cohort dependency — MO4, PHPCS, Slevomat CS, Symfony CS, and the Composer installer must move together, and major bumps in any one of them are breaking. Budget one upgrade PR per PHP or PHPCS major, per project.
• Ownership: assign a named owner (typically the platform/DevEx engineer) for the ruleset and its upgrade cadence. Rulesets decay quietly — an unowned one either blocks unrelated PRs or gets silently excluded.
• Supply chain: the composer-installer plugin executes at install time and rewrites PHPCS config. Some orgs will require an exception or a manual installed_paths setup. Decide this up front.

Support

• Community support is thin: small star count, no dependents, vendor-origin project. Expect GitHub-issue latency measured in weeks, not hours. Mitigation: pin versions, and keep a fork-or-vendor escape hatch (the ~7 custom sniffs are small enough to copy into the repo).
• No commercial SLA unless Mayflower is separately engaged.

Scaling

• PHPCS is single-process and slow on large trees; it scales linearly with code volume. Mitigations: --cache (persisted between CI runs), scope to changed directories in PR jobs and run the full scan nightly, and split the run across parallel CI jobs by directory.
• Wall-clock impact on PR feedback is the most likely developer-complaint vector; measure it before and after enabling the blocking gate.

Failure modes to plan for

• Ruleset not registered (installed_paths drift after a cache restore or image rebuild) → silent zero-violation pass. Add a guard step that asserts phpcs -i | grep MO4.
• Sniff crash on new PHP syntax — historically the most common defect class here. A crashed sniff is an error exit, so it fails CI loudly and blocks unrelated PRs. Pin PHP versions in CI and treat PHPCS major/minor bumps as change-managed.
• Formatter conflict with Pint/pre-commit hooks → oscillating diffs and lost developer trust. Resolve by explicit exclusion, not by convention.
• Oversized autofix diff merged without review → merge-conflict cascade across open branches. Schedule phpcbf sweeps deliberately.
• Upgrade breakage window — PHPCS 4.0 availability vs. IDE/plugin support may leave a period where CI enforces but editors don't.

Ramp-up

• Engineer ramp-up is roughly a day (Composer plugin behavior, ruleset.xml syntax, -e/--report=source/--cache flags, phpcbf caution). No PHP framework knowledge required.
• Team ramp-up is the larger cost: developers must learn which auto-fixes are safe to accept wholesale and which produce noisy diffs, plus the rationale for excluded sniffs. One page of docs plus a pinned ruleset with inline comments covers it.
• TPM-level success metrics: PR lint time delta, violation count trend (should trend down and hold), number of ruleset-exclusion requests (a rising count means the standard is misfit for the codebase), and zero "ruleset not found" CI incidents.