Filament Module Manager Laravel Package

Technical Evaluation

Architecture fit. The package is a thin Filament v4 plugin that registers one admin page and one dashboard widget against nwidart/laravel-modules. It does not introduce new abstractions, persistence, or side channels — it reads module state from Nwidart's registry and exposes enable/disable toggles through Filament's page contract. For any Laravel monolith already running Filament for back-office and Nwidart for domain modularization, the fit is near-ideal: zero schema changes, zero new runtime dependencies beyond what the team already has.

Integration feasibility. Registration is a single ->plugin(ModuleManagerPlugin::make()) in the panel provider. There is no service provider bootstrapping complexity, no config publishing required for baseline use, and no middleware surface. A junior engineer can wire it in under an hour. The real cost is not installation but governance of the actions it exposes.

Technical risk. This is the dominant concern. The repository is archived, has 20 stars, 0 dependents, and a 0.14 composite score against a 12.03 opportunity score — a classic signal of genuine ecosystem demand with essentially no supply-side maturity. Practical risks:

• No upstream security patching or Filament v5 tracking.
• Single-maintainer abandonment already realized.
• Filament v4 is itself a young major version; the plugin's API surface is narrow and will drift.
• The widget performs state-mutating actions (module enable/disable). A misclick in production can deregister service providers, orphan migrations, or break autoload maps.
• No evidence of test coverage or CI.

Key questions for the adopting team.

1. Are we on Filament v4 today, or is v3 still in the estate?
2. Is nwidart/laravel-modules already standardized, or is this the wedge that introduces it?
3. Do we need runtime module toggling, or is deploy-time composition sufficient? (If the latter, this plugin solves a problem we don't have.)
4. Who owns the fork, and what is the review cadence for Filament major bumps?
5. What is the permission boundary — super-admin only, or delegated?

Integration Approach

Stack fit. TALL stack (Laravel 11/12, PHP 8.2+, Filament v4, Livewire 3, Nwidart Modules ^11/^12). The plugin assumes all of these are already present and correctly versioned. It is not a bootstrap tool — it is a console for an existing modular architecture.

Recommended path: vendor-fork, not dependency. Given the archived state, composer require alizharb/filament-module-manager is the wrong move. Instead:

1. Fork into the internal Git org under MIT.
2. Publish to a private Composer registry (Satis, Private Packagist, or a VCS repository entry).
3. Tag 1.0.0-internal, pin exactly, and treat it as first-party code.

This costs roughly a day and converts an unmaintained third-party risk into an owned, auditable internal component — which is the correct trade for a ~200–400 LOC surface area.

Migration path. For greenfield Filament panels, drop the page behind a canAccess gate from day one. For existing panels, stage it in a non-production panel first and validate against the current Nwidart module set. If the estate is on Filament v3, do not attempt to backport — the page/widget contracts differ materially; budget a rewrite or defer.

Compatibility surface to verify before merging.

• Filament ^4.0 pinned in composer.json.
• Nwidart major version alignment with the host app's modules_statuses.json format.
• Livewire version parity (v4 requires Livewire 3).
• PHP 8.2+ floor.

Sequencing.

1. Confirm Filament v4 + Nwidart are already in the target panel (week 1, 1 hr).
2. Fork, run composer audit, add a smoke test around page registration and widget render (week 1, 1 day).
3. Gate behind super_admin and add an audit log on toggle events (week 2).
4. Deploy to staging, exercise a full enable → migrate → disable cycle (week 2).
5. Promote to production behind a feature flag; monitor for panel boot failures (week 3).

Operational Impact

Maintenance. Archived means zero upstream support. Effective ownership transfers entirely to the adopting team. Realistic ongoing cost: 2–4 hours per quarter plus a half-day per Filament major release. That is cheap for a component this small, but it must be scheduled, not implicit — archived dependencies that nobody owns are the ones that break on a Friday.

Support model. No vendor, no maintainer, no issue tracker that will be answered. Internal Slack channel + named owner is the entire support structure. Document the fork in the platform runbook alongside the Filament upgrade checklist.

Scaling. Runtime cost is negligible — an admin page and a dashboard widget that read a JSON status file. The operational scaling concern is different: module toggling is a shared mutable state that all environments and all developers observe. On a multi-tenant or multi-panel deployment, uncoordinated toggles become a class of "works on my machine" incidents. Constrain write access accordingly.

Failure modes to instrument.

• Panel boot failure — a disabled module whose service provider is still referenced in composer.json autoload or bootstrap/providers.php. Symptom: 500 on every Filament route. Mitigation: toggle guardrails + a rollback command.
• Stale module cache — Nwidart caches modules_statuses.json; a toggle without php artisan module:clear-compiled or equivalent produces phantom state.
• Migration drift — enabling a module whose migrations were never run, or disabling one whose tables other modules FK into.
• Class-not-found after Filament upgrade — the pinned v4 API contract breaks silently at boot.
• Permission leak — the page registered without a gate, exposing toggles to any panel user.

Ramp-up. For a mid-level Laravel engineer: ~2 hours to read the plugin end-to-end (it is small enough to read fully), ~1 day to fork, gate, and test. There is no exotic domain knowledge — the learning curve is Nwidart's module lifecycle, not this plugin. That is, in fact, the strongest argument for the fork: the code is legible, the scope is bounded, and the replacement cost is measured in days rather than sprints.

Bottom line for the TPM. Do not adopt as a live dependency. Treat it as a reference implementation and a 1-day internal build/fork. The opportunity score is real — there is a genuine gap here — but at 20 stars and archived, the package is a starting point, not a product.