Product Decisions This Supports
- Build vs. buy for engineering standards. The real decision this package informs isn't "should we install a library," it's "do we adopt someone else's opinionated PHP_CodeSniffer ruleset, or author and own our own?" Reading this repo as a reference implementation is the highest-value use: it shows a working composition of
doctrine/coding-standard + slevomat/coding-standard pinned to a supported PHP version and PHP_CodeSniffer major. That's a few hours of research we don't have to do ourselves.
- Quality-gate policy in CI. Whether linting is advisory (warn) or blocking (fail the build) is a policy decision, not a technical one. A prebuilt standard makes the blocking option cheap to trial: one
require-dev line plus a phpcs.xml reference, run on a single repo, measure false-positive volume and review-comment reduction before committing org-wide.
- Roadmap sequencing for platform/tooling work. Concretely answers "when do we do the standards cleanup sprint?" Adopting a standard mid-roadmap creates a large, low-value diff that conflicts with every in-flight branch. The package's own PHP version floors (8.2 minimum, 8.4 in 2.21.0) tell you it must be sequenced alongside a PHP upgrade, not before it.
- Code-review throughput. The measurable benefit is deflected nitpick comments — spacing, import ordering, forbidden annotations, strict typing — moving from human reviewers to an automated gate. This is a capacity argument, not a craftsmanship argument, and it's the one that survives a prioritization meeting.
- Onboarding and contractor consistency. A committed ruleset shortens the "how do we write PHP here" conversation for new hires and external contributors, and makes the answer enforced rather than folklore.
- Framing correction to flag early: this is a PHP_CodeSniffer ruleset, not a Laravel package. It contains no service provider, no config publishing, no Laravel integration. Any decision framed as "add a Laravel package" is the wrong decision frame — budget it as tooling/DevEx work, not application dependency work.
When to Consider This Package
Adopt (or, more likely, copy from) it when all of the following hold:
- The codebase is not standardized on Laravel Pint. Pint wraps PHP-CS-Fixer; this is PHP_CodeSniffer. Running both means two formatters disagreeing about the same files — pick one toolchain, not both. For a Pint-based Laravel app, the sane path is Pint + selected Slevomat sniffs via PHP-CS-Fixer, and this package becomes inspiration only.
- You want Slevomat's stricter sniffs (type hints, strict comparisons, forbidden annotations, dead code) rather than purely cosmetic formatting. This is where PHP_CodeSniffer + Slevomat genuinely outpaces a formatter-only setup.
- You're on PHP 8.2+ and can follow the maintainer's floor upward. Below that, the current majors won't install.
- You have an owner for the standard. Someone must triage new violations, decide on
phpcs:ignore policy, and handle the next major bump.
Look elsewhere — or fork rather than depend — when:
- You need governance guarantees. 0 stars, 0 dependents, effectively a single maintainer, and a README that is a single line. There is no published rule list, no rationale per rule, no migration guide, and no deprecation policy. Four majors (2.x → 3.0.0 → 4.0.0) with changelogs consisting almost entirely of Renovate dependency bumps means version churn is driven by upstream pins, not by a communicated roadmap. You will absorb breaking changes on someone else's schedule.
- You need to explain your standard to an auditor or a new hire. No documented ruleset = no way to justify a blocked PR beyond "the tool said so."
- You need support or an SLA. None exists. Bus factor is one.
- You want Laravel-native ergonomics. No Artisan command, no preset selection, no Laravel-aware rules (Blade, Eloquent conventions).
laravel/pint is the ecosystem default and is maintained by the framework vendor.
- Recommendation: consume it as a template. Vendor a
phpcs.xml into your repo, pin the underlying slevomat/coding-standard and squizlabs/php_codesniffer yourself, and own the file. You get the rules without inheriting the release cadence. Depending on it directly is the option I'd need a strong argument to approve.
How to Pitch It (Stakeholders)
To executives (30 seconds): "This is a small, free, MIT-licensed configuration file that automates PHP code-style enforcement in CI. It's not a product dependency and adds no runtime risk — it runs only in developer tooling and CI. The value is reviewer time: style feedback stops consuming senior-engineer review cycles and becomes a build check. The cost is near zero; the caution is that it's a single-maintainer project with no support, so we'd copy the configuration into our repo rather than depend on it, and we'd own it from day one."
To engineering leadership: "Recommended action is adopt-as-template, not as dependency. We take the ruleset composition — Doctrine plus Slevomat on PHP_CodeSniffer — commit it as our own phpcs.xml, and pin the underlying tools ourselves. That gives us the strictness of Slevomat with none of the supply-chain or release-cadence exposure of a zero-adoption package."
To the engineering team: "Two decisions to make before we start. First, toolchain: if we're staying on Pint, this package is a reference, not an install — we do not run PHP-CS-Fixer and PHP_CodeSniffer on the same files. Second, adoption shape: roll out advisory on one repo for two weeks, count violations and false positives, then decide whether it becomes blocking. Expect a one-time formatting diff; schedule it in a quiet window so it doesn't collide with feature branches."
Ask: one engineer-day to author and commit the ruleset, plus agreement on warn-vs-block and a named owner for ongoing triage. Decision needed: toolchain consolidation (Pint vs. PHP_CodeSniffer) — that's the blocking call; the ruleset choice follows from it.