Wireless Laravel Package

Technical Evaluation

Architecture fit. Wireless is an in-process adapter over Livewire's lifecycle: it stands up a synthetic component cycle inside the container, invokes mount/set/call, and reads back redirect(), dispatched(), returned() — all without touching the HTTP kernel. It adds no middleware, no service provider surface, and no config. That makes it a good fit for precisely one architectural shape: applications where meaningful behaviour lives inside Livewire components and must be triggered from a non-browser context (queue jobs, Artisan commands, seeders, webhook handlers, scheduled tasks, agent/tooling harnesses, integration tests). It is a poor fit if business logic is already extracted into services — in that case you'd be paying version-coupling costs for something you don't need.

Integration feasibility. Single Composer dependency: robert-stanciu/wireless:^3.0, requiring PHP 8.2+, Laravel 12, Livewire ^3.6. The public API is small enough to read in an afternoon. The blocker is not effort — it's evidence: zero stars and zero dependents means there is no production precedent to lean on. We would be the first consumer of consequence.

Technical risk. The package reaches deliberately into Livewire internals — it borrows the protected HandleComponents::hydrateForUpdate(), manipulates the redirector stack by frame identity, calls Livewire::flushState(), and tracks the authenticated user per guard so it can restore it after each cycle. Anything that mutates process-global container state is a category of dependency that behaves well in tests and badly in long-lived workers if the invariants are ever violated. The v3.0.0 changelog is, in effect, a list of exactly those violations found and fixed: dropped redirector snapshots, out-of-order teardown renumbering the stack, redirect swallowing in the surrounding request, cross-cycle user restoration. That the maintainer found and fixed them and then added a global test guard asserting no leaked component, frame, or redirector is a strong maturity signal — but it also tells us the failure modes are subtle and silent, not loud. The second structural risk is version coupling: the package renumbers itself onto Livewire's major (^3.6 here), which is honest but means every Livewire major is a porting exercise, not a version bump. The livewire:3.x-dev canary mitigates drift within v3; nothing mitigates v4.

Key questions.

• Which specific components are safe to drive headlessly — i.e. no reliance on render(), browser-only state, or request-scoped facades?
• Will this ever execute inside Octane or a long-lived queue:work process, where container state persists across jobs?
• Does any target component read or mutate the authenticated user or tenant context? If so, whose guard-restoration evidence do we have?
• Is coupling to Livewire's major cadence acceptable, given we will eventually move to Livewire 4?
• If the maintainer stops, is the surface small enough to vendor or fork in-house? (Probably yes; we should assume yes before adopting.)
• Do we actually need this in production paths, or only in CLI and test contexts where blast radius is contained?

Integration Approach

Stack fit. The target stack — Laravel 12, Livewire 3, PHP 8.2+ — is already the supported band, so there is no platform uplift to justify. Installation is Composer-only; no publish step, no migration, no config file.

Migration path. Adopt alongside existing practice, not as a replacement. Keep Livewire::test() for unit-level component tests; introduce Wireless for the contexts HTTP cannot reach (jobs, commands, webhooks) and optionally for integration-style tests where you want the real cycle rather than the test harness. Because v1.x and v2.x remain published and v3 is renumbered onto Livewire's major, this is a new dependency, not a forced upgrade of anything we already pin.

Compatibility. The version band is tight — Livewire ^3.6, Laravel 12 only. Composer will surface conflicts immediately. The specific compatibility question is other packages that also mutate Livewire's container bindings or redirector (test helpers, component-driving utilities); two such packages in one process is the scenario the changelog warns about.

Sequencing.

1. Spike (1–2 days). One Artisan command driving one read-only component. Explicitly run it in a long-lived process and assert post-call invariants afterwards.
2. Wrap. Put every Wireless call behind a single internal facade/adapter namespace. This buys replacement optionality, a place to add guards, and a clean seam if we later fork. Do this before the second use site, not after.
3. Expand to one async context — a queued job or webhook handler — with contract tests that mirror the package's own global guard: no component left on Livewire's stack, no redirector frame left open, container redirector restored.
4. Harden auth/tenant handling before any multi-tenant worker use, with a test that drives two different users on the same guard back-to-back.
5. Only then consider request-path usage, and only behind a feature flag.
6. Pin exactly. Add Renovate/Dependabot, but gate Livewire major bumps behind a joint upgrade ticket — they are not independent variables.

Operational Impact

Maintenance. Bus factor of one, no dependents, no community. MIT licensing means we can fork, and the surface is small enough that forking is a realistic contingency rather than a fantasy — but the fork still has to chase Livewire internals. Budget one to two engineer-days per Livewire major for porting or fork maintenance, and treat that as a standing line item, not a surprise.

Support. There is no SLA and no upstream support channel. Our team owns every failure. That is acceptable for internal tooling and test infrastructure; it is not acceptable for a customer-facing critical path without a documented owner and a fallback plan.

Scaling. The performance case is genuinely good: invocation is in-process, with no HTTP hop, no serialization boundary, no queue latency. Throughput is not the constraint. The constraint is that state mutation is process-global — so concurrency inside a single process (Octane workers, coroutines) is the risk vector, not volume.

Failure modes to instrument.

Mitigations: sandbox each drive (reset container state around it), assert the three invariants in CI as the package does, avoid driving user-scoped components until guard restoration is verified with our own test, and keep the adapter layer thin enough to swap.

Ramp-up. The API is learnable in a day; the mental model takes longer — a cycle that mounts, calls, and tears down but never dehydrates, so there are no effects to inspect mid-flight and effects() is gone in v3. The v3.0.0 changelog is the best documentation available and should be read as the failure-mode catalogue, not as release trivia.

Recommendation. Adopt for internal, CLI, and test contexts behind a wrapper namespace with an exact pin and CI invariant checks. Do not place it on a customer-critical or multi-tenant request path until auth-restoration behaviour is verified in our own environment. Treat the Livewire major cadence as a known recurring maintenance cost rather than an assumed-compatible dependency.