Coding Standard Laravel Package

Technical Evaluation

Architecture fit umanit/coding-standard is a PHP_CodeSniffer ruleset package, not application code. It sits in the require-dev layer and influences source via phpcs.xml configuration only — zero runtime footprint, no autoloaded production classes, no Laravel service provider, no config publishing. That makes it architecturally inert and safe to trial, but it also means the "product" is a configuration artifact: the value is entirely in the specific sniffs it enables and how they are versioned.

Integration feasibility High. Adoption is a two-line change: composer require --dev umanit/coding-standard plus a <rule ref="UmanIT"/> entry (name to be confirmed) in the project ruleset. It composes with an existing phpcs.xml and can be scoped to directories, so a Laravel app can enforce it on app/ while excluding database/, generated migrations, and vendor-published config.

Technical risk The dominant risk is provenance, not technology. Zero stars, zero dependents, and a single-agency maintainer (UmanIT) mean no external validation and no observable downstream usage — we would be the first meaningful consumer. Specific hazards:

• Version drift / abandonment. Ruleset packages are typically thin wrappers over slevomat/coding-standard or dealerdirect/phpcodesniffer-composer-installer. If the wrapper pins an old Slevomat or PHPCS major, it will block our own dependency upgrades. This is the most likely failure mode.
• PHPCS 3 vs 4. PHP_CodeSniffer 4.x changes sniff behavior and the installer plugin contract. An unmaintained wrapper may not support it.
• Opinionated defaults. Agency standards often encode house preferences (strict types, final classes, ordering) that will generate thousands of violations in an existing Laravel codebase.
• Silent divergence. If we fork or pin, our standard diverges from upstream with no upgrade path.

Key questions

1. What exactly does the ruleset include, and which upstream standards does it depend on (Slevomat? PSR-12? Generic?)
2. What PHP and PHPCS versions are supported, and what is the release cadence over the last 12 months?
3. Is the license permissive enough to vendor ruleset.xml directly into our repo?
4. How many violations does it produce against our codebase today, per sniff?
5. Does it conflict with Laravel Pint, which most Laravel teams already run?

Integration Approach

Stack fit Natural fit for a Laravel/PHP monorepo or service. PHPCS is the de facto standard for style enforcement and coexists with PHPStan/Larastan (static analysis) and Pint (formatting). Note the overlap: Pint already enforces Laravel's preset. Running both is viable if we assign Pint to formatting and PHPCS to structural/architectural sniffs, but the boundary must be explicit or developers get conflicting autofixes.

Migration path Given near-zero adoption, I would not take a hard dependency. Preferred path: read the package's ruleset.xml, extract the sniffs we actually want, and vendor that into our own phpcs.xml.dist with upstream Slevomat referenced directly. This eliminates the wrapper as a supply-chain and maintenance liability while preserving the intent. Fallback: depend on it, pinned to an exact version, behind a Renovate/Dependabot watch.

Compatibility Verify against our PHP matrix and PHPCS version before committing. Test resolution in a throwaway branch first — a composer update conflict here would touch the lockfile of every service. Confirm the composer installer plugin is allowed (allow-plugins in Composer 2.2+), which is a common silent failure.

Sequencing

1. Spike (1 day). Install in a branch, run phpcs --report=summary across the repo, capture violation counts by sniff.
2. Triage. Classify: auto-fixable (phpcbf), worth fixing manually, or suppress. Decide the final sniff set.
3. Baseline. Land config with legacy directories excluded; CI runs non-blocking (continue-on-error) to establish signal without breaking builds.
4. Enforce on new code. Scope blocking enforcement to changed files (diff-based lint) — the only approach that scales on a mature codebase.
5. Ratchet. Tighten exclusions quarterly as legacy files are touched.

Operational Impact

Maintenance Low effort, non-zero ownership. Someone must own the ruleset, review sniff changes on upgrade, and adjudicate suppressions. If we vendor the ruleset, we own it outright — roughly a few hours per quarter. If we depend on the package, we inherit its release cadence, which given zero activity may be none at all.

Support Effectively none. No community, no issue history to mine. Internal escalation only, and we should plan to self-serve from Slevomat/PHPCS upstream docs. This is acceptable for dev tooling and unacceptable for anything on the runtime path — which this is not.

Scaling Trivially scales. PHPCS is CPU-bound and parallelizable (--parallel); runtime grows with LOC, so a large monorepo should lint changed files in PRs and run the full sweep nightly rather than on every commit.

Failure modes

• Composer resolution conflict blocks a PHP or framework upgrade → highest probability, highest cost.
• Ruleset update introduces new sniffs, breaking CI on untouched code → pin versions, review changelogs.
• False positives from Laravel idioms (facades, magic methods, Eloquent) generate suppression noise that erodes trust in the tool.
• Double-enforcement with Pint produces conflicting autofixes and developer friction.
• Abandonment leaves us pinned to an EOL PHPCS major.

Ramp-up Minimal. Any PHP developer who has used PHPCS is productive in an hour. The real cost is cultural: negotiating the sniff set with the team up front determines whether this becomes a shared standard or a resented gate. Budget a short team review of the proposed rules before enforcement goes blocking.