Php Coding Standard Laravel Package

Product Decisions This Supports

• Upgrade-path strategy: whether automated refactoring (Rector) is part of the standard major-version upgrade playbook, versus manual migration work. This package is the piece that makes Pest-aware codemods runnable inside the existing Laravel/PHP toolchain.
• Framework & test-stack currency: v1.1.0 is specifically a compatibility unblock — it makes pestphp/pest-plugin-rector an optional dependency, so consuming packages can adopt Pest 4 and run their matrix against Laravel 12 without being pinned back by a hard dev-dependency. That directly informs roadmap timing: "can we claim Laravel 12 support this quarter?" becomes a yes rather than a blocked item.
• Build vs. buy for internal tooling: if a team has been hand-rolling Rector configs and custom rules for Laravel/Pest upgrades, this is the buy-side option to weigh against maintaining that in-house.
• Standardization across repositories: shared rule sets let a platform team push one upgrade policy across many packages, instead of each repo rediscovering the same codemods.
• Dependency policy precedent: the opt-in switch (RECTOR_PEST) is a useful pattern to endorse — advanced tooling is available but never imposed, which lowers adoption friction for downstream consumers.

When to Consider This Package

Adopt when most of the following hold:

• The team already uses Rector as a routine part of upgrades, and tests with Pest (or is moving to Pest 4).
• You maintain one or more Laravel packages/libraries that must be tested against Laravel 12 and whose dev dependencies are visible to consumers — the exact scenario this release targets.
• Upgrades recur across multiple repos, so a shared, versioned rule set beats per-repo configuration.
• You want codemods applied in CI, gated and reproducible, rather than as ad-hoc local scripts.

Look elsewhere when:

• The codebase is PHPUnit-only and there is no Pest migration on the roadmap — the Pest-specific value is nil.
• You are a single small application upgrading infrequently; a one-off manual migration is usually cheaper than owning tooling.
• You already maintain a bespoke Rector setup with equivalent rules — adding this creates two sources of truth for the same refactors.
• You are evaluating it for runtime capability. This is dev/CI tooling; it ships nothing to production.

Operational caveat to carry into adoption: because v1.1.0 makes the Pest plugin optional, Pest-related refactors are no longer enabled implicitly. Any pipeline that assumed they ran must now keep pestphp/pest-plugin-rector installed and set RECTOR_PEST, or the rules will silently do nothing. Treat "did any refactor actually apply?" as an assertion in CI, not an assumption — a no-op pipeline looks identical to a clean codebase.

How to Pitch It (Stakeholders)

For executives: This is low-cost, high-leverage engineering tooling. It automates the repetitive mechanical work of framework upgrades, which is where large migrations quietly consume sprints. The v1.1.0 release removes a dependency constraint that was blocking us from claiming support for Laravel 12 and Pest 4 — no forking, no custom patching, no waiting on a vendor. There is no production runtime dependency and no customer-facing surface area, so the risk profile is limited to CI. The decision to make the Pest integration opt-in is deliberate and conservative: it preserves existing behavior for anyone who doesn't need it, while unblocking those who do.

For engineering: v1.1.0 decouples the hard dependency on pestphp/pest-plugin-rector, unblocking Pest 4 adoption and Laravel 12 test matrices for packages that expose dev dependencies. Pest Rector rules are now opt-in via RECTOR_PEST — if you want them, keep the plugin installed and set the flag; if you don't, nothing changes. Recommended rollout: pin the version, add it to the shared dev toolchain, and add a CI check that fails if the expected rules produce zero diffs on a known-bad fixture. That single guard catches the silent no-op failure mode that opt-in flags introduce.