Livewire Gloom Laravel Package

Product Decisions This Supports

• Livewire 4 migration sequencing. v4.0.0 is a version-alignment release: the package's major version now tracks Livewire's major version. This tells us the package expects Livewire 4. It is an upgrade-gating input for any roadmap item that moves the app to Livewire 4, not a standalone feature decision.
• Dependency risk register. The only listed changes are CI/Dependabot bumps (ramsey/composer-install, nick-fields/retry, dependabot/fetch-metadata) — build tooling, not runtime code. That means the "major release" carries little new product surface but does carry a compatibility claim we cannot verify from the notes alone. Treat it as a signal to test, not a signal to ship.
• Build vs buy (retain vs replace). For a UI/component-level package like this, replacement cost is low. If the Livewire 4 alignment proves shaky, the fallback is inlining the component or swapping it, not a rewrite. That keeps this as a low-lock-in dependency.
• Upgrade policy per app version. Teams on Livewire 3 should stay pinned to 3.3.3. Teams already on Livewire 4 are the only audience for 4.0.0. This is a per-project decision, not a portfolio-wide one.
• Release-cadence expectations. The maintainer is signalling "aligned, not stable." Do not plan roadmap features that assume this package leads or keeps pace with Livewire releases; plan for lag.

When to Consider This Package

Adopt or upgrade when:

• Your application is already on Livewire 4, or Livewire 4 migration is funded and scheduled — v4.0.0 is explicitly aligned to that major version.
• You need the component's capability and want it maintained by the upstream author rather than vendored into your codebase.
• You can absorb a major version bump with an explicit "test thoroughly before production" warning — i.e. you have staging coverage and a rollback path.
• You accept a solo/small-maintainer dependency with a public changelog and no formal stability guarantee.

Look elsewhere (or stay on 3.3.3 / vendor the code) when:

• You are on Livewire 3. 4.0.0 is a breaking alignment; there is no stated benefit for you.
• You require a stability commitment or SLAs — the release notes actively disclaim stability.
• Your app is production-critical and cannot absorb a package whose major version bumps in lockstep with its host framework's major version, since that couples your upgrade calendar to two projects at once.
• The release notes list only CI dependency bumps — if you need confirmation that Livewire 4 runtime compatibility was actually implemented and tested, get that evidence (composer constraints, test matrix, a smoke test) before adopting.

How to Pitch It (Stakeholders)

For executives: A dependency we use for Livewire UI has released v4.0.0. The headline is version alignment with Livewire 4 — not new functionality. The maintainer has explicitly said this does not imply stability and asks for thorough testing before production use. Recommendation: do not upgrade on our current Livewire version; treat this as an input to the Livewire 4 migration plan, where it becomes a small, reversible line item. Risk is contained because the package is replaceable at low cost.

For engineering: v4.0.0 bumps the major version to track Livewire 4. The visible changelog contains only CI tooling updates (composer-install 3→4, retry 3.0.2→4.0.0, fetch-metadata 2.5.0→3.0.0) — no runtime changes are documented. Before adopting, verify the composer.json Livewire constraint actually requires ^4, confirm the test matrix runs against Livewire 4, and run a staging smoke test of every component in use. Pin Livewire 3 apps to 3.3.3 and keep an upgrade branch per app so we can prove compatibility rather than assume it. Track upstream for a follow-up patch release, which would be the better moment to promote to production.