Resources Laravel Package

Product Decisions This Supports

• Platform upgrade gating. v3.0.0 exists solely to move the package onto Livewire 4. That makes this version a hard constraint on your Livewire upgrade path — adopting one forces the other. This is the single decision this release informs.
• Roadmap sequencing. If Livewire 4 is already on the roadmap, this package's v3 is a prerequisite line item inside that track. If it isn't, v3 delivers no user-facing value and should not be scheduled as standalone work.
• Build vs buy. A package that tracks Livewire majors promptly is a good sign for maintenance health and reduces the case for building equivalent UI in-house. It also means you inherit a recurring, externally-timed major-version migration obligation. Weigh that against the cost of owning the surface yourself.
• Use case fit. Best suited to Livewire-driven admin panels, dashboards, forms/tables and internal tooling where delivery speed outranks stack independence.
• What this is not. No new capability is described — this is maintenance cost paid on someone else's schedule. Do not position v3 to stakeholders as feature delivery, and do not attach product outcomes to it.

When to Consider This Package

Adopt when:

• Your application is on Livewire 4, or is committed to moving there in the same planning cycle.
• You would otherwise build this UI surface in-house, and a dependency on a Livewire-tracking package is acceptable.
• The package's release cadence historically lands close to Livewire major releases (this release is evidence in favour).
• Engineering can absorb a major-version bump — dependency audit, component re-test, regression pass — within a sprint.

Prerequisites to verify before adopting:

• composer.json constraint genuinely requires Livewire 4 (single-line release notes are not sufficient basis for a migration plan).
• Livewire 4-compatible transitive dependencies, including Alpine and testing helpers.
• Maintainer's support statement for the previous major — if v2.x is dropped immediately, your fallback disappears.

Look elsewhere when:

• You are on Livewire 3 with no Livewire 4 plan this cycle. Stay on the prior major and confirm its support window in writing.
• You need LTS or vendor-backed guarantees; a lockstep-tracking package creates upgrade pressure you don't control.
• You cannot tolerate a major upgrade timed by an upstream project rather than by your own roadmap.

How to Pitch It (Stakeholders)

For executives. This is a compatibility release, not a feature release. It keeps the package aligned with Livewire's current major version so it remains supported and receives fixes. The cost is engineering hours for migration, not licence or vendor spend. Recommendation: fold it into a Livewire 4 migration already on the roadmap, and do not fund it as a separate project. If Livewire 4 is not planned this quarter, stay on the prior major and track its support end date as a risk item. There is no customer-facing outcome to communicate.

For engineering. Treat v3.0.0 as breaking: the Livewire constraint moves to 4, so no partial upgrade is possible. Scope a spike covering transitive dependency conflicts, component and lifecycle behaviour changes, and test coverage gaps before committing to a date. Request from the maintainer a changelog beyond the one-line note plus a written support statement for the previous major — the thin release note is itself a change-management risk signal, and we should not plan a migration off it.