Weave Code
Composer Installers Laravel Package
cartalyst/composer-installers
A Composer installer plugin that registers custom install paths for Cartalyst packages, placing extensions in their expected directories. Mainly relevant to legacy Cartalyst projects; modern setups rarely need it.
Composer installers plugin for various Cartalyst packages.
Frequently asked questions about Composer Installers
- What does cartalyst/composer-installers actually do?
- It is a build-time Composer plugin that registers Cartalyst-specific package types with Composer's installer API and routes matching packages into application-level directories instead of vendor/. It ships no service provider, no routes, and no runtime code, so it has no user-facing surface. The install-path mapping is computed in the plugin's supports() and getInstallPath() methods rather than being configurable, so the only way to know where a package lands is to read that code.
- Do I need cartalyst/composer-installers in a new Laravel project?
- No. Modern Cartalyst-era packages have moved to PSR-4 autoloading and publishable assets via php artisan vendor:publish, which the ecosystem solved better than custom installer types. The package dates to September 2014 and predates Composer 2's plugin API and allow-plugins allowlist. The only defensible use is a time-boxed shim in an inherited application that already declares Cartalyst installer types and whose build fails without it.
- Is cartalyst/composer-installers compatible with Composer 2?
- Not reliably. The plugin predates Composer 2's plugin API and the allow-plugins allowlist, and there has been no release since 2014. Expect install friction, silent non-activation, or hard incompatibility on Composer 2.x. If Composer blocks the plugin, packages silently fall back to vendor/, which presents as a path bug rather than a plugin bug.
- How do I install cartalyst/composer-installers?
- Run composer require cartalyst/composer-installers, and on Composer 2 you must also allow it in the allow-plugins section of composer.json or it will not activate. Verify the resolved install paths afterwards by diffing the tree produced with and without --no-plugins. Treat it as a temporary shim and record it as technical debt, because the package has had no upstream release since 2014.
- Which Laravel versions support cartalyst/composer-installers?
- The package is framework-agnostic: it is a Composer plugin, so it is not versioned against Laravel at all. Practical compatibility depends on your Composer version and PHP version, and the plugin was written for a 2014-era toolchain. Any Laravel version question really becomes a question about whether your Composer 2 install will activate the plugin at all.
- Why are my Cartalyst packages installing into vendor/ instead of the expected directory?
- The plugin is not being activated. Common causes are the plugin being blocked by Composer 2's allow-plugins setting, a Dockerfile or hosting step passing --no-plugins, or the plugin sitting in require-dev while production runs composer install --no-dev. Diff the resolved tree with and without --no-plugins to confirm the blast radius before changing anything.
- Is cartalyst/composer-installers safe for production?
- Treat it as high risk. It has zero stars, zero dependents, no release since 2014, and no CVE coverage, meaning there is no upstream maintainer to patch, notify, or escalate to. Install-path behavior is computed in code, so the mapping lives in one engineer's head and disappears on turnover. Accept it only as a pinned, vendored shim with an owned migration ticket and an exception-approval path.
- What license is cartalyst/composer-installers released under?
- GitHub reports the license as NOASSERTION, which is a hard gate for redistribution or commercial distribution until it is clarified. Get legal sign-off before shipping it inside a product or artifact. Until the license question is answered, avoid repackaging or vendoring it into anything you distribute.
- What are the alternatives to cartalyst/composer-installers?
- The preferred replacement is standard PSR-4 autoloading plus php artisan vendor:publish behind an explicit service provider. If you genuinely need custom install paths, composer/installers with a custom type or oomphinc/composer-installers-extender can cover it, and a path repository or plain repackaging works for internal forks. All of these are maintained options versus a plugin with no release since 2014.
- How do I migrate off cartalyst/composer-installers?
- Start with inventory rather than code: grep every composer.json and composer.lock in scope for this package and for packages whose type matches a Cartalyst installer type. Enumerate the resolved install paths and diff them against the tree produced with --no-plugins; that diff is the blast radius. Then normalize dependent packages onto PSR-4 autoloading and vendor:publish, assign a migration owner, and keep the plugin pinned only until the last dependent package is converted.
Weaver
How can I help you explore Laravel packages today?