Livewire Assistant Laravel Package

Product Decisions This Supports

• Build vs. buy for JavaScript↔Livewire glue. The package is a client-side bridge (get/set/call against a mounted Livewire component from outside Livewire templates), not an Artisan scaffolder despite the repo description. If your roadmap includes third-party widgets (date pickers, rich-text editors, legacy jQuery plugins) or Vue/Alpine islands that must read or drive Livewire state, this is a buy candidate that replaces a small but perpetually fragile in-house adapter.
• Livewire 2 migration sequencing. 2.0.0 is explicitly the Livewire 2 line, with Livewire 1 frozen on 1.x. That makes it a planning input for when — and whether — Livewire 2 is in scope, and an explicit non-answer for Livewire 3.
• Form and search UX decisions. Deferred writes (set(path, value, { live: false })) mirror wire:model.defer, batching bridged input into the component's next request instead of one round-trip per keystroke. This is the feature that decides whether bridged high-frequency inputs are viable at all; without it, the package only fits low-frequency widgets.
• Client-side flows that need a response. call() resolving with the Livewire method's return value turns the bridge from fire-and-forget into request/response, unlocking validate-before-submit, lookup-style flows, and computed results without inventing a second response channel.
• Front-end navigation modernization. Turbo support alongside Turbolinks (via Livewire's livewire-turbolinks adapter, plus data-turbo-eval="false") supports Hotwire adoption without rewriting integration code.
• Security gating. The Livewire ≥ 2.12.7 floor is the first release carrying the fix for CVE-2024-47823 — the package refuses to run on a vulnerable Livewire. That is a genuine procurement and release-gate argument, not just a version note.
• Support-burden reduction. unsupported-operation is no longer raised because Livewire 2 performs every bridge operation, narrowing the error surface we have to document and support.
• Diligence items that should shape the decision, not just the ticket: the repo description (Artisan scaffolding/stubs) contradicts the release notes and docs (JS bridge) — a documentation-quality red flag to resolve before we pitch this internally. The package also has 1 star, 0 dependents, a single vendor, and a release dated 2026-10-23; treat footprint and provenance as unverified until we do a short compatibility and code-review spike.

When to Consider This Package

Consider it when:

• The product runs Laravel 7.30+/8.75+/9/10 on the matching PHP ranges (8.0; 8.0–8.1; 8.0–8.2; 8.1–8.3) with Livewire 2.12.7+ and needs a supported JS-to-component bridge.
• We have a non-Livewire JS layer (Alpine state, Stimulus/Hotwire, Vue islands, legacy widgets) that must drive or read Livewire component state, and the alternative is maintaining that glue ourselves.
• We specifically need deferred writes or method return values — the two 2.0.0 features that materially widen the use cases.
• The front end uses Turbo or Turbolinks and we want Livewire's adapter pattern rather than custom navigation handling.
• 1.x behavior parity matters: the integration API, bridge, attributes, and error codes are unchanged, so a pilot is cheap and reversible.

Look elsewhere or defer when:

• We are on Livewire 1 (frozen on 1.x, none of these features) or moving to Livewire 3 — this line does not support it, and Livewire 3 reworked the front-end contract.
• We are on Laravel 11/12 or PHP 8.4; unstated support is a blocker to confirm, not an assumption to make.
• We have a mixed Livewire 1/2 estate — you would run two package majors concurrently, which is a support-matrix problem before it is a code problem.
• Native Livewire (wire:model.defer, $dispatch, entangle) or framework hooks already cover the use case.
• Any defensive handler or test written against unsupported-operation exists — that contract change needs an audit before upgrade, not after.
• Vendor risk is unacceptable: single maintainer, 0 dependents, tiny public footprint, and no verified disclosure process. If the bridge becomes load-bearing, we own an exit plan.

How to Pitch It (Stakeholders)

For executives: This gives us a supported, low-cost way to connect third-party JavaScript widgets to Livewire components on the Livewire 2 line, instead of building and maintaining that glue ourselves. It adds deferred state sync (fewer server round-trips, better form UX) and method-return-value calls (richer client flows), and it enforces a Livewire version with a known CVE fix — which helps security and release governance. The honest framing: it is a scoped, time-boxed decision for a Livewire 2 estate, not a platform commitment, and it is a small single-vendor package with no measurable adoption, so we should pilot rather than standardize.

For engineering: 2.0.0 re-targets Livewire 2 using documented hooks and preserves the 1.x integration API, component bridge, attributes, and error codes — so the pilot cost is low and the migration is a platform re-target rather than a rewrite. It adds deferred writes (set(..., { live: false })), call() resolving with return values, and Turbo support next to Turbolinks. Constraints to verify up front: Livewire 2.12.7+ (security minimum), Laravel 7.30–10 with specific PHP ranges, no Livewire 3 path, and Laravel 11/12 or PHP 8.4 unconfirmed. Audit any reliance on unsupported-operation, and note that deferred writes create a client-only state window where get() diverges from server state — optimistic UI must tolerate it. First deliverable from the spike: confirm which Livewire 2 hooks the bridge binds to, and whether Laravel 11+ is genuinely incompatible or merely untested.