Module Manager Filament Laravel Package

Getting Started

The package is a Filament panel integration for a module manager — it gives you a UI (typically a Filament Page or Resource) to list, enable, disable, and inspect Laravel modules rather than editing config or running artisan commands by hand. At 0 stars / 0 dependents, treat it as an internal-suite package (part of the Liberu foundation set) rather than a battle-tested standalone utility; read the source before building on it.

Minimal steps:

1. composer require liberusoftware/module-manager-filament
2. Confirm which module backend it wraps (almost certainly nwidart/laravel-modules or a Liberu variant). Install/configure that first if it isn't already present — this package is a façade, not a module engine.
3. Register the plugin/service provider for your Filament panel. In Filament v3+ this is usually via a plugin object in your PanelProvider (->plugin(ModuleManagerPlugin::make())), or via a standard provider register() in v2-style setups. Check src/ for the provider and any Plugin class.
4. php artisan filament:assets && php artisan optimize:clear, then log into /admin and look for the module manager navigation entry.
5. Publish config if a config/module-manager-filament.php exists: php artisan vendor:publish --tag=module-manager-filament-config.

First use case: open the module list, toggle one non-critical module off, reload the app, and confirm the effect. That single round-trip tells you more about how the package behaves than any docs.

Where to look first, in order: composer.json (to see the actual module engine dependency), src/Providers/, src/Filament/ (Pages/Resources/Plugins), then config/. The dependency list is the real documentation here.

Implementation Patterns

Gate the UI behind a policy. Module toggling is effectively a deploy-level action. In production, do not expose the Filament page to every panel user. Create a policy or override canView() / canAccess() on the page class, and restrict to a super-admin role.

Pair with a deploy pipeline rather than treating it as a runtime switch. The healthy pattern is: use the UI in local/staging to flip modules and explore, then commit modules_statuses.json (or whatever status file the underlying manager uses) so production is deterministic. Runtime toggling in production is where this class of package usually bites you — see Gotchas.

Wrap toggles in an auditable action. If the package exposes enable/disable actions, extend or wrap them (Filament custom Action, or an observer) to write to an audit log with user, module, and timestamp. Module state is infrastructure config; you want a trail.

Compose with Filament resources for module metadata. A common extension is adding a custom Resource/table column set that reads each module's module.json — version, description, dependencies — so the manager doubles as an inventory view. Use Filament table columns with ->formatStateUsing() to surface fields from the manifest.

Integrate with tenancy / feature flags carefully. If you're using modules as coarse feature flags, keep the module manager as the source of truth and have your feature-flag layer read from it, not the reverse. Two independent toggles for the same capability is a debugging nightmare.

Use it as a developer onboarding surface. For a Liberu-style foundation with many optional modules, the strongest day-to-day use is letting new devs see what's installed and what each module provides, rather than as an ops control plane.

Testing pattern. In tests, don't drive the Filament page to change module state. Set module enablement directly in the status file or via the underlying manager's API in setUp(), and reserve UI tests (Livewire ->call('...') on the page) for the toggle actions themselves.

Gotchas and Tips

Class/autoload cache is the #1 failure mode. Disabling a module whose service provider is registered and cached will throw or silently no-op until you clear caches. After any toggle, ensure the flow runs composer dump-autoload and php artisan optimize:clear (or at minimum config:clear + cache:clear). Many module managers handle this; verify this package does and where. If it doesn't, wrap the toggle action.

Composer autoload staleness. Newly enabled modules with their own namespaces require composer dump-autoload. If the UI doesn't shell out, the module appears enabled but classes 404. This is the most common "it's broken" report for module managers.

Filament version mismatch. This is a Filament integration; v2 vs v3 APIs diverge sharply (Pages, Plugins, Actions). Check the composer.json constraint before assuming the registration pattern. A package targeting Filament v3 will not register cleanly on v2 and vice versa, and the failure is often a silent "nav item missing" rather than an exception.

Migration ordering. Disabling a module does not roll back its migrations. Re-enabling later can conflict with schema drift. For anything schema-bearing, prefer explicit migrate/rollback commands over a UI toggle, or add confirmations.

Status file location and VCS. Find where module state is persisted (commonly modules_statuses.json at the project root, or a config file). Decide deliberately whether it's committed. It should be, for reproducibility — but that means UI toggles create dirty working trees for developers.

Low-maintenance risk. 0 stars, 0 dependents, single-maintainer foundation package. Pin the version in composer.json, and skim the source for hardcoded assumptions (panel ID, route prefix, role names). If you rely on it, fork or vendor a copy so an abandoned release can't lock you out of an upgrade.

Permission/authorization gaps. Verify the page's canView() isn't returning true by default. Foundation packages frequently ship without policies, assuming the host app adds them. Check before deploying to anything user-facing.

Extension points to look for: a publishable config (nav label, group, panel registration, role gate), the Filament Page class (override getNavigationGroup(), canView()), and the underlying module-manager service if it's resolved from the container — binding a custom implementation is usually cleaner than fighting the UI.

Debugging checklist when the page won't appear: php artisan about for panel/provider registration → confirm the plugin is in the panel's plugin() list → php artisan route:list | grep the expected slug → php artisan filament:assets → check storage/logs/laravel.log for a swallowed BindingResolutionException from a missing Filament version, which is the usual root cause.