Laravel Starter Kit Laravel Package

Technical Evaluation

Architecture fit. This is not a Composer library — it is a project skeleton. dependents: 0 is the tell: nothing requires it, because you consume it by scaffolding (laravel new, composer create-project, or repo-template clone) and then own the result outright. That reframes the whole evaluation: the artifact under assessment is a golden-path baseline, not a dependency. Its opinionated shape is PHP 8.5 + Laravel 13 + Larastan v3 (max strictness) + Rector v2 + Pint v1 + Pest v5/PHPUnit 13 + Tailwind v4 + Laravel Boost v2 MCP, plus in-repo AGENTS.md / .cursor/rules agent guidance. That last part is the genuine differentiator — it ships machine-readable conventions alongside the code style, which is what most internal starter kits fail to do.

What v1.9.0 changes. Not much structurally, but three data points are worth recording. (1) The release notes describe CI behaviour, which confirms the skeleton ships a GitHub Actions pipeline in-repo — this partially resolves the highest-priority open question below, though not whether it gates merges or merely runs. (2) Rector and PHPStan caches moved from system /tmp to a project-relative tmp/ folder — minor in isolation, but it is the correct call for containerized runners with read-only or ephemeral filesystems, and it makes cache persistence/cleanup the project's own problem rather than the host's. (3) Dependency floors moved to Laravel ^13.33.0 and Boost ^2.10.0, and Actions pins moved to checkout@v7 / cache@v6 / upload-artifact@v7. There are no breaking changes, no deprecations, and no new capability. Treat v1.9.0 as maintenance evidence rather than a re-evaluation trigger — the architectural verdict is unchanged.

Integration feasibility. Greenfield: high — it is exactly the intended use case. Brownfield: low-to-moderate — you would be cherry-picking phpstan.neon, rector.php, pint.json, Pest bootstrap, and CI workflows into an existing app, one at a time. There is no upgrade path, no changelog contract, and no way to pull improvements without a manual diff. v1.9.0 is a clean illustration of this cost: the cache-path fix is exactly the kind of small quality-of-life change you cannot receive via composer update, only by diffing and porting by hand.

Technical risk.

• Bleeding-edge matrix. PHP 8.5, Laravel 13, Pest 5, PHPUnit 13 are all at or near the frontier. Managed runtimes (Forge/Vapor/Cloud, container base images, CI runners) lag. This is the single largest adoption blocker, and v1.9.0 tightens rather than relaxes it — the Laravel floor is now ^13.33.0, so any service scaffolded earlier sits below the current baseline until it is re-scaffolded or manually bumped.
• v0 dependencies. laravel/mcp v0 and laravel/prompts v0 carry no backward-compatibility guarantee; they are load-bearing for the Boost/agent workflow. Boost is now floored at ^2.10.0, which is a wider blast radius than before.
• Strictness as a velocity tax. Max-level Larastan on a real domain model produces significant initial noise; teams without static-analysis maturity will stall or disable it — the worst outcome, since it trades away the kit's only real value.
• Documentation drift, already visible. The two shipped rule files disagree (PHPUnit v13 vs v12; npm vs bun). Minor today, and notably v1.9.0 did not reconcile them — which reinforces that generated config and hand-written guidance are not validated against each other in CI.
• Low signal on production use. 883 stars with zero dependents and a 27.1 score means strong interest, thin evidence. Treat it as unproven at scale, though note the release cadence is now demonstrably active, which lowers (does not eliminate) abandonment risk.

Key questions.

1. Does the skeleton ship working CI? Partially answered by v1.9.0: a GitHub Actions workflow exists and is actively maintained. Remaining question: does it enforce Pint + Larastan + Rector + Pest as a required gate on PRs, or does it only run on push?
2. Is Larastan pinned at max level globally, or configurable per-path/with a baseline file for incremental adoption?
3. What is the release/versioning contract — are skeleton releases tagged (v1.9.0 suggests yes), and is there an upgrade guide between them? So far the notes are change-scoped, not diff-scoped; there is still no documented port path.
4. Which frontend assumption is canonical: Blade + Tailwind v4, or Inertia/Livewire? (The docs imply Blade-only.)
5. Does it include auth scaffolding, or is it deliberately bare to stay opinionated?
6. What is the stated support window and security-disclosure process, if any?
7. Is PHP 8.5 a hard floor or a floor with a soft ceiling — i.e., can we pin to 8.4 and still pass?
8. (New) Where do the project-relative tmp/ caches live relative to .gitignore and .dockerignore, and do the shipped CI cache keys cover them? A mis-scoped cache directory is a silent, slow CI regression.

Integration Approach

Stack fit. Strong for teams already on Laravel 12/13 with a GitHub Actions or GitLab CI pipeline, container-based deploys, and any existing AI-assisted development practice — the shipped AGENTS.md and Cursor rules mean the kit encodes conventions for both humans and agents, which most internal standards docs do not. Weak fit for teams on shared hosting, on PHP 8.2/8.3, or with a large legacy Laravel app they cannot re-scaffold.

Migration path — two distinct lanes.

• Greenfield (recommended). Scaffold a single non-critical service with the kit at v1.9.0 or later, run it through the full toolchain for one sprint, and use the output as the reference implementation before templating it org-wide.
• Brownfield (selective). Do not attempt to adopt the skeleton. Port tooling in this order: Pint config → Rector in --dry-run only → Larastan with a generated baseline → ratchet level directory-by-directory. Adopt the project-relative cache setting from v1.9.0 when you do port Rector/PHPStan — it is a two-line change and a real CI win. Copy the agent rule files verbatim and then correct them against your actual pinned versions. Never port the app structure.

