Hearth Laravel Package

Product Decisions This Supports

• Frontend stack strategy: This release confirms the package tracks Livewire v3, so it can inform the decision to standardize new and existing Laravel UIs on Livewire v3 rather than Blade + Alpine, Inertia, or a separate SPA frontend.
• Feature delivery: Teams already using the package can adopt Livewire v3 features (e.g., improved component lifecycle, wire:navigate-style SPA-like behavior, better JS interop) without forking the package, reducing custom glue code.
• Upgrade roadmap sequencing: If the product is still on Livewire v2, this release flags that the package's forward path is v3-only going forward. Plan the Laravel app's Livewire v3 migration alongside any package upgrade, not after it.
• Build vs. buy: Continued maintenance and upstream parity with Livewire reduces the case for building bespoke Livewire-based UI scaffolding in-house.
• Use cases: Best suited to server-driven, form-heavy, interactive Laravel apps (dashboards, admin panels, community/engagement surfaces) where the team wants Livewire conventions rather than a JS SPA.

When to Consider This Package

• You are on Laravel with Livewire v3 (or actively migrating to it) and want pre-built, maintained components/patterns rather than hand-rolling them.
• Your team prefers a server-driven UI (Blade + Livewire) over a JavaScript SPA, and values reduced frontend specialization requirements.
• You want to avoid maintaining a fork of a community package for a common UI need.
• You are on Livewire v2 with no near-term migration plan: do not adopt this release yet; upgrade Livewire first, or pin to the prior major.
• You need deeply custom, highly interactive client-side UX (complex animations, offline-first, heavy browser state): a JS framework may fit better; this package's value is in Livewire-shaped problems, not replacing a full SPA toolkit.

How to Pitch It (Stakeholders)

Executive summary: The package shipped v4.1.0, adding support for Livewire v3 — the current major version of Laravel's most widely used server-driven UI framework. This is a compatibility and modernization release, not a feature expansion in the package's own surface area.

• For product: Enables the team to build and ship interactive Laravel screens on a supported, current stack, reducing the risk of building on an aging frontend foundation.
• For engineering: Removes the need for a fork or custom Livewire bridge; the package now aligns with the ecosystem default. It also sets a clear upgrade requirement — Livewire v3 — which should be scheduled as a deliberate migration, not an incidental one.
• For finance/risk: Low direct cost; one dependency upgrade. The main risk is upgrade timing: teams on Livewire v2 must budget the migration (testing, component rewrites, third-party add-ons) before taking this package version.
• Recommendation: Adopt if you are on or moving to Livewire v3; otherwise treat this as a signal to schedule the Livewire v3 migration and hold the package upgrade until it is complete.