Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Module Manager Livewire Laravel Package

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.

View on GitHub
Deep Wiki
Context7

Getting Started

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:

  1. The core 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.
  2. Livewire is installed and your layout includes @livewireStyles / @livewireScripts (or the v3 equivalent).
  3. Your admin route group and auth middleware are in place.

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.

Implementation Patterns

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');

Gotchas and Tips

  • Livewire 2 vs 3 is the first thing to check. Method names (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.
  • Enabling a module often requires a composer dump. If modules are PSR-4 autoloaded per-module, 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.
  • Cache invalidation is the number one source of "it didn't work." The module manifest, config cache, route cache, and view cache can each hold stale module state. When behaviour looks inconsistent between CLI and UI, run 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.
  • Zero stars and zero dependents means you are the QA team. Read the source end-to-end (it's small) rather than searching for docs; there will be no Stack Overflow answers and no issue history to mine. Pin the exact version in composer.json and expect upgrades to be unreviewed.
  • License is 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.
  • Debugging inside a Livewire component is awkward with 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.
  • Extension point to prefer: if the package exposes an interface or abstract for the module repository/lister, bind your own implementation in a service provider rather than subclassing the component. That keeps your customizations out of the Livewire lifecycle entirely.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
elmogy/larafast
xeviant/laravel-paystack
gorilladash/laravel-website-sdk
martialbe/flysystem-oss
chondal/3312client
jeroen-g/flickr
opscale-co/nova-genbi
itsjustvita/laravel-retention
tequilarapido/trackit
gregsphotography/site-builder-filament
cabaoctavio/laravel-query-log
gregsphotography/site-builder-components
io-digital/clickatell
snowsoft/laravel-admin
oxygen/auth
relicsoftware/barakah-payment-gateway
tobya/work-with-composer
equipc/laravel-email-validator
equipc/laravel-email-database-log
adedsec/nova-translated-labels