Laravel Module Installer Laravel Package

Product Decisions This Supports

• Modular monolith vs. distributed services. If you're weighing "split into microservices" against "keep one Laravel app but organize by module," this package is the enabler that makes the monolith defensible: modules stay in Modules/, but they can be versioned, published, and installed like dependencies. That's a middle path — modularity without the operational cost of separate deployables.
• Feature-as-a-package roadmap. Supports decisions to ship premium/optional capabilities (add-ons, paid tiers, regional variants, white-label features) as independently versioned Composer packages rather than feature flags in one repo. Commercially this unlocks per-module licensing and per-module release cadence.
• Build vs. buy on internal platform tooling. The plugin itself is a small Composer installer (type mapping + install path). The real buy/build question is whether to write and maintain that glue yourself. Buying it costs one dependency; building it costs ~a few hundred lines plus Composer API churn forever.
• Repo topology decisions. Makes "one Composer package per module" viable, so it informs whether your modules live in a monorepo with path repositories, in separate Git repos, or on a private Packagist/Satis. This decision usually precedes any code being written.
• Multi-product reuse. Enables a shared module library consumed by several Laravel applications (e.g., a customer portal and an internal admin), with a single upgrade path via composer update instead of copy-paste drift.
• Third-party/partner extensibility. If you ever want external teams to contribute modules, standardizing on the nwidart/laravel-modules contract plus Composer distribution gives you a real plugin ecosystem story.
• Opportunity signal. The high opportunity score combined with a stalled release cadence is itself a product datum: the underlying need (Composer-distributed Laravel modules) is real and underserved, which argues for internalizing the 200-line glue rather than depending on a volunteer maintainer.

When to Consider This Package

Adopt (or fork) when all of these hold:

• You already use or have committed to nwidart/laravel-modules — this package is meaningless outside that ecosystem.
• Modules need to be installed via Composer from a VCS/private Packagist/Satis source, and you specifically want them landing in Modules/ rather than vendor/.
• Module install paths must be deterministic across developer machines, CI, and production deploys — i.e., you can't tolerate "run this artisan command after install."
• You're prepared to pin the version and verify the composer-plugin-api constraint covers your Composer minor version (Composer 2.2+ tightened plugin permissions — audit that allow-plugins works and that the plugin declares a compatible API range).

Look elsewhere — or don't adopt at all — when:

• Greenfield or single-repo. path repositories in composer.json (with symlinks) solve the same problem natively, with zero plugin surface and zero abandonment risk. This is the default recommendation unless you truly need remote distribution.
• You need maintained dependencies. Last release is January 2021; that's several Composer majors, PHP 8.x generations, and nwidart/laravel-modules majors of unverified compatibility. Treat it as abandoned and assume you own it.
• You want maintained, general-purpose tooling. oomphinc/composer-installers-extender layered on composer/installers supports arbitrary custom package types with installer-paths, and is actively maintained — a lower-risk substitute for the same behavior.
• You're not doing modular-monolith at all. If your answer to "do we need modules as packages?" is no, this adds a Composer plugin (supply-chain and CI risk) to buy nothing.
• You can't fork. If nobody on the team can read ~200 lines of Composer plugin code and patch it, this dependency will eventually block a Composer or PHP upgrade at the worst possible time.

Diligence checklist before committing: confirm Composer 2.2 allow-plugins behavior, confirm compatibility with your nwidart/laravel-modules major, confirm PHP 8.2/8.3 support, and confirm the install path is configurable enough for your layout.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're choosing a modular architecture so features can be built, released, and even sold independently instead of riding one monolithic release train. This package is a small but load-bearing piece of plumbing that lets a Laravel module be installed like any other dependency, into a predictable Modules/ folder. It's MIT-licensed, tiny, and does one job. The caveat a non-technical stakeholder needs to hear: it hasn't been updated since 2021, so we should treat it as code we own — either by vendoring/forking it or using a maintained equivalent — and that decision is a half-day of engineering, not a project. Net effect: it protects the roadmap by letting us ship modules on their own schedule.

For engineering (one paragraph): It's a Composer plugin that registers an installer for the laravel-module package type so nwidart/laravel-modules packages install into Modules/ instead of vendor/. That's the whole feature. The risk is entirely lifecycle, not design: unmaintained since Jan 2021, so verify the composer-plugin-api range against our Composer version and PHP 8.x, and confirm compatibility with whatever nwidart/laravel-modules major we pin. Recommendation: don't take it as a blind dependency — fork it into our namespace (~200 LOC), or use oomphinc/composer-installers-extender + composer/installers with an installer-paths mapping if we'd rather stay on maintained tooling. If we don't actually need remote distribution, use path repositories and skip this entirely.

Recommendation: Conditional adopt. Use it only as part of a deliberate modular-monolith platform decision; budget an owner, a fork or a maintained alternative, and a compatibility spike before it enters composer.json.