Php Coding Standard Laravel Package

Technical Evaluation

What it actually is. webtoolshealth/php-coding-standard is not a runtime library — it is a PHP_CodeSniffer ruleset, i.e. a ruleset.xml (plus a composer.json and probably a README) that composes upstream standards into one opinionated preset. Its only job is to be registered into PHPCS's installed_paths and referenced by <rule ref="WebtoolsHealth"/> in a project's phpcs.xml. Treat it as configuration-as-a-package, not as a dependency with a service contract.

Architecture fit. Good in principle: PHPCS rulesets are the canonical way to share lint policy across a polyrepo of Laravel services, and a require-dev package is the cleanest distribution channel. The fit is poor on timing. The package is archived, its last release was June 2021, it has 1 star and 0 dependents, and an opportunity score of 11.87. That profile means "abandoned artefact from one company's internal toolchain," not "community standard." Any Laravel stack on PHP 8.2+ and PHP_CodeSniffer 3.7+ is running a toolchain roughly four years newer than this ruleset was validated against — and PHPCS 4.x, which is a breaking major, is entirely outside its tested envelope.

Integration feasibility. Mechanically trivial. Three steps: composer require --dev webtoolshealth/php-coding-standard, add the package's src/ (or repo root) to installed_paths, and reference the standard name in phpcs.xml. Realistically 15–30 minutes including a baseline run. The friction is not installation, it is dependency resolution: the package's composer.json will pin a squizlabs/php_codesniffer constraint (likely ^3.5 or ^3.6) and possibly upstream rulesets (slevomat/coding-standard, symfony/...). Those pins were frozen in 2021 and will fight a modern project's composer update, especially if the repo also carries Pint, PHPStan, or Rector with their own PHPCS-adjacent constraints.

Technical risk. Medium-high, concentrated in four areas:

Key questions to answer before any decision. (1) What does the ruleset.xml actually contain — is it 20 hand-written custom sniffs, or a thin <rule ref="SlevomatCodingStandard"/> wrapper with a handful of exclusions? The answer entirely determines whether it is worth adopting. (2) Which PHPCS version constraint does its composer.json declare, and does it resolve on our target PHP/PHPCS pair? (3) Do the bespoke rules encode genuinely valuable house conventions (e.g. Laravel-specific naming, strict-types enforcement) that our team would otherwise have to write? (4) Is the standard PSR-12/PSR-4 aligned, or does it diverge in ways that would force reformatting churn on existing code? (5) Who at WT Health owns it, and is there any informal path to unarchive or fork?

Verdict. Do not adopt as a live Composer dependency. Its value is as source material: read the ruleset.xml, harvest any non-obvious rule choices, and re-express them in a file we own.

Integration Approach

Stack fit. Target environment is a Laravel estate already running PHP_CodeSniffer (directly or via squizlabs/php_codesniffer), almost certainly alongside Laravel Pint. Note the overlap: Pint ships a Laravel preset built on PHP-CS-Fixer, which auto-fixes; PHPCS detects. Running both with divergent rule sets produces contradictory CI signals. Decide up front whether this ruleset supplements Pint (detection of things Pint cannot fix) or replaces it. Given the package's age, supplementing is the only credible posture.

Migration path. Two options, and the second is strongly preferred:

1. Direct dependency — require-dev the package at its 2021 tag, pin PHPCS to the package's declared constraint. Fast, but imports the frozen-transitive-conflict problem and gives us zero maintenance leverage.
2. Vendor the ruleset (recommended) — copy the ruleset.xml into a first-party path (e.g. tools/phpcs/WebtoolsHealth/) or a small internal acme/php-coding-standard package we control. We then own the PHPCS constraint, can regenerate against 3.13/4.x, can delete rules that no longer apply, and keep the standard name in phpcs.xml stable so no project files churn later. Attribution cost is a line in the README; MIT makes this clean.

Compatibility. Assume PHPCS 3.x only until proven otherwise. Before migrating, run composer why-not squizlabs/php_codesniffer "^3.13" in a scratch clone — if it refuses to resolve, decision 2 is forced. Verify the standard loads on the PHP version in production (phpcs -i should list it). Watch for sniffs that reference removed tokens or use T_* constants deprecated between 3.5 and 3.13.

Sequencing.

1. Spike (0.5 day). Clone, run against one representative Laravel service with --report=summary. Capture the rule inventory and the violation count per sniff.
2. Triage. Classify each sniff: keep / rewrite / drop. Expect 60–80% to be duplicating PSR-12 or Laravel conventions already covered by Pint.
3. Fork and pin. Land the internal ruleset package, PHPCS constraint declared by us, CI job added in warn-only mode (|| true, report uploaded as artifact).
4. Baseline. Generate a per-file baseline or restrict enforcement to changed lines so we do not block the team on legacy debt.
5. Ratchet. Promote to blocking after two clean sprints; flip on new repos first, legacy repos last.

Operational Impact

Maintenance. Ownership transfers fully to us the moment we vendor it — which is the correct outcome, because the upstream owner has already stopped. Budget roughly 2–4 engineer-hours per PHPCS major upgrade and 1 hour per quarter of drift review. If we instead take the direct dependency, maintenance cost is not lower; it is deferred and then paid at a worse time, when a PHPCS 4 upgrade collides with a composer resolution wall across every repo at once.

Support. No upstream support, no issue tracker responsiveness, no security patching. This is acceptable for a dev-only linter because the blast radius is CI, not production — no runtime code, no autoloaded classes, no attack surface. That is the single strongest argument in the package's favour: a stale dev dependency is a productivity tax, not an incident.

Scaling. Per-repo require-dev scales linearly and fine for tens of repos. The real scaling cost is CI minutes: PHPCS on a mid-size Laravel app is 30–90 seconds, and multiplying that across 40 pipelines on every PR adds up. Mitigate with parallel processing (--parallel), diff-only enforcement via a changed-files wrapper, or a centralized scheduled full-scan nightly rather than per-PR. Central distribution via an internal Composer registry or a shared CI orb keeps the standard consistent as the repo count grows.

Failure modes to instrument for.

• Silent no-op — a sniff references a removed token or an unavailable standard, PHPCS emits a warning but exits 0, and the team believes it is enforcing a rule it is not. Guard: a self-test fixture with one known-bad file that must fail.
• Resolver deadlock — a transitive pin from 2021 blocks a security update elsewhere; discovered only when someone tries to bump PHPStan. Guard: contract test in the ruleset package's own CI.
• Contradictory formatters — Pint rewrites a file PHPCS subsequently rejects, producing a fix-lint loop that developers learn to bypass with --no-verify.
• Rule churn as breakage — an upstream default change makes 400 files non-compliant overnight. Guard: pin PHPCS exactly, not with a caret range, in the internal package.

Ramp-up. Near zero for developers already on PHPCS: the mental model (run phpcs, read violations, optionally phpcbf) is unchanged and the standard name is opaque to them. If the team is Pint-only, expect a half-day of orientation on detect-vs-fix semantics and one retro cycle where the team argues about specific sniffs — that argument is the actual adoption cost, and it happens whether the ruleset came from WT Health or was written internally. Framing the internal fork as "our standard, crediting WT Health's starting point" is worth more culturally than the marginal effort of copying a file.