Compatibility. Validate before committing: PHP 8.5 availability on the target runtime and in CI images; availability of required extensions; whether any existing first-party or vendor packages declare a Laravel 13 constraint ceiling; and whether the ^13.33.0 / ^2.10.0 floors are satisfiable against your current lockfile and any private registry mirrors. Note the internal contradiction on PHPUnit (v13 vs v12) and frontend tooling (npm vs bun) — resolve it explicitly and pin, rather than inheriting the ambiguity. The Actions bumps to checkout@v7 / cache@v6 / upload-artifact@v7 assume GitHub-hosted runner compatibility; if you are on self-hosted or GitLab, that whole workflow file is a reference document, not something you port.

Sequencing.

1. Sandbox evaluation: scaffold at v1.9.0, run the full local toolchain, measure lint/analysis/test wall-clock time and failure volume on a small realistic domain. Confirm the tmp/ caches are ignored by git and docker contexts.
2. Runtime gate: confirm PHP 8.5 on staging infra and CI before any team commits.
3. Tooling-only pilot in one existing service (Pint, then Rector dry-run, then Larastan baseline) to measure false-positive rate against real code.
4. Ratchet policy: define the level, the baseline-expiry rule, and who may add baseline entries.
5. CI enforcement as a required check, with caching keyed on composer.lock and the project-relative cache path, and a separate fast lint job from the slow analysis job.
6. Publish as an internal template repository with a documented, owned diff-from-upstream process — pin the baseline to a specific upstream tag (currently v1.9.0) so drift is measurable.
7. Agent-rule reconciliation: regenerate AGENTS.md from actual composer.lock versions on a schedule.

Operational Impact

Maintenance. Fork-and-own, not dependency-managed. There is no composer update that improves the skeleton; upstream improvements arrive only if someone diffs the repo and ports them. Budget a recurring, low-frequency owner task (quarterly diff against upstream, version-matrix refresh, agent-rule regeneration). v1.9.0 is a useful calibration of that task's size: a cache-path change plus version bumps is roughly a 30–60 minute port for a single service, so a three-to-five service footprint is a half-day of work per upstream release. The compensating benefit is real: because it is not a dependency, it introduces zero transitive supply-chain risk into composer.json.

Support. Community/author-maintained, no apparent LTS, no guaranteed security policy, no dependents to seed ecosystem answers. Assume full internal ownership from day one, including a named maintainer for the template. If the kit breaks against a Laravel point release, you fix it — there is no upstream SLA to escalate to. Release cadence now looks healthy (active enough to keep Actions and dependency floors current), which is reassuring about abandonment but should not be confused with a support commitment.

Scaling. Scales well as an organizational golden path: one template, N services, uniform quality gates, and agent guidance embedded per-repo. The cost center is CI: max-level Larastan plus Rector plus Pest 5 on every PR is materially slower than a default Laravel pipeline. Mitigate with path filtering, incremental analysis caches (now project-local, which makes them easier to persist and to invalidate), a parallel job graph, and nightly full runs rather than blocking every PR on the complete suite. Expect the strictness to also raise PR cycle time and review depth — a throughput tradeoff that should be an explicit, sponsor-approved decision, not a side effect.

Failure modes.

• Runtime unavailability: PHP 8.5 not offered by the hosting provider or base image — blocks deployment entirely; the highest-probability, highest-impact failure.
• Gate fatigue: analysis noise causes developers to add baselines or @phpstan-ignore widely, silently eroding the guarantee the kit exists to provide.
• Rector misapplication: automated refactors applied without a clean test suite cause behavior changes that pass review.
• v0 breakage: laravel/mcp or laravel/prompts releases a breaking change; the agent/Boost workflow degrades with no obvious symptom until someone relies on it. The ^2.10.0 Boost floor widens exposure here.
• Version lockstep: a Laravel 13.x security patch that requires a PHP or dependency bump strands services on the template's pinned matrix; patching becomes an emergency rather than routine. The ^13.33.0 floor raises the minimum bar for every new scaffold.
• Template decay: the internal fork drifts from upstream and from the org's actual practice; the agent-rule files describe a stack that no longer exists. v1.9.0 not addressing the PHPUnit/npm-vs-bun contradiction is a small but concrete instance.
• Cache misconfiguration (new, low severity): project-relative tmp/ caches committed to git or copied into Docker build contexts bloat images and can produce stale analysis results across builds. Worth a one-line check in the template.

Ramp-up. Non-trivial. Engineers without prior exposure to max-level static analysis, PHPDoc array-shape typing, generics, Pest 5 idioms, and Rector will need a guided spike — realistically 1–2 days of pairing per engineer, plus a documented "how to satisfy the analyzer" runbook, before the gates are net-positive. Track a small set of leading indicators through the first two months: analysis failure volume per PR, baseline entry count, CI wall-clock time, and PR time-to-merge versus the pre-adoption baseline. If analysis failures are not trending down by week six, the strictness level is set wrong for the team and should be ratcheted, not abandoned.

Recommendation. Unchanged by v1.9.0. Pilot on one greenfield service with a named owner and a hard PHP 8.5 runtime confirmation up front; adopt the tooling and agent-rule artifacts (including the project-relative cache setting) into existing services selectively; do not treat the skeleton as a package, a dependency, or an upgrade-managed asset. Baseline the internal template on v1.9.0 and re-run this assessment only when a release note contains "breaking," a major version bump, or a change to the toolchain matrix.