Product Decisions This Supports
- Standards baseline for the platform / DevEx roadmap. Choosing between Laravel's default Pint/PSR-12 setup and a stricter, opinionated PHP_CodeSniffer ruleset for new services. This package sits on the shortlist for the "code quality baseline" initiative, not as a feature but as a decision that shapes how every future PR is reviewed.
- Build vs. buy (well, "buy" here means adopt + pin). The realistic alternative is writing and maintaining in-house sniffs. That cost is real (senior engineer days, ongoing maintenance, documentation), so the decision is: adopt an external ruleset and own the config, or fund an internal one. This package is an input to that comparison, not the conclusion.
- Code review capacity and cycle time. An opinionated, strict ruleset converts recurring review comments ("add return type", "missing strict_types", "use native type hints") into automated CI failures. The product-level benefit is measurable: PR cycle time, reviewer load, and how much senior time goes to nit-level feedback vs. architecture.
- Onboarding and documentation surface. If conventions are enforced by tooling rather than a wiki, new hires produce compliant code from day one. This supports the decision to spend on a tooling-based onboarding path instead of a documentation-based one.
- Static analysis rollout sequencing. Strict-typing enforcement makes a later PHPStan/Psalm adoption cheaper. This package is a lever that influences when we can justify a type-safety push.
- Dependency policy and supply-chain governance. It forces us to answer a policy question explicitly: do we permit single-maintainer dev dependencies? That answer applies well beyond this one package, so the evaluation has value even if the verdict is "no".
- CI cost planning. Any change to the rule set changes CI runtime. This informs whether we invest in PHPCS parallelization/caching.
When to Consider This Package
Consider it when:
- You already run PHPCS in CI and are actively dissatisfied with the PSR-12/PER baseline being too permissive — the value proposition is opinion, not new capability.
- You're on PHP 8.2+ and Laravel 10/11/12, and you want strict-types and native-type-hint enforcement that the mainstream presets leave optional.
- The team is small enough that an opinionated ruleset is cheap to adopt and cheap to reverse — a dev dependency pinned to an exact version is not a one-way door.
- You're willing to run a bounded trial: one repo, one branch, three metrics (PR cycle time, review comment volume, CI minutes delta), then a go/no-go.
Look elsewhere when:
- Single-maintainer risk is disqualifying. Two stars, zero dependents, one maintainer, and a first-meaningful-release timeline around late 2025 means there is no ecosystem signal that this survives its author's attention. If your dependency policy requires active maintainer diversity or vendor backing, stop here.
- You're standardized on Pint or EasyCodingStandard and don't want a second, partially overlapping toolchain in CI.
- You need PHP < 8.2, or you have a locked standards baseline (PER Coding Style, Laravel preset) and no appetite for a new set of opinions on top.
- You need SLAs, support contracts, or a stable long-term API. None of that exists here.
- You don't have a CI quality gate at all yet. Fix that first; tool choice is a second-order decision.
Mitigation if adopted: pin to an exact version, treat it as replaceable config, and record a fork-and-own escape hatch in the ADR.
How to Pitch It (Stakeholders)
Executives: It's a development-only tool that enforces coding consistency automatically. It never runs in production, adds no runtime dependency, and can be pinned and removed at effectively zero cost — so the downside is bounded. The upside is less senior-engineer time spent on style feedback and faster onboarding. The caveat is maturity: it's a very young, single-maintainer project, so we'd adopt it on trial, not as a standard.
Engineering leadership: Actively released (Dec 2025) and genuinely opinionated, which is exactly the gap in our current PHPCS setup. But it's early-stage with no downstream adoption to learn from — we'd be an early adopter, and we should plan to own the config ourselves.
Engineering team: This is a two-week trial on one repo behind an exact version pin. Success criteria up front: reduced style-related review comments, no more than a modest CI time increase, and a ruleset the team doesn't fight. If it doesn't clear those, we keep Pint and move on. Owner assigned, decision recorded in an ADR, revisited at the next quarterly dependency review.