Filament Modular Laravel Package

Product Decisions This Supports

• Build vs. buy for admin scaffolding. If your product is organized into nwidart/laravel-modules domains and your admin UI is FilamentPHP, this package replaces hand-written service-provider glue that registers each module's Filament resources, pages, and widgets into panels. The decision it informs is: "do we write ~30–100 lines of registration boilerplate per module ourselves, or adopt a package that does it?"
• Feature/module architecture for the admin layer. It supports the call to keep Filament artifacts (Resources, Pages, Widgets) co-located inside their domain module rather than in a monolithic app/Filament tree — which matters for team ownership, code review boundaries, and eventual extraction of modules into separate packages.
• Roadmap: pluggable / white-label / multi-tenant direction. Modules that can ship their own admin surfaces are a prerequisite for selling or reusing "module kits" (agency reuse, per-tenant feature flags, marketplace-style add-ons). This package is a cheap way to validate that direction before committing engineering time.
• Use cases where it fits: large admin panels with 20+ resources across distinct domains; agencies maintaining a reusable module library across client projects; teams already standardized on nwidart modules and unwilling to re-architect.
• Use cases where the decision should be "no": a single-domain app with 1–3 resources (premature modularization adds ceremony with no payoff), or a greenfield build targeting current Filament.

When to Consider This Package

Adopt (with guardrails) when:

• You are already using nwidart/laravel-modules and FilamentPHP — this package is a bridge, not a reason to adopt either.
• You have enough modules that per-module Filament registration boilerplate is real, recurring friction (roughly 5+ modules).
• You have verified Composer constraints against your actual Filament and Laravel versions. With a last release of 2023-04-24, expect support to top out around Filament v2/v3 — confirm before assuming v4 compatibility.
• You are willing to vendor or fork it. At 61 stars and no release in over a year, treat it as source code you own, not a maintained dependency.

Look elsewhere (or build it yourself) when:

• You are starting greenfield on a current Filament release. Native panel providers plus discoverResources/discoverPages in a per-module provider cover most of this with zero dependencies.
• You need a vendor SLA, security patching, or active issue triage. This does not provide it.
• Your "modules" are really just folders. Filament's built-in multi-panel and discovery features may be sufficient; modularity is an organizational commitment, not a config flag.
• Alternatives to weigh: a thin in-house module-aware panel provider (low effort, full control), or Filament's native multi-panel support if the goal is separating admin surfaces rather than domain encapsulation.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed adapter that lets our admin panel grow in the same modular shape as our backend domains. Cost is effectively zero and it removes repetitive wiring per feature area, which speeds up delivery as the number of modules grows. The trade-off is maintenance risk: the project is low-adoption (61 stars) and has not shipped since April 2023. Recommendation is to adopt it as a pattern and starting point — copy or vendor the code into our repo — rather than as a live third-party dependency we depend on someone else to maintain. That caps downside while preserving the speed benefit.

To engineering: It's a thin integration layer between nwidart/laravel-modules and FilamentPHP that registers each module's resources, pages, and widgets into panels automatically. It saves boilerplate we would otherwise write and maintain ourselves. Before adopting, we need a compatibility check against our Filament and Laravel versions, and we should plan to own the code — pin, vendor, or fork. If the compatibility check fails or we're on a newer Filament major, the fallback is a ~50-line module-aware panel provider in-house, which delivers most of the same value with no external dependency.