Filament Modules Laravel Package

Technical Evaluation

Architecture fit. This is an adapter, not a framework. It wraps nwidart/laravel-modules so that each Laravel module can expose itself as a Filament plugin, cluster, and optionally its own panel — plus a set of module:filament:* generators that place resources/pages/widgets inside the module namespace instead of app/Filament. That means the package contributes almost no runtime of its own; the architecture you are actually adopting is laravel-modules + Filament, and this package is the glue that makes the two agree on discovery. Fit is therefore conditional: strong if the org has already standardized (or is willing to standardize) on nwidart modules as the vertical-slice boundary; near-zero value if Filament code is expected to stay in app/Filament with a conventional monolith layout.

Integration feasibility. Mechanically easy. One composer require, one published config (config/filament-modules.php), one line in the panel provider (->plugin(ModulesPlugin::make())), and generator commands per module. The composer constraint auto-resolves a compatible laravel-modules major (^11/^12/^13 for Laravel 11/12/13), which removes the most common dependency-hell question. The one non-trivial prerequisite is adding the merge-plugin block to the root composer.json so Modules/*/composer.json are autoloaded — that is a global build-pipeline change, not a package-local one, and it needs to be socialized with whoever owns CI.

Technical risk. Three concerns, in order:

1. Version-window tightness. v5.x supports only Laravel 11/12/13, Filament 4/5, PHP 8.3+, laravel-modules 11–13. The package follows upstream, not the reverse — every Filament major effectively forces a package major. Treat filament + laravel-modules + coolsam/modules as a single atomic upgrade unit in the dependency policy.
2. Bus factor / adoption. One primary maintainer, ~212 stars, zero dependents recorded in this dataset. There is no peer corpus of reference implementations to borrow patterns from, and no commercial support path. Positive counter-signals: MIT license, CI with Codecov, automated changelog/release PRs — release hygiene is better than the star count suggests.
3. WIP surface. Widget generation, theme generation, and the entire "protecting your resources/pages/widgets" access-control layer are explicitly marked WIP in the README. The Coolsam\Modules\Resource / Page / TableWidget base classes must not be used as an authorization boundary. Also note the vendor-name mismatch across sources (savannabits/filament-modules vs. composer package coolsam/modules vs. repo coolsam726/filament-modules) — pin the exact Packagist name and verify the publisher before the first install.

Key questions.

• Is nwidart/laravel-modules already an accepted architectural decision here, or would this package be smuggling it in?
• Do we need per-module panels (mode: panels|both), or is one admin panel with per-module clusters sufficient? Panels mode multiplies panel providers and navigation complexity for a benefit that is mostly cosmetic.
• Who owns the fork if a Filament minor breaks plugin discovery and upstream is slow?
• What is panel boot-time cost with N modules auto-registered? Is registration eager on every request?
• Does merge-plugin interact acceptably with our lockfile determinism and container build cache?
• What is the deprecation path if this package goes stale — how many files would we have to touch to inline the glue ourselves?

Integration Approach

Stack fit. Prerequisites are hard: PHP 8.3+, Laravel 11+, Filament 4/5, laravel-modules 11+. A team on Filament 3 must use package v4.x (Laravel 11/12 only) and a team on Laravel 10 is stuck on v3.x — that is a fork in the road, not a detail. Confirm the Filament major before evaluating anything else; the rest of the assessment is moot if you are pre-Filament-4 with no upgrade budget.

Migration path (brownfield, incremental). Do not big-bang. Sequence:

1. Adopt nwidart/laravel-modules alone and prove module autoloading works in CI and in the container image. This is the risky step; validate it in isolation.
2. Install this package with mode: plugins and auto-register-plugins: false — explicit registration gives you a controlled rollout and a per-module kill switch. Register ModulesPlugin on the admin panel.
3. Pilot one module: module:make, then module:filament:install with clusters enabled. Move one low-risk resource into it. Ship it. Measure.
4. Enable auto-register-plugins: true only once the team trusts discovery.
5. Migrate remaining resources module-by-module, domain-aligned. Each move is independently revertible (drop the module from the merge-plugin include, or flip its registration off).
6. Evaluate mode: panels last, only if a module genuinely needs an isolated panel experience.

Compatibility. Pin the triple explicitly in composer.json (filament/filament, nwidart/laravel-modules, coolsam/modules) and document that they upgrade together. Add a CI matrix job that runs the package's supported-version combination against your app's test suite — this package's version matrix is broad but its real-world coverage on your Filament version is unknown.

Sequencing / ownership. Front-load the convention decision: what constitutes a module, when a cluster is created versus a page, and who can run generators. Generators are cheap and fast, which is exactly why unchecked use produces namespace and panel-scoping drift. Document the per-panel discovery rules (the README is explicit that panel scoping is governed by Filament's own discoverResources()/discoverPages()/discoverWidgets() — this package wires modules to panels but does not override per-panel registration).

Operational Impact

Maintenance. Low surface, low churn: the package is a thin wrapper, and releases are automated with changelog PRs. The maintenance burden is not the package's code, it is tracking two upstream majors. Budget one upgrade sprint per Filament major release, and expect this package to lag upstream by a short window rather than lead it. Assign a named owner — with one maintainer upstream, an unowned dependency here becomes an unpatched one.

Support. MIT, community-only, GitHub issues, no SLA, no vendor escalation. The realistic escalation path is a fork. Before adoption, confirm the team has someone who can read Filament's plugin-discovery internals and patch a wrapper in an afternoon. If not, this is a latent blocker rather than a convenience.

Scaling. Scales organizationally far better than it scales technically. Per-module clusters give clean navigation and clean ownership boundaries as headcount grows — that is the real payoff. Technically, watch two things: panel boot cost with N auto-registered plugins (measure time-to-first-byte on the admin panel at 1, 5, and 15 modules before committing to auto-register-plugins: true), and provider count if you enable panels mode. Neither is likely fatal at typical module counts, but neither is documented, so measure rather than assume.

Failure modes.

• Silent autoload failure. A malformed merge-plugin include or a module removed from the glob produces class-not-found at runtime instead of build time. Mitigate with a smoke test that boots the panel and asserts plugin registration.
• Filament minor bump breaking discovery or generator signatures. Detect via the CI matrix; do not rely on manual QA.
• Authorization drift. Auto-registration exposes module resources in navigation; navigation is not authorization. Enforce Filament policies per resource and treat the WIP Coolsam\Modules\* base classes and CanAccessTrait as unavailable until they are declared stable.
• Generator drift. Files written to unexpected namespaces or the wrong panel subdirectory, causing resources to be discovered by zero or multiple panels. Mitigate with a documented folder convention plus a review checklist on generated code.
• Panel sprawl. Panels mode without a real requirement yields multiple providers, duplicated navigation, and a confusing UX. Default to clusters.

Ramp-up. A Filament-fluent developer is productive in half a day: the command names are aliased three ways and the config keys are few. The real ramp is the team convention — one to two weeks to settle module boundaries, cluster-versus-panel policy, and generator review rules. Note that the dominant learning curve is nwidart/laravel-modules itself, not this package; the README says as much by requiring you to configure laravel-modules first. Plan onboarding around the underlying module system and treat this package as a one-page addendum.

Bottom line. Worth adopting only as the payoff of a deliberate modularization strategy — it is a cheap accelerator on top of an expensive decision, not a reason to make that decision. Gate adoption on: Filament 4+ already in place, laravel-modules accepted, a named owner able to fork, and agreement to keep authorization in Filament policies rather than in this package's WIP classes.