liberusoftware/module-manager-livewire
A Livewire-powered admin UI for managing Laravel modules: browse, enable, disable, and organize installed packages from one dashboard. Drop-in components bring module control to any Laravel app without custom tooling or extra wiring.
This is the UI layer of a two-package split: a module-manager core (discovery, enable/disable, manifest) and this Livewire adapter that renders it. Treat it as the "admin screen" package, not the engine.
Minimal setup:
composer require liberusoftware/module-manager-livewire
php artisan vendor:publish --tag=module-manager-livewire-config
php artisan vendor:publish --tag=module-manager-livewire-views # if you plan to restyle
php artisan migrate
Prerequisites to verify before you invest time:
liberusoftware/module-manager package is installed and its service provider is registered — this adapter will fail at container resolution if the underlying module registry isn't bound.@livewireStyles / @livewireScripts (or the v3 equivalent).Where to look first, in order:
vendor/liberusoftware/module-manager-livewire/src/Providers/ — reveals the component namespace, route registration, and config key.vendor/liberusoftware/module-manager-livewire/routes/ — shows whether a route is auto-registered (likely something like /admin/modules) and what middleware it assumes.vendor/liberusoftware/module-manager-livewire/config/ — the published config is the fastest way to learn which options exist; with zero dependents and no docs, the config file is the documentation.resources/views/ — the Blade will tell you more about the public API (component properties, method names) than any README.First use case: wire the module list into your admin panel so a non-developer can toggle a module on, run its migrations, and see it appear without a deploy. That single loop — list → enable → migrate → clear caches — is the whole value proposition. Build and smoke-test that before touching anything else.
Mount it as a page first, then embed it. If the package registers a route, hit it directly to confirm it works in isolation. Then re-mount inside your own admin layout using the component tag (typically <livewire:module-manager /> or a namespaced variant — read the provider's Livewire::component(...) calls to get the exact alias). Keeping one page-level wrapper around it gives you a stable place to add breadcrumbs, titles, and authorization without forking views.
Keep business logic out of your Blade. The temptation with these adapter packages is to call Artisan::call('module:enable', ...) from a button. Instead resolve the core manager service and call its API. Your own controllers, queued jobs, and CLI commands should all go through the same core service so the Livewire UI never becomes the only path to a working module state.
Hook post-toggle side effects explicitly. Enabling a module almost always implies: run its migrations, publish its assets, register its service provider in the manifest, and clear the compiled caches. If the package doesn't do all of that, attach a listener to whatever event the component fires (or wrap the call) and do it deterministically:
Event::listen(ModuleEnabled::class, function ($event) {
Artisan::call('migrate', ['--force' => true]);
Artisan::call('optimize:clear');
});
Gate the whole surface. These packages frequently ship with a permissive default because they assume you're behind an admin middleware already. Wrap the component in your own can:manage-modules gate or a Gate::define policy, and don't rely on the package's internal checks.
Customize through published views, not edits to vendor/. Override by publishing views into resources/views/vendor/module-manager-livewire/ and change markup only. Leave the component classes alone so composer update stays safe.
Test with Livewire's test helpers so a toggle bug is caught before it reaches a staging module directory:
Livewire::test(ModuleManager::class)
->call('toggle', 'billing')
->assertSee('Enabled');
emit vs dispatch), $rules vs #[Validate], and layout assumptions all differ. A 2026-dated release is probably v3-only, but confirm in composer.json before you plan anything.composer dump-autoload (or the core package's equivalent) must follow the enable. Class-not-found errors immediately after a toggle are almost always this.php artisan optimize:clear before debugging code.config:cache will break dynamic module config if the package reads module config files at boot. If you cache config in production, verify a newly enabled module's config actually loads — otherwise leave config caching off for the modules path.composer.json and expect upgrades to be unreviewed.NOASSERTION. That is not a permissive license — it means the repository did not declare one in a machine-readable way. Get clarity from the author or your legal team before shipping this in anything commercial; otherwise plan to vendor the code or reimplement the UI against the core package.dd() because it kills the AJAX response. Use Log::info() with the component state, or $this->dispatch('debug', $payload) consumed in the browser, and check storage/logs/laravel.log for the underlying core exceptions that the adapter swallows into a generic error toast.How can I help you explore Laravel packages today?