Plugin Installer Laravel Package

Product Decisions This Supports

• Build vs. buy on the extension layer. This package is the plumbing behind a plugin/module ecosystem: it registers a custom Composer package type so composer require drops code into an app-owned directory (e.g. catch/ modules) instead of vendor/. That is the enabling decision for "do we let third parties extend our product, and how do their extensions get installed?"
• Distribution model for modules. Because plugins land outside vendor/, they're editable, independently versioned, and shippable as separate artifacts. This supports deciding between (a) a curated marketplace, (b) private partner distribution, or (c) per-client forks — the installer makes (a) and (b) mechanically possible.
• Roadmap: ecosystem and monetization. A working installer convention is a prerequisite for a paid plugin catalog, partner certifications, or an "extensions" line item on the roadmap. Without it, every customization is a core patch and there's nothing to sell or support.
• Delivery model for services/implementation work. Agencies and implementation partners can ship client-specific modules that survive core upgrades. That's a decision about whether your go-to-market leans on partners and how much upgrade friction you're willing to accept.
• Upgrade and support policy. Plugin code living outside vendor/ changes your support envelope: you now own compatibility guarantees between core versions and third-party modules, plus a deprecation policy.
• Use cases in scope: vertical SaaS configurations, on-prem/self-hosted deployments where customers modify modules directly, partner-built integrations, and internal feature-flagging via toggleable modules.

When to Consider This Package

Adopt it when all of these hold:

• You are already on CatchAdmin (or a Laravel admin stack that deliberately uses this installer convention and the matching module registry).
• You need third-party or partner code to install via Composer into an app-owned path, not vendor/.
• You're willing to treat the dependency as internal infrastructure: pin the version, review the source, and vendor/fork it.

Look elsewhere when:

• You're not on CatchAdmin. The value is entirely in the shared convention; without the framework's loader it's a solution to a problem you don't have.
• You just need generic custom install paths. composer/installers or oomphinc/composer-installers-extender are the established, widely-adopted route.
• You just need package discovery. Laravel's built-in package discovery already handles service providers — no custom installer required.
• You need a real plugin sandbox. A Composer plugin runs with full Composer/PHP privileges at install time. If you're hosting untrusted third-party code, this is not a security boundary and shouldn't be presented as one.
• Maturity matters more than fit. Zero stars, zero dependents, single-vendor ownership. That's not disqualifying for a small utility, but it means no community validation, no external bug pressure, and a real bus-factor/supply-chain question. Budget for ownership, or plan to reimplement (it's a small, well-understood piece of logic).

How to Pitch It (Stakeholders)

To executives: This is a small piece of plumbing that determines whether partners and customers can extend our product without us patching core for every request. It's the precondition for an extensions catalog, partner-delivered customizations, and lower-cost per-client deployments — the mechanics of an ecosystem play, not a feature in itself. The caveat: the package is a tiny, unproven, single-maintainer dependency that executes at install time, so we should treat it as internal infrastructure — audit it, pin it, and be prepared to own or replace it. The strategic value is in the convention, not the code; the convention is ours to define either way.

To engineering: It's a Composer plugin registering a custom package type that remaps install paths so modules land in the app tree rather than vendor/. Small surface area, easy to read and to reimplement in-house if we'd rather not carry a third-party dependency with no adoption. Action items: security-review the install-time hooks, lock the version, and document the module directory contract (naming, autoload, registration) so third parties build against a stable spec rather than against this package's internals.