Laravel Modular Laravel Package

Product Decisions This Supports

• Architecture bet: modular monolith vs. microservices vs. flat Laravel app. This package makes the modular monolith a credible middle path — domain isolation (modules/Shop, modules/Blog) with strict dependency ordering (topological boot resolution), without paying the distributed-systems tax. That's a roadmap-level decision this package directly de-risks.
• Build vs. buy on internal scaffolding. The alternative is spending engineering weeks on home-grown module tooling (autoloading, generators, migration scoping). 29+ overridden Artisan commands with a --module flag means near-zero retraining cost — the counterfactual cost is real and this collapses it.
• Feature packaging and monetization. module:enable / module:disable plus @moduleEnabled Blade directives turn modules into runtime feature flags — enabling tiered plans, per-tenant entitlement sets, or add-on packs without redeploying divergent codebases. That is a product decision, not just an engineering one.
• White-label / agency distribution model. Modules can be turned on or off per deployment, and modular:export promotes a module to a standalone Composer package — a viable path for customer-specific builds or spinning a module out as a sellable product.
• Team topology and parallel workstreams. Module-scoped modular:migrate, modular:test, modular:npm, and per-module stubs let squads own a vertical slice end-to-end with enforced conventions. Supports decisions about how many squads we can add before coordination cost dominates.
• Frontend/build strategy. Vite integration with HMR and NPM workspaces per module — relevant if we're deciding whether module teams can own their own asset pipelines.
• Extraction trigger. If a module's scale or compliance needs change, modular:export gives a low-friction exit into a service or package. That reduces the irreversibility of committing to the monolith.

When to Consider This Package

Consider it when:

• You're greenfield or restructuring on Laravel 11/12, PHP 8.2+, and the domain count is trending past ~6–8 or teams past ~3.
• You need runtime module activation for licensing, tiering, or per-customer configurations — this is the package's sharpest differentiator versus folder-structure conventions.
• You want strict typing, PHPStan, and a test suite as table stakes, not an afterthought.
• You can absorb early-stage dependency risk: 23 stars, 0 dependents, a single-maintainer ecosystem (Filament/Livewire/Themer/Hooks integrations are all from the same author). MIT license means forking is a legitimate mitigation.
• You're prepared to own the operational detail the README itself flags — running modular:sync and disabling composer-merge-plugin in production, and modular:cache in the deploy pipeline.

Look elsewhere when:

• Single team, single product, under ~5 domains. Laravel's own app/ conventions and plain namespaces will cost less than any module system.
• Laravel 10 or earlier — not the target.
• You need a large community, years of StackOverflow answers, and third-party tutorials: nwidart/laravel-modules is the incumbent and warrants a formal head-to-head before adoption. Run both against our actual generator and migration workflows.
• You require a vendor SLA, security-response commitments, or procurement-approved support.
• The team won't maintain module boundaries voluntarily — a module system without architectural discipline just produces a distributed mess in one repo.

Recommendation: bounded pilot, not a platform commitment. Adopt on one non-critical module for two sprints; exit criteria = no measurable prod overhead after modular:cache, generators used by the team unaided, and a clean modular:export of that module.

How to Pitch It (Stakeholders)

To executives: We're choosing an application structure now that will constrain how fast we can ship and how we package what we sell for the next several years. This package gives us a modular monolith — separated domains inside one deployable — with per-module on/off switches. Practically: we can sell tiered or per-customer feature sets without running separate codebases, onboard a new squad without them colliding with existing ones, and later extract a module into its own product or service without a rewrite. The cost is a small integration effort and a dependency that is early-stage and single-maintainer — which we mitigate by piloting it on one non-critical module and keeping the MIT-licensed fork option open. I'm asking for a two-sprint pilot, not a platform bet.

To engineering: No new mental model. The standard commands you already type — make:model, make:controller, make:migration — take a --module flag and behave as you expect, with -mcf and --all intact. You get zero-config autoloading via a Composer merge plugin, topological dependency resolution so base modules boot first, auto-discovery of commands, policies, and listeners, module-scoped migrations/seeds/tests, and per-module stubs to enforce conventions. Discovery caching means near-zero production overhead; the README is explicit that we should run modular:sync and drop the merge plugin before shipping. Vite and NPM workspaces are supported per module, so frontend ownership isn't blocked. The risks are maturity and bus factor — 23 stars, no downstream dependents — so we pin a version, review the changelog before upgrades, and treat the pilot as an evaluation with a real off-ramp.