Composer Installers Laravel Package

Product Decisions This Supports

• Legacy migration scoping (primary PM use case). Its presence in a composer.json is a concrete diagnostic signal: this application is still shaped by pre-2016 Cartalyst conventions. Use it to scope Composer 1 → 2 upgrades, Laravel version jumps, and dependency cleanup with evidence rather than guesswork.
• Tech-debt inventory and EOL sequencing. Treat it as a backlog item in the dependency-retirement register. Its presence helps prioritize removal of old Cartalyst-era packages and prevents abandoned install plumbing from silently becoming permanent.
• Build vs. buy vs. fork vs. delete. With a last release in 2014, zero stars, zero dependents, and NOASSERTION licensing, the realistic decision is not "adopt." The PM decision is whether to fork, vendor, replace, or remove. Default recommendation: remove.
• Compliance and dependency review. The unclear license is a legal gate for commercial distribution. It belongs in third-party review regardless of technical merit and can block release if left unresolved.
• Roadmap hygiene. There is no end-user surface here — no routes, models, or service provider. It should never appear as a roadmap deliverable. It only supports internal decisions about maintenance cost, migration effort, and risk exposure.
• Effort and ownership estimation. Retaining it converts a free dependency into an owned artifact with a named owner and review cadence. That ownership cost — not the code — is the real line item to budget.

When to Consider This Package

Consider it only if:

• You inherited a pre-2016 Laravel application that already declares Cartalyst installer types and whose build fails or mis-resolves without the plugin.
• You need a one-time forensic audit of legacy install paths before refactoring dependencies away from Cartalyst conventions.
• You are keeping a legacy application on explicit life support and have accepted the maintenance, legal, and pinning burden as a documented exception.

Look elsewhere if:

• You are doing greenfield work. Modern packages use PSR-4 autoloading; assets ship via php artisan vendor:publish and an explicit service provider. Custom installer types are unnecessary.
• You are on Composer 2.x. A plugin last released in September 2014 predates Composer 2's plugin API and allow-plugins requirement. Expect installation friction or hard incompatibility, not a clean drop-in.
• Licensing matters. NOASSERTION provides no clear grant. Treat redistribution as blocked until legal counsel or the maintainer clarifies terms.
• You need support or security response. No release in roughly a decade, no dependent ecosystem, and no maintainer means no patches and no CVE coverage.
• A maintained alternative exists. Use the framework's supported publishing mechanisms, or a small in-house service provider — both are cheaper and safer than resurrecting this package.

How to Pitch It (Stakeholders)

For executives: Do not add this as a dependency. It is a decade-old Composer install helper with no maintainer, no community adoption, and an unclear license. The upside for new work is zero; the downside is legal review, upgrade risk, and a permanent ownership burden. Recommendation: no-go — treat any existing usage as technical debt to retire within the next few sprints.

For engineering: If it already appears in a legacy composer.json, scope it as a discrete cleanup workstream, not a side quest inside a feature sprint. Replace custom installer paths with PSR-4 autoloading and vendor:publish, confirm no package still depends on the registered install types, then remove the plugin before changing Composer versions. Validate in an isolated branch against your current Composer 2 / PHP baseline — and verify the plugin is active on the deploy target, since --no-dev or --no-plugins will silently disable it and cause path drift between CI and production. Estimate roughly half a day to two days depending on how many Cartalyst-era packages are involved.

If forced to keep it: Pin the exact version, vendor the source into the repository, register the licensing ambiguity in the dependency register, and add it to the quarterly review list with a named owner so it does not silently become permanent.

Bottom line: deprecate, don't adopt. The only defensible product decision this package supports is deciding how quickly to remove it — and that should be measured in sprints, not quarters.