Coding Standard Laravel Package

Technical Evaluation

Architecture fit chadicus/coding-standard is a PHP_CodeSniffer (PHPCS) ruleset, not an application library. It carries no service provider, no config publish, no Artisan surface, and no runtime code path — it is a require-dev static-analysis dependency that plugs into Laravel projects via phpcs.xml (<rule ref="Chadicus"/>) and runs in CI or a Composer script. Architecturally it is a peer of Pint and PHPStan, not of application packages, and it sits entirely outside the deployable artifact.

Integration feasibility Low effort. The work is a Composer dev-dependency bump (^2.0.0 → ^2.0.1), a ruleset reference in phpcs.xml if not already present, and a CI job or composer lint script. No application code changes, no migration, no configuration migration. Semver-wise v2.0.1 is a patch on top of v2.0.0, so the constraint bump is safe.

Technical risk Low, but not zero. The single change — "Fix absoluteNestingLevel property name" — is a correctness fix inside the ruleset's sniff configuration. The material consequence is behavioural: PHPCS silently ignores properties that are misspelled or unknown for a given sniff, so in v2.0.0 the nesting threshold was likely not applied at all. After v2.0.1 the property is named correctly and the rule may begin firing, surfacing new violations in code that previously passed clean. The risk profile is "new CI failures," not "broken builds" or production impact. A secondary standing risk is PHPCS major-version coupling: rulesets reference sniff names and properties that are tightly bound to the underlying PHPCS release.

Key questions

• Which PHPCS major versions does v2.x support, and which one is in our lock file?
• Was the misnamed property in v2.0.0 silently ignored, or did it emit a PHPCS warning? This determines whether v2.0.1 changes results or only cleans up noise.
• Does the package maintain a documented semver policy for a ruleset, where a patch release can legitimately flip a build from pass to fail?
• Do we override absoluteNestingLevel in our own phpcs.xml, or do we inherit it entirely from the package? If inherited, what threshold are we now actually enforcing?
• How does this coexist with Laravel Pint's preset — is Chadicus authoritative, or supplemental?

Integration Approach

Stack fit Laravel 9–12, PHP 8.1+, dev-only. Coexists with Pint, but the two standards can disagree; pick one as the blocking gate and treat the other as advisory to avoid contradictory fix loops in the same PR.

Migration path

1. Bump the dev constraint to ^2.0.1 and run composer update chadicus/coding-standard in an isolated PR with no application changes.
2. Confirm the standard is registered: vendor/bin/phpcs -i should list it.
3. Run the full ruleset locally and capture the error/warning count as a baseline delta against the pre-bump run.
4. If the count rises, triage per violation — fix, or explicitly pin absoluteNestingLevel in our own phpcs.xml to the previously effective value to preserve current behaviour while deferring cleanup.
5. Only then promote the CI step from report-only to blocking.

Compatibility Verify the package's PHPCS constraint against our locked PHPCS version, and that the PHP version in the CI matrix matches local. Clear any PHPCS/IDE plugin caches after the bump — some editor integrations cache registered standards and will report stale results.

Sequencing Bump and measure first (one PR), decide on enforcement second (second PR), ratchet to blocking third. Keeping the bump separate from any code cleanup preserves a clean bisect point if results shift unexpectedly.

Operational Impact

Maintenance Near-zero ongoing cost — Composer updates only, no runtime surface to patch. The real maintenance exposure is project health: a small, single-maintainer OSS package. Pin the version, commit the lock file, and be prepared to fork or vendor the ruleset if the project goes dormant.

Support Community OSS, no vendor SLA. Failures surface as developer-facing PHPCS output with file/line/sniff references, which are self-diagnosing and rarely require escalation.

Scaling Dev-time only, so no production scaling concerns. PHPCS is effectively single-threaded over the codebase; use --parallel or shard by directory as the repo grows, and cache results in CI keyed on file hashes if lint time becomes a gate bottleneck.

Failure modes

• Silent config drift — the exact class of bug v2.0.1 fixes. Unknown sniff properties are ignored without error, so a ruleset can appear to enforce a rule it does not. Worth an occasional -vv run to confirm sniffs are actually active.
• Enforcement shift on a patch bump — new violations block merges after what looks like a trivial update.
• PHPCS major upgrade — sniff names and properties move; the ruleset may reference sniffs that no longer exist.
• Version skew — different PHPCS/standard versions between developer machines and CI produce non-reproducible results.

Ramp-up Low. Engineers need to know the lint command, where phpcs.xml lives, and how to suppress a rule with justification. Expect roughly an hour of onboarding, plus a one-time baseline cleanup if this fix tightens enforcement. The one habit worth instilling: treat patch bumps of a ruleset package as potentially behaviour-changing, not cosmetic, and validate them in CI before merging.