Codingstyle Laravel Package

Technical Evaluation

Architecture fit: The package is a PHP_CodeSniffer ruleset (built on m6web/coke and m6web/symfony2-coding-standard) rather than a runtime Laravel library. Its architectural role is a dev-dependency static analysis layer, which fits Laravel projects cleanly: it can be wired into composer.json under require-dev and invoked through a composer lint script or a CI job (GitHub Actions, GitLab CI, or Enlightn/StyleCI style gate). It does not touch the application container, service providers, or runtime boot path, so there is zero production surface area.

Integration feasibility: High. v1.0.5 materially improves installability in a Laravel context:

• Moving squizlabs/php_codesniffer out of core requirements is the most important change for a TPM. It lets teams pin their own PHPCS version (critical, since Laravel projects often already carry PHPCS via laravel/pint, squizlabs/php_codesniffer, or phpstan toolchains) instead of inheriting a hard transitive constraint that could conflict with the rest of the dev dependency graph.
• Unlocking the m6web/symfony2-coding-standard constraint reduces the risk of a Composer solver deadlock when mixed with Symfony-adjacent packages already present in a Laravel app (e.g., symfony/console, symfony/process).
• Adding m6web/coke to require makes the ruleset self-contained — the package now brings its own configuration runner rather than assuming a global install.

Technical risk: Low-to-moderate.

• The package lineage is Symfony-oriented, not Laravel-oriented. Expect friction: PSR-12 vs. Laravel's own conventions, and rules that may flag framework idioms (facades, helper functions, blade-adjacent PHP). Plan for a ruleset override file.
• Excluding Squiz.Strings.ConcatenationSpacing is a behavioral change to the ruleset — existing codebases that were previously clean may now behave differently (fewer errors, which is safe, but it changes the baseline diff).
• Releasing the PHPCS constraint shifts version-compatibility responsibility onto the consuming team. That is the right trade-off but must be documented internally.
• Thin signal: we only have release notes, no composer.json, no PHP/Laravel version matrix, no test coverage data. Treat adoptability as unverified until a compatibility spike is run.

Key questions:

1. What PHP version range and PHPCS major version does v1.0.5 support? Is PHP 8.2/8.3 covered?
2. Is there a published ruleset diff or changelog for the sniff exclusions beyond ConcatenationSpacing?
3. Does the maintainer intend this as a standalone standard or an overlay on symfony2-coding-standard?
4. What is the release cadence and maintainer count? Single-maintainer risk?
5. Does it ship a Laravel-specific preset, or do we author our own phpcs.xml wrapper?

Integration Approach

Stack fit: Suitable as a CI-only quality gate for Laravel 9/10/11 services. Recommended placement: require-dev, executed in a dedicated lint CI stage, not in the local pre-commit hook initially (to avoid developer friction during ramp-up). Pairs well with Pint only if we deliberately designate Pint for formatting and this ruleset for deeper sniff coverage — otherwise the two will disagree and produce churn.

Migration path: Treat as greenfield, not a migration.

1. Spike (1–2 days): Install in a throwaway branch of a representative Laravel service. Resolve Composer constraints against the existing dev graph. Confirm PHP + PHPCS versions.
2. Baseline: Run the ruleset against the current codebase, capture the violation count. Expect a large initial number.
3. Triage: Split violations into (a) auto-fixable, (b) genuine issues worth fixing, (c) Laravel-idiomatic patterns to exclude. Produce a project phpcs.xml that extends the package ruleset and documents every exclusion with a reason.
4. Ratchet: Enable CI enforcement only on changed files (--filter / diff-aware runs) or via a baseline file so the team is not blocked on legacy debt.
5. Full adoption: Once the baseline is burned down, enforce repo-wide.

Compatibility: Primary risk is Composer resolution, and v1.0.5 directly mitigates it. Secondary risk is rule-set conflicts with Pint, PHPStan, and any existing phpcs.xml. Verify coexistence before committing.

Sequencing: Spike → internal ruleset wrapper → CI on changed files → repo-wide enforcement → publish to other services. Do not block a feature release on this adoption; it is a background quality initiative.

Operational Impact

Maintenance: Low ongoing cost once the wrapper ruleset exists. The wrapper is the real asset — it is what insulates the team from upstream sniff churn. Budget roughly a half-day per upstream minor release to review rule changes and re-baseline. The v1.0.5 pattern of relaxing constraints suggests the maintainer is actively smoothing integration, which is a positive maintenance signal.

Support: Community/OSS support only. No vendor SLA. Escalation path is upstream issues plus our fork. Keep a fork-ready posture: pin to a specific tag (1.0.5) rather than a floating constraint, and record the exact resolved PHPCS version in composer.lock.

Scaling: Scales well — PHPCS is fast and parallelizable (--parallel), and CI cost is linear in changed-file count with diff-aware runs. The scaling concern is organizational, not technical: as more services adopt it, the shared wrapper ruleset becomes a versioned internal artifact and needs an owner. Assign that owner before the second service adopts.

Failure modes:

• Composer solver conflict on composer update in an unrelated PR, breaking CI. Mitigation: the constraint relaxations in v1.0.5 reduce this; pinning reduces blast radius.
• Rule drift silently changing pass/fail between upstream releases. Mitigation: pin the tag, review changelogs, run the ruleset in CI against main nightly.
• Pint/PHPCS disagreement causing developer confusion and reformatting churn. Mitigation: explicit ownership split documented in CONTRIBUTING.md.
• Blocked PRs on legacy files if enforcement is enabled repo-wide too early. Mitigation: diff-aware enforcement during ramp-up.
• Maintainer abandonment. Mitigation: fork readiness; the package is small and the wrapper ruleset is the durable artifact.

Ramp-up: Expect 2–4 developer-days total for the initial spike plus triage, then near-zero per-developer cost since violations surface as CI annotations. Developer education burden is minimal but real: the team needs to know which tool owns which class of style issue, and where to add justified exclusions rather than inline phpcs:ignore comments. Recommend a short written policy (one page) covering the Pint/PHPCS boundary, the exclusion-request process, and the pinning/upgrade cadence before rolling out to a second service.