Wire Extender Laravel Package

Product Decisions This Supports

This is a scope-reduction lever, not a feature. wire-elements/wire-extender lets a Laravel app mount Livewire components from outside Livewire's normal page lifecycle (plain controllers, legacy Blade views, CMS/marketing pages, admin panels). For a PM, that maps to a small number of high-value decisions:

• Incremental modernization vs. rewrite. If we have legacy controller-rendered screens, this package lets us ship interactive islands (a filterable table, a cart widget, an inline edit form) without converting the whole route to Livewire or standing up a JS SPA. That's a roadmap option that buys quarters of runway.
• Build vs. buy. The alternative is hand-rolling a component-mounting bridge plus its Blade directives and request/response plumbing. That's ~a sprint of work with ongoing maintenance, for zero differentiation. Default should be buy — conditional on the compatibility picture below.
• Feature sequencing for embedded surfaces. Reusing Livewire components inside CMS pages, partner-facing embeds, emails-preview tooling, or a legacy admin is a common ask. This package turns "we'd have to build that twice" into a small ticket.
• Upgrade-coupling budget. Most importantly, this release forces a planning decision: Livewire major-version upgrades and this package's version are now the same workstream. That belongs on the roadmap as one line item, not two.

What v2.0.4 actually changes: it removes Livewire v3 support from the 2.x line. It is a patch-version number carrying a compatibility break — a team on Livewire 3 that runs a routine composer update can regress. Treat the version number as unreliable and manage this dependency by explicit pin, not by constraint range.

Recommended stance: Pilot / Adopt-with-pin, qualified by Livewire version:

• On Livewire 3 → pin v2.0.3 exactly; do not float. Blocked from 2.0.4+.
• On Livewire 4+ → 2.0.4 is the supported path; pin exact and re-verify on each bump.
• No Livewire footprint yet → pick the Livewire major first, then this package; don't let the package choose it for you.

When to Consider This Package

Adopt when most of these hold:

• Livewire is already a stack standard, and the team is fluent in its component model.
• There's a concrete, named surface that cannot be a Livewire page: a legacy Blade screen mid-migration, a CMS-managed landing page needing one interactive module, a package/panel that owns its own routing, or a controller that must return a full server-rendered response.
• The alternative is duplicating a component in Alpine/vanilla JS — i.e., the second copy is the real cost.
• Someone owns the dependency: exact pins, a compatibility matrix in the repo, and a check in the upgrade runbook.

Look elsewhere or build thin when:

• You're on Livewire 3 and upgrading isn't funded this cycle. 2.0.4 is a dead end for you; staying on 2.0.3 is a deliberate frozen-dependency decision that needs a review date, not a silent one.
• All your UI is already full-page Livewire — the package adds a compatibility liability for a capability you don't use.
• SEO/crawlability or first-paint is load-bearing for the surface in question; client-hydrated components are the wrong tool regardless of mounting convenience.
• The work is a one-off. If exactly one screen needs one interactive widget, a Blade partial + Alpine is cheaper than a new dependency with a hard version lock.
• You need a hard support SLA or a multi-maintainer vendor. This is a small, ecosystem-maintained package; budget for the possibility that a Livewire major ships before this package catches up, and have a fallback (revert to plain Blade + Alpine for the affected islands) documented.

The real adoption criterion is not "does it work" — it's "can we absorb a breaking change delivered in a patch release without a production surprise." If the answer is no, fix that first.

How to Pitch It (Stakeholders)

To executives (one paragraph): We're evaluating a small open-source add-on that lets us drop interactive Livewire components into screens that aren't built as Livewire pages — mainly our older admin and CMS-managed pages. The business value is avoided rewrite: instead of rebuilding those screens to modernize one table or one form, we mount a component into the existing page and move on. Cost is near zero in license terms; the real cost is dependency discipline. The latest release drops support for the previous Livewire major version while only incrementing the patch number, which means a routine dependency update can break us. Recommendation: pilot on one low-risk screen, pin the version explicitly, and log the Livewire upgrade as a scheduled workstream rather than an incidental library bump. Expected outcome is a measurable reduction in "we can't touch that page" backlog items.

To engineering (the short version):

• Capability: mount Livewire components outside the Livewire page lifecycle. Small surface area, drop-in, no architectural commitment.
• Heads-up on v2.0.4: Livewire v3 support removed. Semver-wise this is a breaking change shipped as a patch. Do not widen the constraint and do not composer update this package blind.
• Actions: (1) pin an exact version per Livewire major; (2) add a row to the compatibility matrix and the upgrade runbook; (3) confirm which Livewire major each app is on before any bump; (4) keep a documented fallback path — Blade + Alpine for the affected islands — so a stalled upstream release isn't a blocker.
• Ask: one pilot surface, one sprint, with a written "how we revert" line in the ticket.