Livewire Starter Kit Laravel Package

Product Decisions This Supports

• Platform baseline / standard-stack decision. v2.0.0 hard-pins to Laravel 13 and PHP 8.3+, and drops the ^12.0|^13.0 bridge that 1.0.3 offered. That makes this release the de facto "L13 starter kit" and forces a decision: does the org standardize new projects on L13 + PHP 8.3 now, or keep the 1.x line pinned for the remainder of the current quarter? Note that the CI matrix now covers 8.3/8.4/8.5 — so this package is also the cheapest available signal that your infra (build images, staging, prod runtimes) is 8.5-ready.
• Build vs. buy for project scaffolding. The optional-packages prompt now covers the full ArtisanPack UI surface (ai, bing-places, bookings, cms-framework, google, google-business-profile, hooks, icons, media-library, security, visual-editor) grouped by category, and correctly partitions code-style / code-style-pint into require-dev. That is a meaningful reduction in "assemble-a-starter-kit" work: feature selection is now a product/architecture conversation held at scaffold time rather than a per-project bundling chore. If your roadmap involves multiple content/booking/AI-enabled Laravel properties, this is a lever worth pricing against the alternative of an internal template repo.
• New-project kickoff readiness. The --no-interaction fix matters more than it reads. Previously, laravel new consumed the prompts silently and teams were left assembling packages by hand — a silent failure that surfaced as "the starter kit didn't work." Now the command re-attaches to /dev/tty, and when no terminal is reachable it prints an explicit "run this manually after install" notice. That converts an invisible gap into a documented step, which is what makes this usable in Docker, CI, and devcontainer onboarding paths. It affects time-to-first-commit for every new engineer.
• Upgrade gating for existing applications. Two items are release-blockers for any upgrade plan, and both are user-facing rather than purely technical:
  • session.serialization flips from php to json, which invalidates all existing session data. Every upgrading app needs a coordinated rollout (drain, logout-all, or a maintenance window) — this is a customer-visible support-ticket event, not a deploy detail.
  • config/cache.php ships an empty serializable_classes allowlist, matching L13's hardened deserialization default. Anything relying on object caching with custom classes will need an explicit allowlist entry or it breaks at runtime.
• Dependency-risk and support-window decisions. The major bumps (artisanpack-ui/security ^2.1.0, livewire-ui-components ^2.1.0, laravel/tinker ^3.0, laravel/boost ^2.0, Vite 7) mean a large simultaneous blast radius. Worth noting that livewire-ui-components ^2.1.0 drops the transitive owenvoke/blade-fontawesome dependency that was blocking L13 — that was a hard blocker, so this release unblocks the L13 migration entirely. Conversely, security going major signals a possible API or behavior change that needs a threat-model review before you adopt, not after.
• Roadmap sequencing constraint. Because v2.x is L13-only, any roadmap item slated for an L13 runtime depends on this release (or on hand-rolled equivalents) landing first. That makes v2.0.0 a predecessor node for L13-targeted features, and a hard gate for teams still on PHP 8.2.

When to Consider This Package

Adopt when:

• You are starting new Laravel 13 projects and want a curated, tested baseline rather than a bespoke internal starter.
• Your roadmap touches the ArtisanPack UI surface — CMS, bookings, media library, AI, Google integrations, accessibility, Livewire UI. The categorized prompt turns package selection into a checklist instead of a research task.
• You are already on PHP 8.3+ and can absorb Laravel 13 without a compatibility bridge — the ^12|^13 range is gone, so there is no staged path here.
• You need scaffolding to work headlessly: the /dev/tty re-attach plus the explicit manual-run fallback makes the interactive path defensible in containers and CI.
• You value the L13 hardening defaults (serializable_classes allowlist, json session serialization) being on by default rather than something each team remembers to configure.
• You are on PHP 8.5 or planning to be: the Pdo\Mysql::ATTR_SSL_CA preference is a real deprecation-noise fix for MySQL/MariaDB connections.

Look elsewhere (or stay on 1.0.3) when:

• You still run PHP 8.2, or must support Laravel 12 for any customer or internal obligation. There is no supported path in v2.x.
• You have long-lived session state and no ability to coordinate a logout/invalidations window — the php → json serialization change is unconditional and destructive to existing sessions.
• You depend on object caching of custom classes and cannot audit an allowlist quickly; the empty serializable_classes default will bite.
• You have already standardized on an internal starter kit, or you only need one or two of the bundled packages — the optional-packages surface is broad, and a full framework swap is disproportionate to pulling in artisanpack-ui/icons alone.
• Your change-control process cannot absorb a release that bundles two breaking platform changes (PHP floor, Laravel major) with a security major in one step. Consider whether cherry-picking the /dev/tty and SQL SSL fixes into your 1.x branch is more prudent than a coordinated v2 cutover.
• You need LTS-style stability guarantees; a 2.0.0 that simultaneously moves PHP, Laravel, Vite, Pest, and a security major is a fast-moving line, and a 2.0.1/2.1 patch window should be expected before production adoption.

How to Pitch It (Stakeholders)

To executives: v2.0.0 makes our Laravel starter kit a first-class L13 baseline. Two things matter commercially. First, it removes the last blocking dependency on Laravel 13 (the dropped blade-fontawesome transitive dep), so the platform upgrade we scoped is now unblocked rather than waiting on upstream. Second, the package-selection step finally works in non-interactive installs, which means new projects get a consistent, reviewed stack by default instead of each team hand-assembling one — that is a direct reduction in onboarding time and configuration drift across projects.

To engineering leadership: treat this as a planned migration, not a version bump. It is Laravel 13 only and PHP 8.3+ only — the 12/13 compatibility range is dropped, so anyone on PHP 8.2 is out until they move. The two operational items to sequence deliberately: session serialization moves from php to json, which invalidates all existing session data and needs a rollout plan; and config/cache.php ships an empty serializable_classes allowlist per L13's hardened deserialization default, so any custom-class object caching needs an explicit allowlist or it fails at runtime. Also budget review time for artisanpack-ui/security going to a new major — that is a behavioral-change signal, not just a version number. Upside of doing it: PHP 8.5 deprecation noise on MySQL/MariaDB is silenced, dev-only tooling (code-style, code-style-pint) now correctly installs as require-dev so it no longer leaks into production, and CI is validated across 8.3/8.4/8.5.

To product/design: the scaffold-time prompt now lists every ArtisanPack UI package, grouped by category — AI, bookings, CMS framework, media library, visual editor, Google integrations, accessibility, security, icons, hooks. That means capability selection becomes an explicit early product decision with a visible menu, rather than a series of ad-hoc composer require calls. Worth a short alignment session so new projects pick intentionally instead of defaulting to whatever the last project chose.