Phpcs Rules Laravel Package

Product Decisions This Supports

• Engineering standards baseline (build vs. buy): This package is a curated PHPCS ruleset. It answers "do we maintain our own coding-standard config or consume a maintained one?" — the release cadence (0.4.8 → 0.5) supports buying/consuming over building.
• Static-analysis gate composition: The ruleset includes PHPCS, PHPStan, Rector, and unused-sniff checks in its own CI. That signals what a mature quality gate looks like, and gives you a reference architecture when designing your own pipeline — useful input for a "definition of done" or CI standard.
• CI cost / runtime as a product constraint: The release explicitly drops the 8.4/8.5 build matrix and collapses to a single worker to reduce GitHub Actions usage. That's a roadmap-relevant precedent: treat CI minutes as a tracked cost center, and expect vendors and internal tooling to do the same.
• Platform-version policy decisions: The breaking change to php: ^8.5 forces an explicit stance on "how fast do we chase the newest PHP runtime?" This is a policy question for the platform team, not a per-repo one, and it should be documented (e.g., "adopt new PHP minors within N months of GA").
• Use cases where the package is a fit: Greenfield Laravel/PHP services, monorepos standardizing style across teams, and packages that want an opinionated, low-maintenance rule set rather than a bespoke phpcs.xml.
• Use cases where it is not a fit: Client projects on vendor-mandated or long-term-support PHP versions, teams with an existing PSR-12/Slevomat config already tuned to their codebase, or regulated environments that pin dependencies and cannot absorb breaking platform bumps.

When to Consider This Package

Consider adoption when:

• Your services are already on, or actively migrating to, the minimum PHP version the ruleset requires — for 0.5 that is PHP 8.5. This is the hard gate.
• You want an opinionated, single-source style ruleset rather than each team curating slevomat/coding-standard and squizlabs/php_codesniffer themselves.
• You have a CI quality gate you can extend, and the cost of adding one more PHPCS run is acceptable relative to the value of consistent style.
• You are comfortable pinning to a minor line (0.4.x or 0.5.x) and upgrading deliberately, not continuously.

Look elsewhere when:

• You are on PHP 8.4 or earlier. Stay on 0.4.x; do not attempt 0.5. Note that 0.5 raising minimum to 8.5 while removing the 8.4 matrix means the maintainer is no longer validating against 8.4 at all — treat the 0.4.x line as maintenance-only and plan your exit or upgrade date.
• You need a stable, semver-guaranteed contract. At 0.x, breaking changes are permitted on minor bumps; a PHP-minimum jump in a 0.5.0 is consistent with that, but it means you cannot rely on "minor = safe."
• Your style is already settled and the delta from this ruleset is churn rather than value.
• You require an SLA or commercial support. This is a single-maintainer open-source package with no stated support commitment.
• You need the ruleset to cover non-PHP concerns (JS/TS, Blade formatting, etc.) — it doesn't.

Specific 0.5 watch-items for the adopting team:

• ReadonlyClass sniff excluded — this is a loosening. If your codebase relies on that rule to enforce immutability, you now need to enforce it via review or a separate config, and existing "violations" will silently stop being flagged. Expect a one-time drop in reported issues that is not an improvement in code quality.
• StaticClosure re-enabled outside tests — this is a tightening. Expect a burst of new violations on first run after upgrade. Budget a cleanup pass; it's mechanical but touches many files and will conflict with in-flight branches.
• CI matrix reduction is a signal, not a feature — it means 8.5-only validation going forward. Do not read the green build as 8.4 compatibility evidence.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small open-source package that standardizes PHP code style across our Laravel services. Its value is consistency and reduced review friction, not new product capability — it will not move roadmap metrics directly. The latest release (0.5) requires PHP 8.5, which we are not yet running, so adoption is gated on our PHP upgrade timeline; the safe action today is to stay on the 0.4.x line. The cost is low and the risk is a single-maintainer dependency, which we'd mitigate by pinning versions and keeping our config in-repo so we can swap the ruleset out if needed.

For engineering leads: Version 0.5.0 is a breaking release: minimum PHP raised to 8.5, and CI now validates only on 8.5 — the 8.4 build was removed to cut Actions spend. Concretely: (1) do not bump past 0.4.8 until the platform upgrade lands; (2) when you do bump, expect two separate one-time effects — a spike of StaticClosure violations to clean up, and a drop in ReadonlyClass findings because that sniff was dropped from the ruleset, which we'd need to backfill with review discipline or a supplementary config; (3) pin to an exact minor and treat every 0.x minor as potentially breaking. Recommendation: hold at 0.4.x, add the 0.5 upgrade to the PHP 8.5 migration ticket as a follow-on task, and do not adopt this ruleset on any repo that isn't on the same PHP floor.