Filament Modules Laravel Package

Product Decisions This Supports

• Architecture: modular monolith vs. microservices for the admin surface. The package lets you carve the Filament back office into domain modules (Billing, Inventory, Support) inside one deployable app. That's a decision you can make and reverse cheaply: modules stay cohesive, but you avoid the operational overhead of separate services just to get team boundaries in the admin UI.
• One panel per audience vs. one giant panel. With mode: panels (or both), each module can own its own Filament panel, with links to sibling panels grouped in the main navigation, optional new-tab behaviour, and a back-link to the main panel. This is the decision point for "should Finance and Support see different admin apps?" without building two codebases.
• Build vs. buy on scaffolding. The realistic alternative is hand-rolling panel providers, discovery paths, and generator commands. This package plus nwidart/laravel-modules is the "buy" (well, MIT-license) option: you get module:filament:install, plus generators for resources, pages, clusters, plugins, and panels. Estimate the in-house cost of matching that scaffolding and the ongoing cost of keeping it aligned with Filament major releases before deciding to build.
• Roadmap: path to reuse and eventually extraction. Because each module becomes a self-contained Filament plugin, a module that outgrows the monolith has a credible exit: promote it to a standalone package or a separate product's admin. Fund module boundaries now as an option on future product spin-outs, not as a refactor later.
• Agency / multi-brand portfolio decisions. For shops shipping several similar Laravel+Filament apps, a shared module set is the difference between Nth-project margin and Nth-project loss. This is a "standardise the starter kit" decision, and it's where the package's value is highest.
• Team topology and ownership. Module = squad ownership boundary. This supports decisions about how many teams you can staff against one admin codebase and how review/CODEOWNERS and release cadence are split.
• Access control model (deferred). The package offers Coolsam\Modules\Resource / Page / widget base classes and a CanAccessTrait, but these are explicitly marked WIP. Treat authorization as your decision and your implementation; don't let this package's WIP surface become your RBAC roadmap.

When to Consider This Package

Adopt when most of these are true:

• You're already on Filament 4.x/5.x, Laravel 11–13, PHP 8.3+, and can accept the version lock-step in the support matrix (every Filament major is a package major — plan the upgrade as a project, not a patch).
• You have three or more clearly separable domains in the admin, with different stakeholders, release cadence, or eventual ownership.
• You're already using, or are willing to adopt, nwidart/laravel-modules — this is a wrapper, so that package's conventions, docs, and quirks become yours. Don't adopt it for a one-module need.
• You can handle the merge-plugin autoload requirement in composer.json. Verify this against your CI, Docker build, and production deploy pipeline; it changes how Composer resolves module autoloads and is a real operational dependency, not a config detail.
• You have the appetite to pin versions, read the changelog, and fork if necessary. Signals to weigh: ~212 GitHub stars, zero dependents on Packagist, a effectively single-maintainer credit, and a low opportunity score relative to mainstream Filament tooling. That's not disqualifying for an internal-use MIT package, but it means you are the support contract.
• You want the reuse-across-projects payoff. If you only ever ship one app, modules are pure ceremony.

Look elsewhere (or defer) when:

• You're on Filament 3.x or Laravel 10 — you'd need the 4.x/3.x docs branches, which means starting on a legacy branch.
• You need stable, documented access control today — the protection layer is WIP.
• You need widgets and theming generators in production — both are marked WIP; budget for hand-writing them.
• You need vendor SLA, security-response guarantees, or an ecosystem of examples — the dependents count tells you the community answer.
• You have one panel, one domain, one team. Plain Filament panel providers with discoverResources()/discoverPages() cover it, and you skip two third-party dependencies entirely.
• Your org has a strict third-party dependency policy or a low tolerance for a wrapper that tracks two upstreams' release cadence simultaneously.

Recommended de-risking before commitment: a timeboxed spike — install into a throwaway branch, generate two modules with clusters and one module panel, run it through your deploy pipeline, and confirm the panel-scoping story ("this package wires modules and panels together but does not override Filament's per-panel registration model" — so your discovery config is still yours to get right).

How to Pitch It (Stakeholders)

For executives (one paragraph): Our admin back office is on Filament, and right now every new domain adds more files to one undifferentiated pile. This MIT-licensed package lets us split the admin into self-contained modules, each optionally its own panel, while staying a single app and a single deploy. The upside is faster parallel delivery across teams, a credible path to reusing modules across products or client projects, and an option to spin a module out as a standalone product later without a rewrite. The cost is adoption effort, a small amount of architectural discipline, and a dependency on a young, thinly-adopted open-source package maintained by one person — which we mitigate by pinning versions, forking if needed, and keeping our own tests around the boundary. Net: low cash cost, moderate technical risk, and it buys us organisational flexibility we can't easily retrofit.

For engineering (the short version): It's a thin wrapper over nwidart/laravel-modules that turns each module into a Filament plugin, adds generators (module:filament:install, module:make:filament-{resource,page,cluster,plugin,panel}), and gives you config for plugins / panels / both discovery modes, auto-registration, cluster layout, and panel grouping in navigation. Requirements are Laravel 11–13, Filament 4/5, PHP 8.3+, and you must configure laravel-modules and the Composer merge-plugin autoload before it works. Watch-outs: versions are lock-stepped to Filament majors, access-control base classes and the widget/theme generators are WIP, and per-panel resource scoping is still plain Filament discovery — the package doesn't abstract it away. Plan to pin, fork if necessary, and own the upgrade path ourselves.

Ask: approve a short spike (a day or two) to validate the install and deploy story and confirm the version matrix against our current Filament release, then a go/no-go on adopting it as the standard structure for the admin.