Laravel Module Loader Laravel Package

Product Decisions This Supports

• Modular monolith vs. microservices: Use this package's module concept as a cheap way to prototype service boundaries before committing to distributed infrastructure. If contextual modules can be defined cleanly inside one Laravel app, that is evidence a monolith is still viable for the next 12–18 months.
• Feature-to-domain mapping: It forces an explicit decision about which bounded context (Billing, Catalog, Identity, Notifications) owns each new feature. That mapping is the artifact PMs need for roadmap sequencing and for negotiating scope with engineering.
• Build vs. buy vs. borrow: The package itself is a buy/borrow candidate only for the organizational convention, not the runtime. Because it is deprecated, the realistic decision is "build the convention in-house, using this repo as a reference design," which is a much smaller commitment than adopting a framework.
• Team-scaling roadmap input: Module boundaries map naturally to squad ownership. This informs hiring plans and the decision of when to split a growing engineering team along domain lines versus feature lines.
• Migration and re-platform planning: If the roadmap includes a future extraction of a domain (e.g., moving Billing to a separate service), module isolation today reduces the cost of that extraction later. This is a concrete input to technical-debt and platform-investment prioritization.
• Use cases it does not support: It is not a plugin/extension system for third-party developers, not a multi-tenancy mechanism, and not a substitute for proper package architecture when modules need independent release cycles.

When to Consider This Package

Consider the pattern (not the dependency) when:

• The codebase is a single Laravel application that has grown past the point where app/Models, app/Http/Controllers, and app/Services communicate ownership, and engineers are regularly touching unrelated files to ship one feature.
• You have, or expect to have, more than one squad and need a defensible convention for "who owns what."
• You are planning a modular monolith and want a low-ceremony reference for directory structure and module registration — this repo is a readable, MIT-licensed example.
• You are evaluating module systems and want to compare a minimal convention-first approach against heavier alternatives (e.g., nwidart/laravel-modules) before writing your own ADR.

Look elsewhere — or do not adopt the code at all — when:

• You would be adding the Composer dependency. It is marked deprecated, archived, and has had no release since March 2021. Laravel's major-version cadence since then means compatibility is unverified, and there is no maintainer to patch a break. Treat it as read-only reference material.
• You need guaranteed support, security response, or upgrade paths. Deprecated packages fail procurement and security review for anything customer-facing or regulated.
• You need independently versioned, independently deployable modules. That is a package/plugin architecture problem; a lightweight loader will not carry it.
• Your team is small and the app is small. A convention with no enforcement is overhead; folder structure alone is sufficient.
• You need first-class tooling — module-level test isolation, asset publishing, migration scoping. Mature, actively maintained alternatives exist and are worth the heavier footprint.
• The organization cannot own a fork. If nobody will maintain the convention internally, the deprecation is a hard stop rather than a caveat.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated laravel-module-loader as a way to organize our Laravel codebase into business-domain modules. The package itself is deprecated and unmaintained since 2021, so I am not recommending we adopt it as a dependency — that would add unsupported code to our stack for no gain. What I am recommending is that we borrow its structure: a small internal convention that groups code by business domain rather than by technical layer. This costs roughly one engineering week, carries no vendor or licensing risk (MIT), and buys us two things: clearer ownership as the team grows, and a cheaper path if we ever need to extract a domain into its own service. It is a low-cost option on future architecture, not a platform commitment.

For engineering leadership:

• Status: Deprecated, archived, 75 stars, last release 2021-03-11, MIT. Not suitable as a production dependency.
• What we take: The module-registration convention and directory layout. Small surface area, easy to reimplement in-house in a day or two, and easy to reverse.
• What we leave: The Composer package, its service provider, and any autoloading behavior we have not verified against our Laravel version.
• Risk: Near zero if we treat it as a design reference; high if we add it to composer.json and forget about it.
• Decision requested: Approve a short internal spike to codify a domain-module convention, with an ADR documenting the choice and a review at the next architecture checkpoint.
• Success signals: New features touch fewer unrelated directories; PR review identifies an owning domain without asking; module boundaries survive one quarter without ad-hoc exceptions.