Laravel Module Installer Laravel Package

Technical Evaluation

Architecture fit. joshbrw/laravel-module-installer is not a runtime library — it is a Composer plugin that registers a custom installer for packages declaring "type": "laravel-module", redirecting their install path from vendor/ to the application's Modules/ directory. This makes it an install-time concern only: no service provider, no runtime coupling, no autoload surface added to the app. For teams already using nwidart/laravel-modules and distributing modules as Composer packages, the fit is clean and the blast radius is small because the plugin is inert outside composer install/update.

Integration feasibility. Feasible but conditional. It requires (a) nwidart/laravel-modules conventions in the consuming app, (b) each module published as a Composer package with type: laravel-module, (c) a repository entry (VCS, path, or private Packagist) for those modules, and (d) Composer plugin execution permitted. The last point is the practical blocker: since the last release (Jan 2021), Composer 2.2+ introduced the allow-plugins secure default and Composer 2.5 hardened it. Any environment that has not explicitly allowed this plugin will fail installs or, worse, silently resolve modules into vendor/.

Technical risk. High for a 171-star, single-purpose plugin last released in 2021:

• Composer API drift. The plugin must declare a composer-plugin-api constraint compatible with the installed Composer binary. A 2021-era constraint is likely incompatible with current Composer 2.x lines and will either be rejected or force a Composer downgrade.
• Maintenance abandonment. No releases in ~4 years means no fixes for Composer 2.2/2.5 plugin governance, PHP 8.2/8.3 deprecations, or nwidart/laravel-modules v10/v11 changes.
• Supply-chain exposure. Composer plugins execute arbitrary code at install time with the developer's privileges; enabling one that is unmaintained is a security posture decision, not just a compatibility one.
• No visible test or CI signal in the package metadata to confirm current behavior.

Key questions.

1. What composer-plugin-api constraint does the current tag declare, and does it install without --ignore-platform-reqs on our Composer version?
2. Does it degrade gracefully under Composer 2.2+ allow-plugins, and what is the exact allow-list entry?
3. Is nwidart/laravel-modules v10+/v11 supported, or only the older Modules/ layout?
4. Is there a maintained alternative — composer/installers + oomphinc/composer-installers-extender type mapping, or a path-repository strategy — that removes the dependency entirely?
5. What is the bus factor, and are we prepared to fork and vendor the plugin internally?

Integration Approach

Stack fit. Valid only for Laravel applications on nwidart/laravel-modules that consume modules as external Composer packages. If modules live in-repo (the common case), the plugin adds no value and should not be introduced. It is a fit for platform teams distributing a shared module catalog to multiple downstream apps.

Migration path. Three viable routes, in order of preference:

1. Avoid the dependency. Use composer/installers with oomphinc/composer-installers-extender to map laravel-module to Modules/{{name}}. This replaces a stale plugin with actively maintained Composer tooling and yields the same on-disk layout.
2. Vendor/fork. If existing module packages already depend on this plugin's behavior, fork it, bump the composer-plugin-api constraint, add a CI matrix against current Composer and PHP, and publish internally.
3. Adopt as-is. Only acceptable behind a pinned Composer version and an explicit allow-plugins entry, with a scheduled re-evaluation.

Compatibility. Must be validated on four axes before adoption: Composer version (composer-plugin-api), PHP version, nwidart/laravel-modules major, and whether modules declare type: laravel-module in their own composer.json. Any mismatch in the type field silently routes modules to vendor/ — a failure that only surfaces when the app can't find its modules.

Sequencing.

1. Inventory how modules are currently delivered (path repo, VCS, Packagist) and confirm the type field.
2. Stand up a throwaway app on the target Composer/PHP and attempt install with allow-plugins pinned.
3. Compare against the installers-extender route on the same fixture; prefer it if parity holds.
4. Only after a clean CI install/update run, roll to a single internal consumer app, not the whole fleet.
5. Document the plugin allow-list entry and a rollback (remove plugin, re-run composer install with modules restored via path repo).

Operational Impact

Maintenance. This is the dominant cost. An unmaintained Composer plugin becomes a pinned-Composer liability: every Composer upgrade is a compatibility gate. Budget either a fork-and-maintain line item (small codebase, but requires a Composer-fluent owner) or a planned migration to composer/installers-based mapping. Do not let it become permanent infrastructure.

Support. Community support is thin — 171 stars, no recent releases, no evidence of active issue triage. Internal teams will be their own support tier. Documentation of the laravel-module package type and Modules/ path convention must be written and owned internally; the upstream README is not a substitute.

Scaling. Works acceptably for a modest catalog of internal module packages. At larger scale, Composer plugin execution adds to install time, and multi-repo module distribution increases resolution and cache complexity. Evaluate whether a monorepo with path repositories removes the need for a custom installer entirely — often the cheapest scaling answer.

Failure modes. The critical ones: (1) plugin blocked by allow-plugins → install aborts or modules land in vendor/; (2) composer-plugin-api constraint mismatch → dependency resolution failure or forced Composer downgrade; (3) module package missing type: laravel-module → silent misplacement, discovered at runtime; (4) PHP deprecation warnings on 8.2+ surfacing as CI noise; (5) stale plugin interacting unpredictably with nwidart/laravel-modules v10+ layouts. Each needs a documented symptom and remediation.

Ramp-up. Low for engineers comfortable with Composer custom installers; moderate for those who have only used composer require. The hidden cost is institutional knowledge about Composer plugin governance (allow-plugins, plugin API versioning), which most Laravel teams have never had to reason about. Plan a short internal write-up plus a known-good composer.json template before broader rollout. Given the package's age, low score, and the availability of maintained alternatives, the recommendation is to treat it as a stopgap at most — validate the composer/installers-extender path first.