- What does joshbrw/laravel-module-installer actually do?
- It is a Composer plugin that registers a custom installer for packages declaring "type": "laravel-module" and redirects their install path from vendor/ into the application's Modules/ directory. It is install-time only: it adds no service provider, no runtime coupling, and no autoload surface to your app. Outside composer install and composer update the plugin does nothing, which keeps the blast radius small. It is meant for projects that already follow nwidart/laravel-modules conventions and consume modules as external Composer packages.
- How do I install and configure joshbrw/laravel-module-installer in a Laravel project?
- Require the plugin with Composer, add a repository entry (VCS, path, or private Packagist) for each module package, and make sure every module's composer.json declares "type": "laravel-module". On Composer 2.2 and later you must also add an allow-plugins entry permitting joshbrw/laravel-module-installer in your root composer.json config. After that, composer update installs those packages into Modules/ rather than vendor/. If any of those four pieces is missing, modules silently resolve to vendor/.
- Does it work with Composer 2.2 and 2.5 allow-plugins requirements?
- Composer 2.2 introduced the allow-plugins secure default and 2.5 hardened it, so the plugin will not execute unless you explicitly allow it in your root composer.json config. Because the last release dates to January 2021, its composer-plugin-api constraint may also be incompatible with current Composer 2.x lines and could be rejected outright. Verify in a staging project that installs succeed without --ignore-platform-reqs. If they do not, fork and bump the constraint rather than downgrading Composer.
- Is joshbrw/laravel-module-installer compatible with nwidart/laravel-modules v10 and v11?
- There have been no releases since January 2021, so nothing indicates validated support for nwidart/laravel-modules v10, v11, or newer layout changes. The plugin only redirects install paths, so a compatible layout may still work, but the surrounding module conventions are untested against recent majors. Treat it as unverified on modern stacks and prove it in a staging application before adopting. If you need current support, expect to fork and maintain it internally.
- Why are my Laravel modules still installed into vendor/ instead of Modules/?
- The most common cause is that the module package does not declare "type": "laravel-module" in its own composer.json, which makes the plugin ignore it. The second most common cause is that the plugin is not installed or is blocked by the Composer 2.2+ allow-plugins default. Both failures are silent: you only notice when the application cannot find its module at runtime. Check the type field, the allow-list entry, and the composer-plugin-api constraint in that order.
- What is a maintained alternative to joshbrw/laravel-module-installer?
- Use composer/installers together with oomphinc/composer-installers-extender to map the laravel-module type to Modules/{{name}}. That produces the same on-disk layout using actively maintained Composer tooling, removing a stale plugin from your install-time attack surface. For modules that live alongside the app, a path repository strategy is simpler still and needs no custom installer at all. Prefer either of these before adopting an unmaintained plugin.
- Is it safe for production if it hasn't been released since 2021?
- Composer plugins execute arbitrary code at install time with the developer's privileges, so enabling an unmaintained one is a security posture decision, not just a compatibility question. With no releases in roughly four years there are no fixes for Composer 2.2/2.5 plugin governance, PHP 8.2/8.3 deprecations, or newer nwidart majors. If you must use it, pin your Composer version, add a narrow allow-plugins entry, and schedule a re-evaluation or fork. There is no visible test or CI signal in the package metadata confirming current behavior.
- Can I use it with private modules distributed via private Packagist or a VCS repository?
- Yes, that is the primary use case: a platform team distributing a shared module catalog to multiple downstream Laravel apps. Each module must be published as a Composer package with type laravel-module, and the consuming app needs a repository entry pointing at the VCS repo, path, or private Packagist. The plugin then installs them into Modules/ instead of vendor/. Confirm plugin governance and the composer-plugin-api constraint first, since private distributions make breakage harder to spot.
- Do I need nwidart/laravel-modules for this installer to be useful?
- The installer only changes where files land; it assumes nwidart/laravel-modules conventions such as the Modules/ directory layout and module structure. Without nwidart/laravel-modules your packages would still land in Modules/, but the application would have no mechanism to load them. If your modules live in-repo, the common case, the plugin adds no value and should not be introduced at all. It fits only apps that consume modules as external Composer packages.
- How do I fork joshbrw/laravel-module-installer and maintain it internally?
- Fork the repository, bump the composer-plugin-api constraint to match your Composer 2.x line, and add a CI matrix covering current Composer, PHP 8.2/8.3, and the nwidart/laravel-modules majors you support. Publish the fork to private Packagist or a VCS repository and swap the requirement in your root composer.json. Validate four axes before rollout: Composer version, PHP version, nwidart major, and whether every module declares type laravel-module. Keep the allow-plugins entry pointed at your fork's name.