Modules Laravel Package

Product Decisions This Supports

• Modular monolith vs. microservices: This package makes a modular monolith a viable admin-panel strategy. If we adopt nWidart/laravel-modules for domain separation, this lets each domain module own its Filament resources, pages, and widgets — so the architecture decision and the admin UI decision stay aligned instead of drifting.
• Build vs. buy for admin scaffolding: Rather than building an in-house module-aware Filament loader (resource discovery, panel registration, per-module providers), we can adopt this and redirect engineering time to domain features. This is a small, MIT-licensed, single-purpose dependency — cheap to try, cheap to remove.
• Team topology and ownership boundaries: Per-module Filament files map cleanly onto team ownership. If we organize squads by domain, this reduces cross-team merge conflicts in a shared app/Filament directory and makes code review ownership obvious.
• Roadmap sequencing for a modular admin panel: This is an enabler, not a feature. Sequence it before we commit to a modular admin roadmap — deciding later means retrofitting existing resources into modules, which is materially more expensive than starting modular.
• Multi-tenant / multi-panel product direction: If the roadmap points toward separate panels per module or tenant (e.g., a Billing admin surface distinct from a Catalog one), module-scoped Filament files are the natural unit of composition. This is a prerequisite worth validating now.
• Developer onboarding cost: New engineers can be pointed at one module directory and see models, migrations, routes, and Filament UI together. That's a measurable reduction in time-to-first-PR and a defensible argument in headcount planning.

When to Consider This Package

Adopt when:

• We are already on (or are committing to) Filament v3/v4 and nWidart/laravel-modules. This package is glue — it has no standalone value without both parents.
• Our admin surface is large enough that a single app/Filament tree has become a merge-conflict hotspot or an ownership gray zone.
• We have, or want, a domain-boundary convention and need the admin layer to respect it rather than leak across modules.
• We're comfortable with a small, community-maintained OSS dependency and can absorb the integration work ourselves if upstream stalls.

Look elsewhere when:

• The application is a straightforward monolith. Adopting laravel-modules purely to use this package is a large architectural commitment justified by a small tool — do not let the tail wag the dog.
• We need enterprise support, SLAs, or a vendor to call. The repo shows a single maintainer, ~212 stars, and 0 dependents — that is a genuine sustainability signal, not a footnote.
• We need capabilities outside its scope: it does not solve authorization policy design, panel-level tenancy, or Filament theming. Those remain our responsibility.
• We require strict version-pinning across Filament majors. A third-party integration layer between two fast-moving frameworks is a recurring upgrade tax; budget for it each time Filament ships a major.
• Our team has no existing Filament expertise. The dependency stack (Laravel + Filament + laravel-modules + this) is three layers deep; debugging failures spans all four projects.

Mitigations if we proceed: pin versions, add an integration test that boots a panel from a module, write an internal ADR, and identify an internal owner. Treat "0 dependents" as a prompt to do a two-week spike rather than a permanent commitment.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source adapter that lets our admin interface be organized the same way as our application's business domains. It costs roughly a spike to evaluate and is removable if it disappoints. The upside is developer throughput and cleaner ownership boundaries as the admin surface grows; the downside is dependency risk from a single-maintainer project, which we contain through version pinning and an internal owner rather than a contract.

For engineering: It's the official-feeling bridge between Filament and nWidart/laravel-modules — you get module-scoped resources, pages, and widgets instead of one sprawling admin directory. Two caveats to plan around: it's a one-person project with negligible downstream adoption, so we own the upgrade path when Filament ships a major; and it's only worth adopting if we're genuinely committed to the modular structure. Recommendation: timeboxed spike on one module, measure the diff in conflicts and onboarding time, then decide.