Jump Start Laravel Package

Product Decisions This Supports

• Greenfield project scaffolding vs. bespoke setup. This is a starter kit (jump-start), so the primary decision it informs is whether new Laravel services boot from a standardized baseline or from hand-assembled config. v2.0.0 makes that baseline opinionated: PHP 8.4, Pest 5/PHPUnit 13, Pint 1.30+, plus Rector and PHPStan wired into the test path.
• Build vs. buy for developer-experience tooling. The release closes most of the "we'll configure this ourselves later" gap — static analysis (PHPStan), automated refactoring (Rector), formatting (Pint with Blade + Tailwind class sorting), and CI caching/pinning are now shipped rather than backlog items. Treat the kit as the buy option for tooling config.
• Quality-gate roadmap. CI now runs all four gates instead of tests alone. That's a policy decision, not just a config change: it sets the bar for what "green" means on new repos and creates pressure to retrofit the same gates onto existing ones.
• Upgrade sequencing on the roadmap. PHP 8.4 is now a hard floor, so the kit's release cadence becomes coupled to your runtime upgrade plan. Every new project adopting v2.0.0 is a de facto commitment to a PHP 8.4 host.
• Security posture / dependency hygiene. The npm update clears 5 advisories (3 high, 2 critical) across vite, postcss, nanoid, and shell-quote. That's a concrete, datable risk reduction for the front-end build chain — useful when justifying the upgrade on non-feature grounds.
• Supply-chain and CI cost decisions. Pinning every action to a commit SHA and caching Composer and npm are decisions you inherit for free; they reduce drift and CI minutes but add a maintenance obligation (SHA bumps) that someone must own.
• Use cases: new internal tools, client project kickoffs, proof-of-concepts that must survive into production, and template repos for teams standardizing across many Laravel services.

When to Consider This Package

Adopt when:

• You are starting new Laravel applications and want a consistent baseline rather than a per-team snowflake.
• Your infrastructure or host already supports PHP 8.4 — or you have a dated plan to get there.
• You want static analysis and refactoring enforced from day one, with /tests on both tools' paths, rather than negotiated later.
• Your team is comfortable with the Pest ecosystem (Pest 5 + PHPUnit 13); a PHPUnit-only shop will be swimming upstream.
• You can accept a Node toolchain in the PHP test path — the Blade formatting and Tailwind class sorting require prettier, prettier-plugin-blade, and prettier-plugin-tailwindcss, so npm ci must precede composer test. Confirm this works in your CI images and in local onboarding docs.
• You value a hardened CI template (full gate suite, SHA-pinned actions, dependency caching) and have an owner for keeping it current.

Look elsewhere when:

• You are maintaining existing applications. This is scaffolding; the breaking changes (PHP 8.4, Pest 5, Pint 1.30+) are migration work with no scaffold payoff on a mature codebase.
• You are pinned to PHP 8.3 or below — v2.0.0 will not install at all. Stay on v1.0.1 and track the runtime upgrade as a separate initiative.
• Your pipeline is deliberately PHP-only (no npm in CI) and you don't want to introduce it just for formatting.
• You need a full application starter (auth, billing, admin) rather than a tooling/quality baseline — verify scope before committing; this release is about the quality harness, not product features.
• You require a slower-moving, conservative dependency floor; Pest 5 / PHPUnit 13 is a recent major and third-party plugin coverage may lag.

How to Pitch It (Stakeholders)

For executives: This release is a maintenance upgrade to our Laravel starter kit, not a product feature. Its value is risk and velocity: it removes 5 known dependency vulnerabilities (including 2 critical) from the front-end build chain, and it makes four automated quality checks — tests, static analysis, refactoring, and formatting — mandatory on any project that starts from this template. The cost is a runtime requirement bump to PHP 8.4, which is a scheduling item for infrastructure rather than a spend item. Net: lower defect and security exposure on new work, at the price of a coordinated runtime upgrade.

For engineering: v2.0.0 is a breaking major. PHP 8.4 is now required (^8.3 → ^8.4); PHP 8.3 cannot install it. Pest moves to 5.1, pulling PHPUnit 13, and Pint's floor rises to 1.30 because the Pint/laravel_blade fixer depends on it. Pest's Rector and PHPStan plugins are wired up with tests/ on both paths, and CI now runs all four gates with every action SHA-pinned and Composer/npm caches enabled.

One operational gotcha to bake into onboarding and CI images: Blade formatting and Tailwind class sorting shell out to npm dev dependencies (prettier, prettier-plugin-blade, prettier-plugin-tailwindcss), so npm ci must run before composer test or the suite fails for reasons that look unrelated to the change under test. Recommend we (a) gate new repos on v2.0.0 only after confirming PHP 8.4 in the deploy target, (b) keep existing repos on v1.0.1 with a tracked migration ticket, and (c) assign an owner for the pinned-action SHA bumps, since that maintenance is now implicit in adopting the template.