Composer Installers Laravel Package

Technical Evaluation

Architecture fit. This is a build-time Composer plugin, not a Laravel runtime dependency. It registers Cartalyst-specific package types with Composer's installer API and routes matching packages into application-level directories outside vendor/. For a TPM the correct framing is that this is install plumbing, not a product capability: no service provider, no routes, no user-facing surface. Its only architectural signal is negative — presence in a composer.json reliably indicates a project still shaped by pre-2016 Cartalyst conventions. Removal should be runtime-invisible once dependent packages are normalized onto PSR-4 autoloading and standard asset publishing.

Integration feasibility. Feasible in exactly one narrow scenario: an inherited application that already declares Cartalyst installer types and whose build fails or mis-resolves without the plugin. Even then, feasible means "temporarily tolerable," not "advisable." For greenfield work or any Composer 2.x project, integration is not justified — a September 2014 plugin predates Composer 2's plugin API and the allow-plugins allowlist, so expect install friction, silent non-activation, or hard incompatibility. The realistic integration is a pinned, vendored shim held in place only until dependent packages are migrated.

Technical risk. High and multi-dimensional. Technically: Composer 2 plugin API incompatibility, PHP version drift, install-path collisions, autoload breakage, lockfile divergence between CI and production, and silent fallback to vendor/ when the plugin is blocked or absent — a failure that presents as a path bug rather than a plugin bug. Commercially and legally: NOASSERTION licensing is a hard gate for redistribution or commercial distribution until clarified. Operationally: zero stars, zero dependents, no release since 2014, and no CVE coverage means no upstream to patch, notify, or escalate to. The compounding risk is that install-path behavior is computed in code rather than configured, so the mapping is discoverable only by reading the installer's supports() and getInstallPath() methods — knowledge that lives in one engineer's head and evaporates on turnover.

Key questions.

• Which Cartalyst packages in the estate still require this installer, and are any still security-supported?
• What install paths does the plugin register, and do they collide with anything in the deployment or artifact layout?
• What license actually applies, and who owns legal sign-off for a NOASSERTION dependency?
• Does the pipeline run Composer 1 or 2, and does any Dockerfile or hosting step pass --no-plugins (which silently disables the mechanism)?
• Is the plugin in require or require-dev? If dev-only, CI and production diverge on --no-dev installs.
• What is the cheapest viable replacement: standard autoloading plus vendor:publish, composer/installers with a custom type, oomphinc/composer-installers-extender, a path repository, an internally owned fork, or plain repackaging?
• Who owns the migration ticket, and what is the exception-approval path if removal slips past the current release?

Integration Approach

Stack fit. Poor for modern Laravel/PHP stacks, and explicitly wrong for greenfield. Modern packages declare PSR-4 autoloading; publishable assets ship via php artisan vendor:publish behind an explicit service provider. Custom installer types solved a real 2014 problem that the ecosystem has since solved better. The only defensible fit is a time-boxed legacy build shim inside an already-pinned application — and it should be labeled technical debt in the dependency register on day one.

Migration path. Start with inventory, not 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. From there, three exit routes in order of preference: (1) replace dependent packages with standard-autoloading equivalents and delete the plugin; (2) swap in a maintained installer (e.g. composer/installers custom type or installer-paths extra) so the path contract survives without the abandoned dependency; (3) fork and vendor internally under a named owner with a documented review date. Route 3 is the fallback, not the plan.

Compatibility. Assume Composer 1-era behavior throughout. Validate against the current Composer 2 and PHP baseline on an isolated branch before touching the main pipeline. Confirm the license position before any redistribution. Do not introduce this alongside other Composer plugins without explicit interaction testing — plugin execution order is a common source of "it worked yesterday" failures. Note that composer.lock records package type but not resolved install path, so lockfile inspection alone misleads; always verify against the filesystem tree and composer install -vvv.

Sequencing. Run this as a discrete migration workstream, not a side quest inside a feature sprint:

1. Dependency and license inventory across all affected repositories.
2. Reproduce the current build in CI under the target Composer/PHP versions to establish a known-good baseline.
3. Spike the plugin on an isolated branch and capture exactly which paths it controls.
4. Implement the replacement path strategy — standard autoloading preferred, maintained installer second, fork last.
5. Regenerate lockfiles and autoload, then remove the plugin.
6. Run full regression, especially anything assuming files live outside vendor/.
7. Close the exception record, or if retained, document the pin, the owner, and the review cadence.

CI-specific: the plugin must be active in the environment that builds the artifact. If it sits in require-dev, a production composer install --no-dev will not activate it and paths will diverge between CI and production — verify with composer show cartalyst/composer-installers on the deploy target, not just in CI.

Operational Impact

Maintenance. Effectively zero upstream maintenance, which means 100% internal maintenance if retained. No release in roughly a decade means no bug fixes, no PHP compatibility updates, no Composer API updates. Keeping it alive converts a free dependency into an owned artifact — a fork or patched vendored copy with a named owner, a review cadence, and a permanent line item. That ownership cost, not the code itself, is the real expense.

Support. No vendor, no maintainer, no community to escalate to; zero stars and zero dependents means no ecosystem to crowd-source fixes from. The support path is internal engineering plus legal/compliance review. Escalation for a production incident degrades to "read the source and patch it yourself," a materially different staffing assumption than "file an upstream issue."

Scaling. Build-time only, so it will not affect runtime throughput or request latency. It scales poorly across an organization in a different sense: every service needing legacy Composer behavior or custom install paths becomes another place the pin is replicated and another surface for drift. Centralized CI images and shared caches reduce per-service friction but do not reduce abandonment risk. Twenty services sharing one abandoned plugin is twenty services with one shared single point of failure.

Failure modes. Composer 2 plugin API incompatibility; silent non-activation when the plugin is absent from allow-plugins, not installed, or disabled via --no-plugins; install-path collisions; autoload failures when a package lands in an unexpected directory; lockfile drift between CI and production; PHP version failures; inability to apply security patches; license/compliance blockers on distribution; and silent breakage triggered by unrelated Cartalyst package or Composer version changes. Several present as generic path bugs, which lengthens mean time to diagnosis.

Ramp-up. Low ceiling, high floor. Any engineer learns the Composer basics in an hour; the expensive part is archaeology — reconstructing which types map to which paths, why the layout exists, and which deploy configs quietly depend on it. Budget TPM time for dependency inventory, legal review, CI validation, and stakeholder communication about a change with no user-visible benefit. Do not staff this as feature work, and do not let it be invisible work either — it needs a ticket, an owner, and a date. The product decision this package supports is not "should we use it" but "how fast can we stop using it," and the answer should be measured in sprints, not quarters.