Module Installer Laravel Package

Product Decisions This Supports

• Modular architecture commitment. This package only exists to make composer require place code into modules/<name> instead of vendor/. Adopting it is effectively a public commitment that features ship as independently installable modules rather than as edits to the core app. It is the plumbing behind a roadmap decision, not a feature itself.
• Feature delivery cadence. Once modules install and upgrade through Composer, individual capabilities can version and release on their own schedule. This supports decisions like "can we decouple the billing module from core releases?" or "can a partner ship an add-on without touching our repo?"
• Ecosystem / marketplace optionality. A typed package (type: saucebase-module) plus a deterministic install path is the minimum viable foundation for a module directory, private registry, or partner extension programme. The package does not create the ecosystem, but no ecosystem story is credible without it.
• Build vs buy vs vendor. It is a small, MIT-licensed, single-purpose Composer plugin. The realistic alternatives are (a) fork and own it, (b) pin a generic installer such as composer/installers with a custom path, or (c) ask every consumer to copy folders manually. A PM should treat this as a ~1-day decision with low switching cost, not an architecture debate.
• Developer onboarding and support cost. Every manual "clone into modules/" instruction is a support ticket and a point where a self-hosting customer gets the layout wrong. Automating the path is a cheap DX win that shows up in activation and installation-failure metrics rather than in the product itself.
• Convention and naming policy. Forced lowercase install directories and a configurable base dir are product-level conventions. Decide now whether module names are case-sensitive, whether the base path is fixed or per-project, and document it before third parties depend on it.
• Distribution and governance model. Publishing to Packagist versus running a private registry is a commercial decision (open vs gated modules). This plugin is compatible with both; the decision must be made before the first external module ships.

When to Consider This Package

Consider adopting when:

• You are building on the Sauce Base modular skeleton and expect three or more first-party modules; below that threshold, hand-managed directories are cheaper than any installer.
• You intend modules to be installed by people other than the core team — customers, agencies, or partners — where a copy-paste instruction is unacceptable.
• You want modules versioned and upgraded through standard Composer tooling (require, update, lockfiles) rather than a bespoke update mechanism.
• You are standing up a private or public registry and need a stable, predictable install path for tooling, docs, and CI to rely on.
• You can tolerate a nascent dependency: 1 star, 0 dependents, a recent release. Vendor it, fork it, or pin it with a lockfile and be prepared to maintain it yourself.

Look elsewhere when:

• The product is a single deployable monolith with no intention of shipping discrete add-ons. A modules/ convention with one module is overhead with no payoff.
• You need a general-purpose installer for many package types (themes, plugins, assets). Use composer/installers or composer-installers-extender instead of a bespoke plugin per type.
• Your CI, shared hosting, or customer environments block Composer plugins (allow-plugins restrictions, no plugin execution). The install step will fail or require manual overrides, which negates the benefit.
• You need guaranteed long-term maintenance and cannot accept a single-maintainer, pre-traction dependency. In that case fork it into your own namespace or reimplement the ~one class of logic in-house.
• Module names, nesting, or multi-tenant paths must be dynamic per environment. A fixed modules/<lowercase-name> convention will fight you.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, MIT-licensed piece of developer plumbing that lets us ship product capabilities as installable modules instead of one growing codebase. It costs effectively nothing to adopt, carries no runtime footprint, and is the prerequisite for any future module ecosystem, partner add-ons, or paid extensions. The risk is not technical — the code is simple and the licence is permissive — it is maturity: the package is early and barely used, so we should treat it as ours to maintain if we depend on it. Recommendation: adopt internally now, keep the ecosystem narrative off the roadmap until at least three real modules exist.

For engineering (one paragraph): It is a Composer plugin (Installer.php + Plugin.php) that maps type: saucebase-module packages to modules/<name> in lowercase, with a configurable base directory. It ships with a PHPUnit 12 suite, Pint formatting, and Conventional Commits, so it is easy to review and safe to fork. Two asks before we depend on it: confirm allow-plugins is permitted in our build and customer environments, and agree whether modules resolve from Packagist or a private registry. Budget a day to vendor or fork it if upstream goes quiet — the surface area is tiny.