Theme Installer Laravel Package

Product Decisions This Supports

• Theme distribution strategy — the core decision. This package only makes sense as an answer to one question: do we ship themes as versioned Composer packages, or as files copied into the repo? If the answer is "Composer packages," this is the plumbing that installs orchestra-theme packages into themes/ instead of vendor/. If the answer is "files in the repo," the package is irrelevant and the decision still needed making — but a different way.
• Build vs. buy for installer plumbing. A custom Composer installer is roughly 150 lines of unglamorous, easy-to-get-wrong lifecycle code (install/update/uninstall, path resolution, package-type registration). Reusing it is usually correct; it is infrastructure and never differentiation. Even if you don't adopt it, it's a working reference for that decision.
• Release engineering and rollback posture. Once themes are lockfile entries, theme upgrades and rollbacks ride the same composer.lock diff → code review → staged deploy path as every other dependency. That is the single strongest product argument in the pattern's favor, and it is an operational upgrade over ad-hoc file drops regardless of which implementation you land on.
• White-label / multi-brand roadmap. If per-tenant or per-brand themes are on the roadmap, pinning theme versions per tenant is only tractable when themes are consumable as versioned artifacts. This package enables the artifact mechanics — it does not provide tenant assignment, activation, or settings.
• Platform and ecosystem bets. Adopting it implies adopting Orchestra Platform conventions. That is a lock-in decision to name explicitly in roadmap planning, not a footnote for engineering.
• Dependency due diligence as a product input. Zero stars, zero dependents, a 0.3 composite score, and a PHP 7.1 floor described in a 2024-era minor release are themselves evidence: plan for "we own this," not "someone supports this."
• Do not confuse it with a theme management layer. The most likely PM misjudgment is to file this under "theming capability." It installs files. Nothing more.

When to Consider This Package

Consider it when:

• The product already runs on Orchestra Platform (or a fork) and themes are genuinely packages, not static assets.
• You ship multiple themes or brands to one application and need deterministic, versioned rollouts and rollbacks across environments.
• Your delivery pipeline is Composer-driven end to end, and you want themes to inherit lockfile diffing, artifact caching, and CI installation rather than introducing a second delivery mechanism.
• You want vendor/ kept free of application-owned theme code so composer update never touches theme files and autoloading stays predictable.
• You're willing to own the code — fork it, vendor it, or reimplement the installer internally. Assume "internal fork with a named owner," not "supported supplier."

Look elsewhere when:

• The product is vanilla Laravel. Blade namespaces, view paths, and a Vite/build step already solve theme delivery with zero plugin surface.
• You need activation, switching, settings, or per-tenant theme assignment. Out of scope entirely.
• You need a maintained dependency with security response or PHP 8.1–8.3 guarantees. The release notes give a 7.1 floor and no CI matrix.
• Generic path mapping is all you need — composer/installers already handles custom install paths across many package types and is far better maintained. Prefer it unless the orchestra-theme package type is a hard requirement.
• You can't fund a fork. The realistic end state here is internal ownership; if that isn't available, copy the pattern into your own Composer plugin.

Two non-obvious adoption gates worth naming to stakeholders up front: Composer 2.2+ blocks plugins by default, so config.allow-plugins must be whitelisted — a supply-chain governance approval, not a config tweak. And a theme package with a misspelled or missing type silently falls through to vendor/ with no error, surfacing much later as "theme not found."

How to Pitch It (Stakeholders)

Executive summary. This is a small, single-purpose Composer plugin that lets themes be installed and upgraded like any other dependency in an Orchestra Platform application. Its value is operational, not competitive: theme releases go through the same review, versioning, and rollback path as the rest of the codebase instead of ad-hoc file drops. The caveats are equally clear — no ecosystem traction (no stars, zero dependents, 0.3 composite score), a PHP 7.1 floor our supported stacks have long passed, and a hard tie to Orchestra Platform conventions. Recommendation: do not adopt as a strategic dependency and do not budget for it as a product capability. If we pursue a theming roadmap, take the pattern — themes as versioned, lockfile-tracked artifacts — and either fork this or build the installer in-house under our ownership. Revisit only if we commit to Orchestra Platform.

Engineering summary. orchestra/theme-installer registers a custom Composer installer for packages of type orchestra-theme, placing them in the configured themes path and handling install, update, and uninstall. v1.1.0 raised the minimum PHP to 7.1 and dropped the illuminate/support dependency — a dependency-hygiene change shipped as a minor bump. Two things to verify before trusting it in our stack: (1) removing illuminate/support is breaking for anyone relying on it transitively, and is only safe if the source no longer references Illuminate\ classes or global helpers; (2) a 7.1 floor implies CI has not been validated on PHP 8.1–8.3, where our applications actually run. If we adopt or inherit it: pin explicitly rather than floating on ^1.0, add it to allow-plugins in a branch first and prove a clean --no-interaction CI run, exercise an install/update/remove plus a path change in a throwaway skeleton, diff the deploy artifact to see what new directory volume enters production, and confirm nothing depended on the removed transitive package. Budget about half a day for that audit — treat the audit, not the release notes, as the go/no-go gate. The supplied materials describe a generic dependency-maintenance release; they say nothing about installer behavior, path resolution, or uninstall cleanup, which is where the actual risk lives.