Laravel Laravel Package

Technical Evaluation

Architecture fit. This package is a development-time quality/tooling layer for a Laravel application, not a runtime dependency. It wires Rector (automated refactoring) and PHPStan (static analysis) into the project, ships opinionated CI workflows for GitHub Actions, and integrates Laravel Boost. That places it entirely in the build/CI path — it does not sit in the request lifecycle, does not add middleware, service providers, or migrations to production, and carries no runtime latency or availability surface. For a TPM this is a favorable profile: adoption risk is concentrated in developer workflow and CI, and rollback is a composer remove plus a deleted config file.

Integration feasibility. Low-to-moderate. Installation is standard Composer tooling with published config; the real effort is configuration tuning (PHPStan baseline, Rector rule sets, path scoping) and the one-time cost of cleaning up or baselining existing findings. On a brownfield codebase, expect the first PHPStan run to produce a large finding volume that must be baselined or triaged, which is the dominant effort driver and is often underestimated.

Technical risk. v1.9.0 introduces three changes worth flagging:

1. Laravel ^13.33.0 constraint (highest risk). A caret constraint on a new major excludes Laravel 12 and below entirely. Any application not already on Laravel 13 cannot install this version — Composer will hard-fail. This is a breaking change shipped in a minor version. Treat v1.9.0 as a migration, not a patch.
2. Project-relative caches. Rector and PHPStan caches move from system /tmp to <project>/tmp/. This is an improvement (per-project isolation, fewer cross-project cache collisions, better behavior on ephemeral/containerized runners) but it creates a new writable directory inside the repository that must be gitignored, must exist or be auto-created, and will accumulate. Expect at least one incident where a committed tmp/ directory or a Docker build context bloat appears.
3. GitHub Actions bumps to checkout@v7, cache@v6, upload-artifact@v7. These are the most current majors and assume GitHub-hosted or recently updated GHES runners. actions/cache@v6 in particular tracks the newer cache service backend; older self-hosted or GHES deployments may not support it. If the org uses GitHub Enterprise Server, pin and verify before merging the generated workflows.

Key questions.

• What is our current Laravel version across the applications that would consume this? If any are on 12.x, are we willing to sequence a framework upgrade ahead of, or alongside, this package?
• Is the Laravel 13 requirement in require or require-dev, and is there a documented support policy for prior majors?
• Are we on GitHub-hosted runners, or GHES/self-hosted? Which GHES version?
• Does the package auto-create tmp/, and does it ship a default .gitignore entry for it?
• What is the intended PHPStan level (and Rector rule set) that the package defaults to, versus what we would want?
• Is Boost a hard requirement or optional? It is declared at ^2.10.0, so it will be installed transitively whether or not we use it.

Integration Approach

Stack fit. Appropriate for any team already standardized on PHPStan + Rector, or intending to be. It replaces hand-rolled tooling config and CI YAML with a maintained, versioned equivalent — a genuine reduction in bespoke maintenance. The GitHub Actions coupling is a constraint: teams on GitLab CI, Bitbucket, or Jenkins get the PHP-side tooling but not the CI workflows, and the value proposition weakens accordingly. Confirm the pipeline platform before committing.

Migration path. Because there is no prior assessment, this is a greenfield integration and the version-constraint question should drive sequencing. Recommended path:

1. Inventory Laravel versions across candidate applications.
2. For applications already on Laravel 13.x, adopt v1.9.0 directly.
3. For applications on 12.x or below, either (a) upgrade the framework first, or (b) pin this package to the last 1.8.x line, which presumably supports the older major — verify that pin resolves cleanly before it is needed as an escape hatch.
4. Pilot on one mid-sized service, not the largest and not the smallest.
5. Add tmp/ to .gitignore and to any Docker build-context ignore file as part of the install PR, not as a follow-up.

Compatibility. The dominant compatibility axis is the Laravel major constraint, followed by PHP version (PHPStan and Rector both track recent PHP releases closely; confirm the package's PHP floor matches the team's lowest supported runtime). Secondary axes: GHES version versus the Actions majors, and Composer 2.x. There is no runtime compatibility surface — no database, queue, cache, or HTTP contract changes.

Sequencing. Framework upgrade → package adoption → CI workflow swap → baseline/triage cleanup. Do not parallelize the framework upgrade and the package rollout on the same service; if the build breaks, you will not be able to attribute the failure. Allocate the baseline-cleanup work explicitly rather than absorbing it into "adoption."

Operational Impact

Maintenance. Positive. The package absorbs Rector/PHPStan/Actions version churn that the team would otherwise manage by hand. The cost is a dependency on the maintainers' release cadence and judgment — v1.9.0's pairing of a major framework constraint with a minor version number is a concrete example of why upgrades should be reviewed rather than auto-merged, even under a Renovate/Dependabot policy.

Support. No production support burden: no on-call surface, no runtime SLOs, no incident path. Support risk is developer-experience only — a broken build blocks merges but does not affect customers. That materially lowers the consequences of a bad upgrade and argues for a straightforward rollback policy (revert the lockfile, re-run CI) rather than a formal change-control process.

Scaling. Scales fine across repositories; the per-project tmp/ cache change actually improves scaling characteristics by removing cross-project contention and cross-contamination in shared /tmp on shared runners. Two watch items: disk growth in tmp/ on long-lived self-hosted runners and inside Docker build contexts (mitigate with ignore rules and, if needed, periodic cleanup), and the fact that each repository adopting the workflows duplicates the CI minutes cost. Budget CI minutes as a real line item — full PHPStan at a high level on a large codebase is not free, and it runs on every PR.

Failure modes.

• Composer resolution failure on Laravel <13 — loud, immediate, pre-merge. Low severity, high likelihood for some subset of repos.
• Cache directory not present or not writable in containerized/CI environments — manifests as slowed or failing analysis runs rather than clear errors; ensure auto-creation or pre-create it in the image.
• Committed or Docker-context-included tmp/ — quiet bloat, discovered late. Mitigate at install time.
• Actions major bumps incompatible with GHES/self-hosted runners — CI fails on the workflow, not the code; easy to misdiagnose as a code problem.
• Unbaselined analysis noise — the most likely cause of adoption stall: developers see hundreds of pre-existing findings and the tool gets disabled. This is a process failure mode, not a technical one, and is the single most common reason these integrations quietly die.

Ramp-up. Developer ramp-up is roughly half a day to a day: understanding the Rector/PHPStan output, how to regenerate a baseline, how to suppress a finding legitimately, and where caches live. Team-level ramp-up is mostly the baseline triage exercise, which scales with codebase size and existing code hygiene. Recommend one engineer own the pilot end-to-end and produce a short internal runbook covering ignore rules, baseline regeneration, and the version-pin escape hatch — that document, not the package itself, is what determines whether adoption sticks.