Livewire Gloom Laravel Package

Technical Evaluation

What it is: luttje/livewire-gloom is a small presentational Livewire component package that applies a "gloom" visual treatment (dimmed/hidden reveal effect) to UI elements. Scope is cosmetic; it does not touch the data layer, auth, queues, or persistence.

Architecture fit: Fits any Laravel app that already renders Livewire components — the component drops into a Blade view like any other. Low blast radius by construction: a failure degrades one visual affordance, not a workflow. It does not fit Blade-only, Inertia/Vue, or API-first front ends without an adapter, and it is not worth building one for a cosmetic effect.

Integration feasibility: High — Composer install, optional asset/view publish, drop-in tag. The gate is not effort, it is the Livewire 4 coupling described below.

Technical risk:

• Version-alignment policy is the headline risk. 4.0.0 exists to match Livewire's major, not because the package's own API changed. The release notes state explicitly that the major number "does not imply stability." This means semver on this package no longer signals its API stability — it signals Livewire's. Every future Livewire major becomes a forced migration for this package too.
• The 4.0.0 diff appears to be CI-only. The three listed changes (ramsey/composer-install 3→4, nick-fields/retry 3.0.2→4.0.0, dependabot/fetch-metadata 2.5.0→3.0.0) are GitHub Actions, not runtime code. If the only runtime change is a livewire/livewire constraint bump, adopting 4.0.0 carries near-zero behavioral risk if you are already on Livewire 4 and near-zero benefit if you are not.
• Compounding immaturity. A self-declared pre-stability package built on a newly-released framework major, maintained by a single author.
• Leaf-dependency hazard. A cosmetic package with a hard Livewire constraint can pin the whole application's upgrade path. This is the failure that actually costs a team a quarter, not a broken hover effect.

Key questions to resolve before approving:

1. Does 4.0.0 require livewire/livewire:^4.0, and is Livewire 4 GA at our target adoption date?
2. What is the actual runtime diff between 3.3.3 and 4.0.0 — composer.json only, or also views/assets/JS?
3. Is the 3.3.3 line still maintained for Livewire 3, or has support effectively forked?
4. What is the asset footprint (injected CSS/JS, Alpine coupling)? Livewire 4 ships its own Alpine version — presentational packages break here silently.
5. Is there any CI beyond dependency bumps (test suite, visual tests)?

Integration Approach

Stack fit: Laravel + Livewire shops only. If we are on Livewire 3 today, the answer is: stay on 3.3.3 and track. If we are piloting Livewire 4, 4.0.0 is the only compatible line — there is no version of this package that straddles both.

Migration path:

1. Confirm the installed Livewire major and the app's Livewire 4 decision. This package follows that decision; it never drives it.
2. Branch, then bump luttje/livewire-gloom and livewire/livewire together in a single change. Never let them drift.
3. Re-publish views/assets and diff against any locally overridden copies — stale published assets are the most common post-upgrade breakage for packages of this shape.
4. Visual regression on every surface where the component renders, not just a smoke test.

Compatibility: Verify publish tags (vendor:publish --force) are unchanged, and check Alpine version coupling against the Livewire 4 Alpine build. Confirm no CSS specificity collisions with the design system.

Sequencing: Livewire 4 GA → app upgrade decision → spike branch on one low-traffic surface → visual diff sign-off → rollout → then allow the major bump in composer.json. Do not auto-merge this Dependabot-style release; the version number moved, so a human should confirm what did and did not change.

Operational Impact

Maintenance: Single maintainer, dependency-bot-driven activity. Expect the version number to track Livewire rather than to track bug fixes or features. Low churn, but low responsiveness ceiling.

Support: No commercial backing; issue-driven only. Mitigate by treating the escape hatch as part of the design: the effect is cosmetic, so a wrapper Blade component of a few lines of CSS can replace it. Exit cost is effectively zero — that is the strongest argument for permitting it at all.

Scaling: Negligible. Presentational, render-time only, no I/O, no throughput concern at any realistic page volume.

Failure modes, ranked by cost:

1. Upgrade pinning — the package's Livewire constraint blocks an application-wide Livewire upgrade. Highest cost, lowest visibility until you hit it.
2. Silent visual failure — component renders without error but the effect disappears after an Alpine/CSS change. Only caught by visual tests.
3. Stale published assets after upgrade — overridden views/assets shadow the new version.
4. Asset collision with the design system — visible, and therefore cheap to catch.

Ramp-up: Hours for a developer to integrate. The real onboarding cost is governance, not code: the team must hold the rule "livewire-gloom major X requires Livewire major X." Put that in the internal component wrapper's docblock and the cost goes away.

Recommendation: Approve for use behind an internal wrapper component, pinned to a minor range, with the major bump gated on the application's Livewire 4 decision rather than on the package's release cadence. Do not approve it as a direct, unwrapped dependency in a shared layout — the coupling is not worth the effect.