Code Sniffer Laravel Package

Product Decisions This Supports

Build vs. buy for coding standards. Every PHP team eventually faces "do we write our own ruleset or adopt one?" This package is the buy answer, at least for the Slevomat/PSR-12 layer: it ships a fully composed standard (PSR-2 complete, PSR-12 included, plus a large set of opinionated fixers) that would otherwise cost weeks of sniff authoring, tuning, and false-positive triage. A PM can use it to close that decision and redirect engineering time to product work.

Scope of the engineering investment in code quality. The package makes a clear distinction between style enforcement (code:sniff:style) and architecture enforcement (code:sniff:architecture). That framing lets you decide, per quarter, whether you're buying consistency (cheap, immediate) or architectural invariants (module boundaries, Factory/Facade/Repository/QueryContainer method annotations, namespace-to-path mapping). These are different bets with different payoff curves.

Roadmap for standard tightening. The docs encode an incremental adoption model: start on Spryker, escalate to SprykerStrict, silence individual sniffs with <severity>0</severity> (whole rule or a single code path), then re-tighten. This is a roadmap primitive — you can commit to "PSR-12 clean this half, strict types and PHP-version-safety gating next half" without a big-bang reformat.

Toolchain and CI scope decisions. The README gives a concrete CI wiring pattern and an IDE integration recipe (PHPStorm external tools on Ctrl+comma / Ctrl+dot). A PM can use these to define the definition-of-done for PRs and to justify not building internal lint tooling.

Framework applicability, honestly assessed. Despite the Laravel/PHP framing, the value split matters: the PSR-12 + Slevomat base and the CI enforcement pattern transfer to any PHP codebase, including Laravel. The genuinely Spryker-specific sniffs (namespaces, method annotations, module layout, license doc blocks) do not. So the decision is really "adopt the base standard and pattern" vs. "adopt the whole thing," and only one of those is on the table outside Spryker.

Release pinning as an operational policy. The migration guidance — never bump the sniffer in a feature branch, land updates on a master-cs branch first, pin to patch releases with ~ — is a policy decision the PM should ratify, not leave to whoever runs composer update. Getting this wrong means every open branch fails CI simultaneously.

When to Consider This Package

Good fit:

• You are on Spryker (or a Spryker-adjacent suite). This is effectively the house standard, and the convenience command console code:sniff:style / code:sniff:architecture comes from the Development module.
• You have a multi-repo or many-contributor PHP codebase where review comments are dominated by formatting and naming instead of substance.
• You want a pre-assembled, fixable standard rather than authoring sniffs. phpcbf --standard=.../Spryker/ruleset.xml ./ autofixes a large share of violations, which is the difference between a rule people obey and a rule people disable.
• You need a defensible migration story for a large existing codebase: severity silencing, exclude-pattern for generated code, and per-branch rollout are all documented.
• You need opt-in strictness knobs: strictTypesMandatory, phpVersion safety checks, custom namespaces via .license-adjacent config.

Look elsewhere:

• Laravel / Symfony / generic PHP. For Laravel, the pragmatic stack is Laravel Pint or PHP-CS-Fixer for formatting, slevomat/coding-standard directly for the stricter rules, and Larastan/PHPStan for correctness. You'd be importing a large Spryker-shaped ruleset and then excluding most of it — a net cost, not a saving.
• You want static analysis. A sniffer is not a type checker. Pair it with PHPStan (this package itself declares level 8) rather than treating green sniffs as correctness.
• Small team or greenfield. Under ~4 engineers with a fresh codebase, a formatter plus editor-on-save covers most of the value; the CI gate and ruleset maintenance are overhead.
• You can't commit to scheduled, deliberate standard bumps. If the team bumps dependencies opportunistically, the sniffer will produce exactly the branch-wide breakage the docs warn about. Fix the process first.
• You need ecosystem signal. 38 stars and 0 tracked dependents is thin standalone evidence; the package's real adoption is inside Spryker Suite. Outside that ecosystem, you're the one finding the edge cases.

How to Pitch It (Stakeholders)

To executives — one paragraph. We can make an entire class of code review comment disappear, for free, under an MIT license. Today our reviewers spend time on formatting, naming, import ordering, and license headers — work that produces no customer value and is inconsistent across the team. This tool mechanizes that, in CI and in the editor, so review attention moves to design and correctness. It is a fixed, one-time integration cost with an ongoing cost limited to a scheduled dependency bump once per cycle. The main thing I am asking for is not budget but a process commitment: standard updates land on a dedicated branch, never inside feature work.

To engineering — the practical case. You get a composed standard (full PSR-2, PSR-12, plus Slevomat and Spryker-specific architectural sniffs) with auto-fix via phpcbf, so the majority of violations are repaired rather than hand-edited. It plugs into PHPStorm as two external tools with hotkeys, so you get feedback before pushing. It's configurable rather than dogmatic: silence a single sniff or a single rule code with severity 0 during migration, exclude generated folders (src/Generated, src/Orm, tests/_support/_generated), and extend it with your own ruleset.xml that refs the vendor ruleset. Two things to know up front: it requires PHP ≥ 8.2, and some PHP 8 features are deliberately sniffed as disallowed by default (named arguments, constructor property promotion, trailing commas, nullsafe operator) to prevent version creep — those are one-line <exclude> entries if we want them.

The honest caveat to state in the room. The Spryker-specific half of this package — namespace mapping, Factory/Facade/Repository/QueryContainer annotation checks, module layout — only pays off if we're actually on Spryker. On Laravel, we should take the pattern (a versioned ruleset, CI gate, auto-fix, IDE integration, disciplined bump cadence) and pair it with Pint/PHP-CS-Fixer plus slevomat/coding-standard, and not drag this ruleset in. Recommend we decide the framework-adjacent half explicitly rather than adopting the package wholesale by default.