Wireless Laravel Package

Product Decisions This Supports

• Where business logic lives. The need for this package is a diagnostic: if you want to mount/set/call a Livewire component from a job, a command, or another component, your domain logic is currently trapped inside a presentation layer. The real decision this surfaces is extract to a service and call the service versus keep it in the component and drive the component. Extracting is the durable answer; this package is the shortcut that lets you defer it.
• Runtime orchestration vs. HTTP plumbing. Supports a build-vs-buy call on internal flows that today require a full request cycle — multi-step wizards executed server-side, one request fanning out to several components, an internal endpoint that needs to advance UI state without a browser. If those flows exist, the alternative is refactoring them out of Livewire entirely, which is weeks of work versus a small dependency.
• Headless / agentic and automation surfaces. Anything where a non-browser actor (queue worker, scheduler, admin tool, AI agent, seeded demo environment) needs to move a component through states. This is the highest-value use case and the one least served by alternatives.
• Test strategy. Livewire already ships Livewire::test() for mount/set/call in PHP. If your only need is test coverage, this package adds nothing and should be rejected on the spot. The decision it supports is whether you need this capability at runtime, outside the test suite — that distinction is the entire buy signal.
• Roadmap coupling to Livewire. Adopting it makes Livewire's internals part of your runtime contract. That is a roadmap input: it argues for budgeting a version-pinning and upgrade-review line item every time Livewire bumps a minor.

When to Consider This Package

Consider it when all of the following hold:

• You are on Livewire ^3.6, Laravel 12, PHP 8.2+ — v3.0.0 is explicitly scoped to that matrix and renumbered to track Livewire's major.
• You have a named, concrete runtime flow that today costs an HTTP round trip or a refactor, and you can point at it.
• The flow is internal and non-critical — admin tooling, seeding, automation, back-office orchestration — not a customer-facing path.
• You can pin the version exactly and accept that a Livewire patch release may break you.
• You have a written exit plan: the component calls are few enough to inline into a service, or you are willing to vendor/fork.

Look elsewhere when:

• You only need tests. Use Livewire::test(). Non-negotiable.
• You are on Livewire 4, or plan to be soon. The changelog openly notes it borrows hydrateForUpdate() and calls mount/call without Livewire 4's added arguments. This is a bridge built on internals that the next major will move.
• You need a vendor, SLA, or security review sign-off. Zero stars, zero dependents, single maintainer, no downstream usage to learn from. That is a support-risk profile, not a quality judgment.
• You run Octane or long-lived workers with concurrent component cycles. The v3.0.0 changelog is dominated by process-global state defects: a destroyed component's Redirector surviving for the life of the process, redirector frames released out of order across overlapping cycles, per-guard user restoration across two drivers on one guard, validation errors from an updated hook wiped by the next call. Those are not cosmetic bugs — they are the abstraction fighting the framework's global container. If you don't fully understand the failure modes, don't put them in a worker.
• You need isolation guarantees across tenants or users in one process. Same reason.

How to Pitch It (Stakeholders)

To executives: This is optional internal plumbing, not a product dependency. It lets server-side code drive a Livewire component directly instead of going through a browser round trip, which is useful for back-office automation, admin tooling, and background jobs. Cost is one Composer line under MIT. Risk is concentrated in the maintenance profile — a single maintainer, no adoption, and a hard coupling to Livewire internals — so it should be treated as a timeboxed experiment with an exit cost we've already estimated, not a platform bet. Recommendation: approve a scoped spike, not adoption.

To engineering: Small adapter, narrow scope, real value in exactly one place — runtime component invocation outside tests. Be explicit that Livewire::test() already covers the testing case, so we should only take this if we can name the runtime flow it unblocks. The v3.0.0 notes are the honest risk summary: the maintainer spent the release fixing global-state leaks in the redirector stack, the authenticated user, and the validation bag. That tells us the abstraction manipulates Livewire's process-global container, which is fine in a single short-lived request and dangerous under Octane or in a worker. Estimate the cost of removing it before we add it: if the call sites are three services, the exit is a day; if it's thirty, we're buying a dependency we can't leave.