Weave Code
Modular Livewire Laravel Package
internachi/modular-livewire
Livewire plugin for internachi/modular that auto-discovers and registers Livewire v3 components from your application modules. Scans each module’s src/Livewire directory and registers components as {module}::{kebab-name} with dot notation for subfolders.
At a glance
Frequently asked questions about Modular Livewire
- How do I install modular-livewire in my Laravel project?
- Run `composer require internachi/modular-livewire` to install. The package auto-registers its service provider and plugin via Laravel’s package discovery. Ensure you meet the requirements: PHP 8.3+, Laravel 11+, internachi/modular ^3.0, and Livewire ^3.0.
- Can I use this package without internachi/modular?
- No, this package is a plugin for internachi/modular and requires it to function. If you’re not using modular, you’ll need to adopt it first, which may introduce architectural changes. It’s not designed as a standalone solution.
- What’s the directory structure for Livewire components with modular-livewire?
- Place Livewire components in `src/Livewire/` within each module. For example, `app-modules/billing/src/Livewire/InvoiceTable.php` becomes `billing::invoice-table`. Subdirectories use dot notation (e.g., `Reports/MonthlySummary.php` → `billing::reports.monthly-summary`).
- Does modular-livewire support Livewire 4?
- Yes, the package supports Livewire 3.x and 4.x. Check the package’s version compatibility (e.g., v1.1.0 supports Livewire 4) and ensure your Livewire installation matches. Downgrade paths or unsupported versions are not guaranteed.
- How does modular-livewire handle naming conflicts in Blade templates?
- Components use kebab-case naming with dot notation for subfolders (e.g., `<livewire:billing::invoice-table />`). If your team uses PascalCase, you’ll need to pre-process Blade templates or use custom resolvers to convert naming conventions before rendering.
- Will this package work with runtime-loaded modules (e.g., plugins)?
- No, modular-livewire currently only scans static modules at startup. For runtime-loaded modules, you’ll need to extend the package with event listeners (e.g., `ModulesDiscovered`) or implement custom discovery logic to register components dynamically.
- What happens if I have non-Livewire classes in src/Livewire/?
- The package will attempt to register all PHP classes in `src/Livewire/` as Livewire components, which may cause runtime errors. Mitigate this by adding `implements Component` checks to your classes or whitelisting only valid Livewire components in the discovery process.
- How do I test Livewire components registered via modular-livewire?
- Test components like any other Livewire class, but ensure your module is loaded in the test environment. Use Laravel’s module testing utilities (e.g., `Module::load()`) or mock the discovery process if needed. Per-module CI pipelines may require custom Artisan commands or service provider overrides.
- Can I mix modular Livewire components with globally registered Livewire components?
- Yes, but globally registered components won’t follow the `{module}::{kebab-name}` convention. For critical global components (e.g., checkout flows), manually register them in a service provider or use a fallback naming strategy. Plan for coexistence during migration.
- What’s the performance impact of auto-discovering Livewire components across many modules?
- Auto-discovery scans `src/Livewire/` in all modules at startup, which may slow boot time for large projects. For 50+ components, consider lazy-loading or caching the discovery results. Monitor performance in staging/prod and optimize if needed (e.g., exclude test modules).
Weaver
How can I help you explore Laravel packages today?