Modular Livewire Laravel Package

Product Decisions This Supports

This package does not unlock new product capability. It changes how engineering organizes and ships UI work, and the product decisions it supports are therefore about delivery economics — how many teams can work in parallel, how much coordination a new screen costs, and whether the platform bet on a modular monolith pays off. Frame it accordingly, and it earns a place in the roadmap discussion. Frame it as a feature, and it will not survive scrutiny.

• Modular monolith: continue, or unwind? This plugin is a low-cost option on internachi/modular — it removes the main friction that makes modularization annoying in a Livewire shop. If the roadmap depends on multiple squads shipping independently in one codebase, this is the small tool that makes that bet coherent. If the organization is seriously reconsidering modularization, this package is moot and should not be evaluated in isolation.
• Feature work: how new screens get built. The concrete use case is UI surface area — admin tables, dashboards, per-module reports, tenant-facing settings pages. Every such feature lives in a module and needs a Livewire component. Today that means a manual registration line in a shared provider; with this plugin it means a file in a conventional directory. The product-relevant effect is that a feature no longer blocks on a shared-file edit or an unrelated squad's review.
• Roadmap sequencing for a Livewire upgrade. The package has followed Livewire majors (Livewire 4 support landed in 1.1.0), so any roadmap item that depends on a Livewire upgrade touches this dependency. That makes it a line item in upgrade planning, not a permanent platform commitment.
• Build vs. buy — and the honest answer is "neither, exactly." With 2 stars, zero dependents, and a single maintainer, this is not procurement. The real decision is adopt an external convention for a ~50-line concern, or write and own those 50 lines. That framing should go to the decision-maker, because it changes who owns the risk: adopting means inheriting upstream's release cadence; building means inheriting the maintenance, but keeping full control over aliasing, paths, and registration hooks.
• Team topology: which squads get autonomy, and when. Below roughly a dozen Livewire components, or with a single squad touching the UI layer, the module boundary plus plugin adds ceremony without buying parallelism. The decision this supports is deferring modularization until concurrency actually hurts — a legitimate and often correct product call.
• Where component variants (white-label, per-tenant) will live. The plugin gives a natural placement — a module-scoped component — but no mechanism for runtime variant selection or per-tenant aliasing. If the roadmap includes white-label UI, decide the variant strategy separately; do not let this package be mistaken for that solution.

When to Consider This Package

Adoption is justified only when a specific set of conditions holds simultaneously. Any one of them failing moves the answer to "decline and revisit."

Consider it when:

• internachi/modular v3+ is already adopted or approved. This is a plugin for that package; standalone it does nothing. If modularization itself is still undecided, the real decision in front of you is about architecture, not about this plugin — do not let a 2-star dependency become the camel's nose for a larger migration.
• Livewire is a primary UI layer, not incidental, and the component count is growing rather than stable.
• More than one squad writes Livewire components, and the shared registration file has become a recurring review bottleneck or merge-conflict source. This is the actual pain being solved.
• The team's convention is compatible with the package's non-negotiable one: kebab-case class names, dot notation for subdirectories, {module}::{component} aliases derived from directory names. No custom aliases, no configurable paths, no exceptions.
• A named owner exists for the dependency — a person, not a team — plus a standing plan to fork it if upstream stalls.
• The version matrix is verified against composer.json, not the README. The README claims Laravel 11+, while the 2.0.0 release notes state Laravel 11 support was dropped. Resolve this before committing a sprint.

Look elsewhere when:

• The stack isn't modular. A plain Laravel app with a conventional App\Livewire namespace needs nothing here; Livewire's own discovery already covers it.
• You need dynamic registration, per-component custom aliases, non-standard source paths, or an explicit registration hook for security review. These are deliberate design exclusions, not backlog items. If any is a requirement, stop and build in-house.
• The UI path is business-critical and unowned. Zero dependents, no vendor, no SLA, no issue triage, and a release log dominated by Dependabot bumps. That is acceptable for a pilot on a non-critical module; it is not acceptable for the billing or checkout surface without an approved fork-and-own plan in advance.
• You are on Laravel 11 and the 2.0.0 release notes are accurate — or you cannot get a clear answer on which it is. Ambiguity in the support matrix is itself a reason to pause.
• You want a caret range on a critical path. The 2.0.0 release was a breaking change solely for dropping Laravel 11 — evidence that upstream makes breaking moves with little ceremony. Pin the version.

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a small, free, MIT-licensed plugin that lets teams drop Livewire UI components into application modules and have them work automatically, instead of each one needing a manual registration edit in a shared file. It doesn't add customer-facing capability; it reduces coordination cost between squads, which is the thing that slows delivery once more than one team works in the same codebase. The cost is near zero and the change is reversible — components can be moved module by module, one squad at a time, and existing registrations keep working throughout. The risk is support: it is a 2-star package with one maintainer and no vendor, so the recommendation is a scoped pilot on one non-critical module, with a named owner and a fallback plan of writing the equivalent ~50 lines ourselves. Approve the pilot, not a platform commitment.

For engineering — the summary. A plugin for internachi/modular v3+ that scans each module's src/Livewire/ and registers components with Livewire as {module}::{kebab-case-class} (dot notation for subdirectories). Zero-config via package auto-discovery — no config file, no published assets, no migrations. Requires PHP 8.3+; verify the Laravel and Livewire majors against composer.json rather than the README, which claims Laravel 11+ that release 2.0.0 says was dropped. Migration is additive: existing Livewire::component() calls in the service provider continue to work, so this can be piloted per module and reverted by deleting a directory. The only change with blast radius is Blade alias renaming (<livewire:invoice-table /> → <livewire:billing::invoice-table />) — grep and review it. Capability ceiling is deliberate: no dynamic registration, no custom aliases, no configurable paths, no registration hook for audit. If we need any of those, we write our own provider instead. Success criteria for the pilot: components resolve under the expected alias, existing tests pass, and a newly added component requires zero manual registration edits. Gate: if the pilot surfaces a need for aliasing or non-standard layouts, stop rather than accumulating workarounds.