Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for developer tooling: v1.9.0 confirms this package is a maintenance-layer product — it owns the unglamorous glue (Rector/PHPStan configuration, cache locations, CI workflow versions, dependency floors) so your team doesn't. That is a classic "buy/adopt, don't build" signal: the value is ongoing upkeep, not a one-time scaffold.
• Roadmap input on CI cost and reliability: moving Rector and PHPStan caches into the project's tmp/ folder is a small change with real operational upside — caches become project-scoped and inspectable, easier to invalidate per-branch, and no longer collide with system /tmp in containerized or shared runners. This supports decisions about CI minutes spend and cache-key strategy.
• Platform upgrade planning: the Laravel ^13.33.0 floor is the item that actually gates your roadmap. It tells you the package tracks current Laravel minors closely — good for staying upgrade-ready, but it means your own Laravel version becomes a hard constraint on when you can take package updates.
• Dependency posture as a risk input: actions/checkout@v7, actions/cache@v6, actions/upload-artifact@v7 and Boost ^2.10.0 show the package is actively maintained against current ecosystem versions. Useful evidence when deciding whether to standardize this toolchain across multiple Laravel services.
• Use cases it directly enables: onboarding new Laravel repos with a consistent static-analysis baseline, enforcing quality gates in CI without per-team configuration drift, and reducing the "our linters disagree between projects" class of support tickets.

When to Consider This Package

Adopt when:

• You run multiple Laravel services and want one opinionated Rector/PHPStan baseline instead of N bespoke configs.
• Your CI runs in containers or shared runners where system /tmp is constrained, wiped, or contended — the project-relative cache change is a direct win here, and worth pinning to >=1.9.0 specifically.
• You are already on, or planning to be on, Laravel 13.x. The ^13.33.0 floor makes this a non-starter below that.
• You want CI workflow definitions maintained by someone else rather than hand-bumping action versions each quarter.

Look elsewhere or wait when:

• You are on Laravel 11 or 12. The dependency floor in this release will block adoption until you upgrade — treat this as an upgrade-ordering dependency, not a package feature.
• You need finely tuned static analysis (custom rule sets, framework-specific extensions, PHPStan baselines with per-directory ignores). Opinionated tooling packages tend to fight you here; a hand-rolled setup usually wins.
• You require pinned, audited CI actions — if your security policy mandates SHA-pinned actions, generated workflows using floating major tags (@v7) will need review or forking.
• Your pipeline runs on non-GitHub CI (GitLab, Buildkite). The Actions updates are irrelevant, so a chunk of the release's value doesn't apply.
• You are on an LTS/legacy cadence and can't absorb frequent minor bumps. This package moves fast on Laravel and Boost floors; expect to chase versions.

How to Pitch It (Stakeholders)

For executives: This is low-cost plumbing that keeps our Laravel static analysis and CI current without engineer time. The v1.9.0 release is a routine maintenance update — no breaking changes, no migration work, no behavioral risk to production. Its main strategic value is that someone else is absorbing the ongoing version-churn of code-quality tooling, which is exactly the kind of work that quietly consumes senior engineer hours across every repo.

For engineering: v1.9.0 is a safe, additive minor. Three things to know: (1) Rector and PHPStan caches now land in the project's tmp/ rather than system /tmp — check that tmp/ is gitignored and, if you containerize, that it's on a writable volume; expect the first post-upgrade run to be cold-cache and slower. (2) The Laravel floor is now ^13.33.0 and Boost ^2.10.0, so this update is gated on your framework version — sequence your Laravel upgrade first. (3) Generated CI workflows have bumped to actions/checkout@v7, actions/cache@v6, and actions/upload-artifact@v7; if your org SHA-pins actions, run these through your standard review. No deprecations and no API changes, so adoption risk is low and the rollback path is trivial.