Modular Livewire Laravel Package

Technical Evaluation

Architecture fit. This is a thin adapter, not a platform. It registers a plugin with internachi/modular's plugin API that scans each module's src/Livewire/ directory and registers discovered classes with Livewire under a {module}::{kebab-case} alias, using dot notation for subdirectories. For a TPM the significance is coordination economics, not capability: it converts a recurring cross-team chore — every new Livewire component needing an edit to a shared service provider — into a filesystem convention owned entirely by the module team. That removes a standing merge-conflict and review-bottleneck surface. It is only on the table if internachi/modular v3+ is already adopted or approved; standalone, it does nothing.

Integration feasibility. High effort-to-value only in the right environment. Installation is a single composer require with an auto-discovered service provider and plugin — no config file, no published assets, no migration, no changes to AppServiceProvider. The feasibility question is therefore entirely prerequisite-driven: PHP 8.3+, internachi/modular ^3.0, Livewire ^3.0 (1.1.0 added Livewire 4 support), and a Laravel major we must verify rather than assume. Adoption is per-module and additive, so a pilot can be scoped to one low-risk module and reverted by deleting a directory.

Technical risk. Three items belong on the register, in order:

1. Support-matrix contradiction. The README states Laravel 11+, while the 2.0.0 release notes explicitly state Laravel 11 support was dropped. Resolve against composer.json and the actual runtime before committing a sprint — a late-discovered framework mismatch is the classic way a dependency like this burns a cycle.
2. Maintainer and adoption concentration. 2 stars, zero dependents, single-maintainer history, no vendor, no SLA, no issue-triage commitment. The release log is dominated by Dependabot bumps to GitHub Actions (checkout, setup-php, cache) rather than feature iteration — healthy hygiene, but not evidence of a support commitment. For a business-critical UI path this is a governance issue, not a footnote.
3. Deliberate capability ceiling. Static, convention-only discovery: no dynamic registration, no per-component custom alias, no configurable path mapping, no registration hook for security review or audit tooling. Any roadmap item depending on those is blocked rather than delayed.

Mitigating factor: MIT license plus roughly a service provider's worth of code makes it cheaply forkable. The realistic posture is "adopt the convention, budget for owning it, name an owner" — and make that decision in advance, not during an incident. Also verify the release timeline; the 2026-09-07 date on the latest release should be reconciled against the changelog's 0.0.1 placeholder-to-1.0.0 progression before citing maturity in any plan.

Key questions before I approve a pilot.

• Is internachi/modular v3+ already in the stack, or is this quietly a two-package commitment? If the latter, the decision is about modularization, not about this plugin.
• What does composer.json actually constrain — Laravel 11 supported or not? Which Livewire major are we on today, and does the pinned version cover it?
• Do we have a legitimate need for custom aliases, non-standard paths, or dynamic registration? If yes, stop here.
• How many Livewire components exist today, and how many squads touch the shared registration file per month? Below roughly a dozen components or a single squad, the modular scaffolding costs more than it saves.
• Who is the named code owner if upstream stalls? A person, not a team.

Integration Approach

Stack fit. Narrow and conditional. Viable only where three things are simultaneously true: modular monolith on internachi/modular v3+, Livewire as a primary UI layer, and a component count plus concurrency level where manual registration has become a recurring review nuisance. Where any is false, decline and revisit. The honest benchmark is a ~50-line in-house service provider implementing the same convention — put that on the table, because this is a build-versus-adopt call, not a procurement.

Migration path. Additive and non-destructive, which is the package's main planning virtue. Nothing existing needs to move: current Livewire::component() registrations keep working alongside discovered components, so both mechanisms coexist through the transition. Work is per-module relocation — move a component into app-modules/{module}/src/Livewire/, delete its manual registration line, update Blade references from <livewire:invoice-table /> to <livewire:billing::invoice-table />. That rename is the only change with blast radius; grep it and review it, don't eyeball it.

Compatibility. Pin explicitly and test the pin in CI. Constraint set to verify, not document on a wiki: PHP 8.3+, Laravel major (contradiction above), Livewire 3.x or 4.x, internachi/modular ^3.0. Note that 2.0.0 was a breaking release solely for dropping Laravel 11 — evidence upstream will make breaking moves with little ceremony, which argues for a locked version over a caret range on a critical path. The naming convention is also non-negotiable: kebab-case class names, dot notation for subdirectories, module name from the directory name. Any squad wanting an exception is asking for a fork.

Sequencing. Four stages, each with a stop gate:

1. Validation (days, not weeks). Resolve the Laravel version question; confirm pinned versions install and the provider registers in a scratch environment.
2. Pilot (one non-critical module). Pick a module with few Livewire components and one owning squad. Success criteria: components resolve under the expected alias, existing tests pass, and a newly added component requires no registration edit.
3. Core domains. Roll out module by module, one squad at a time, using the pilot squad as the reference implementation rather than a wiki page. Keep the manual registration path alive throughout.
4. Long tail and cleanup. Retire old registration lines only after the convention is established and the fork decision is settled.

Gate at each stage: if the pilot surfaces a need for aliasing, dynamic registration, or a non-standard layout, stop and reassess rather than accumulating workarounds.

Operational Impact

Maintenance. Low ongoing effort, non-trivial latent liability. The package does one thing and the code is small, so day-to-day maintenance is near zero. The liability is version currency: Livewire 4 support arrived in 1.1.0, and the Laravel 11 drop in 2.0.0 shows the maintainer tracks upstream majors reactively. Budget a recurring review at every Laravel and Livewire upgrade, and assume we may be the ones patching it. Assign a named code owner — "the team" is not an owner.

Support. Effectively none. No vendor, no SLA, no triage commitment, one maintainer, zero dependents — meaning no downstream community pressure to fix anything. Acceptable for a pilot on a non-critical module; not acceptable for the billing UI without a pre-approved fork-and-own plan. The trade is defensible only because MIT licensing and a tiny surface make forking cheap, and that mitigation is a decision to be made before it is needed.

Scaling. Scales well on the axis that matters: component count and team count. Discovery is a per-module directory scan, aliases are deterministic, and module boundaries let squads add components without touching shared files — the parallelization win. It does not scale on capability axes: no per-tenant or per-customer alias variation, no runtime registration, no feature-flag-aware discovery. If the roadmap includes white-label or tenant-specific variants, the package gives a natural placement (a module-scoped component) but not a mechanism; the variant selection lives in our code, not the plugin.

Failure modes to plan for. Silent non-discovery when a file sits outside src/Livewire/ — the component simply doesn't resolve, with no error at boot, so the pilot's success criteria must include a negative test. Alias drift when a module directory is renamed, since the module name is the prefix and every Blade reference breaks with it. Kebab-case conversion surprises on acronym-heavy class names, worth spot-checking against our naming habits. Collisions between a discovered alias and an existing manually registered one, which coexistence makes possible during transition. And hard breakage on the next Livewire major, as the 1.1.0 history shows.

Ramp-up. Low, and that is a genuine point in its favor. One rule to learn — put components in src/Livewire/, reference them as {module}::{kebab-name} — communicable in a single onboarding paragraph and reinforced by the pilot squad. No training program, no tooling, no config surface. The real ramp-up cost is organizational, not technical: getting squads to stop editing the shared provider is a habit change, and the pilot squad demonstrating it is worth more than any documentation we could write.