Theme Installer Laravel Package

Technical Evaluation

Architecture fit. This is Composer plumbing, not product capability. orchestra/theme-installer registers a custom Composer installer so packages of type orchestra-theme land in the platform's themes/ directory instead of vendor/. Its entire architectural value is contingent on one prior product decision: are we running Orchestra Platform, and do we intend to distribute themes as versioned Composer packages? If either answer is no, the package has no role. Vanilla Laravel theming (Blade namespaces, view paths, Vite asset compilation) covers the same ground with zero plugin surface. Critically, this package installs files and does nothing else — it is not a theme management layer. Activation, switching, settings, and per-tenant assignment are out of scope, and conflating the two is the most likely program-level misjudgment here.

Integration feasibility. Mechanically trivial (composer require plus a themes path) but it introduces a dependency class most teams have no operational muscle for: Composer plugins execute arbitrary code at install time. Composer 2.2+ blocks plugins by default, so any CI runner, Docker build, or non-interactive production deploy fails until config.allow-plugins explicitly whitelists it. That is a supply-chain governance decision with a named approver, not a config tweak — and it surfaces first in the pipeline, not in local dev. Second friction point: writing themes to themes/ rather than vendor/ breaks the widespread assumption that "app repo + vendor/" is the complete deployable artifact. Build scripts, .gitignore, permissions, and asset-publishing steps must all be updated to account for a Composer-managed, mutable directory inside the application tree.

Technical risk.

• Ecosystem concentration. Orchestra Platform is a small, tightly-scoped ecosystem. Dependents are 0 and the composite score is 0.3. There is no third-party validation signal, no downstream consumer base to absorb breakage, and no community backstop. Adopting this likely makes us the most significant consumer in existence.
• Single-maintainer exposure. The value proposition is entirely upstream: it must track both Orchestra's theme conventions and Composer's composer-plugin-api version. A Composer 3 plugin-API change or an Orchestra theme-structure change has exactly one party responsible for the fix.
• Metric inconsistency. The opportunity score (4.16) contradicts the composite score (0.3) and the zero-dependent count. Treat the opportunity score as a heuristic artifact, not evidence of latent demand — do not let it into a roadmap justification.
• Evidence quality. The supplied release notes and assessments describe a generic dependency-maintenance release (PHP floor bump, illuminate/support removal) — not custom-installer behavior, path resolution, or uninstall semantics, which are the actual risk surface. The documentation does not support an informed decision on its own.
• Silent misconfiguration. A theme package whose type is misspelled or absent falls through to the default installer and lands in vendor/ with no error. The failure appears later, in staging or production, as "theme not found."

Key questions.

1. Are we on Orchestra Platform today, or is this speculative? Which major version, and is it still receiving releases?
2. Who maintains this package, what is commit cadence over the last 12 months, and is there any stated support position on the Composer 2.x → 3.x transition?
3. What is our allow-plugins policy, and who signs off on whitelisting an install-time code-execution hook?
4. Is the themes path configurable per environment, and does the plugin clean up correctly on uninstall?
5. Does any part of our build or deploy pipeline assume vendor/ is the only Composer-managed directory?
6. If upstream stalls, do we have appetite (and a named owner) to fork and maintain a Composer plugin indefinitely?

Integration Approach

Stack fit. Binary, and governed by platform choice rather than Laravel version. Fit: an Orchestra Platform deployment already using theme packages, where this is the sanctioned mechanism and the plugin is glue the platform expects. No fit: standard Laravel/Lumen applications, where adopting it means importing an entire platform's packaging convention to solve a problem Blade and a build step already solve. The PHP 7.1 floor is not a hard constraint (every supported Laravel line sits above it) but it signals the reference environment — verify PHP 8.2/8.3 explicitly before committing. Also evaluate composer/installers, which handles custom install paths for many package types and is far better maintained; prefer it unless the orchestra-theme package type is a hard requirement.

Migration path. There is no meaningful incremental migration — this is either/or on packaging strategy. Recommended spike sequence:

(a) Stand up a throwaway Orchestra Platform skeleton and run the plugin plus one theme package end-to-end, including composer update, composer remove, and a themes path change. Confirm where files actually land and what is left behind. (b) Add the plugin to allow-plugins in a branch composer.json and verify a clean CI run with --no-interaction. (c) Diff the built deploy artifact against current output to quantify the new directory and file volume entering production. (d) Only then touch a shared environment.

If the outcome is negative, the fallback is not "find another package" — it is "do not distribute themes as Composer packages," or "implement the installer in-house."

Compatibility. Pin explicitly — exact or tilde range, not a caret, given the zero-dependent baseline — and pin the expected Composer plugin-api in composer.json. Test against the Composer version pinned in CI and the one developers run locally; these diverge more often than teams expect. Confirm the Orchestra Platform major we target is the one this release line supports: the v1.1.0 notes provide no compatibility matrix, so this needs direct verification. Separately, the removal of illuminate/support is breaking for anyone relying on it transitively; it is only safe if the source no longer references Illuminate\ classes or global helpers, and if nothing in our own code depended on it. Budget roughly half a day for that audit — treat the audit, not the release notes, as the go/no-go gate.

Sequencing. Decide the platform question first, before any technical spike is funded. If Orchestra is confirmed, run the spike and the allow-plugins governance approval in parallel — the approval is the longer pole and should be tracked as a dependency in the delivery plan. Land CI/Docker/pipeline changes before the plugin becomes a resolved dependency on main, not after, or the first pipeline run will be the discovery mechanism. Rough effort framing: ~0.5 day technical audit, ~1–2 days spike, 1–2 weeks elapsed for allow-plugins sign-off, and ~1–2 days of pipeline and deploy-artifact changes.

Operational Impact

Maintenance. Low ongoing engineering effort if the ecosystem is healthy, because we write no code — developers interact with it via composer require and nothing else. But we inherit a maintenance dependency we cannot influence: every Composer upgrade and every Orchestra Platform bump is a compatibility event we monitor rather than control. With zero dependents upstream, there is no crowd to share that burden with. Budget explicitly for "we may become the maintainer" as a realistic end state, and price a fork (~150–300 lines of Composer plugin code plus a CI matrix) accordingly. If a fork is not fundable, the correct decision is to own the code from day one or not adopt.

Support. The support surface is genuinely thin; the real load is triage. Because the plugin fails at install time with Composer's error output rather than an application stack trace, front-line support will escalate to platform engineering quickly — which is fine, but it should be staffed, not discovered. The PHP 7.1 floor invites repository-level questions from security and compliance reviewers, so prepare a short written stance ("internal fork; validated on 8.2/8.3; single named owner") before it is asked in an audit context.

Scaling. Theme installation scales trivially — a handful of files per package. What does not scale through this package is anything the roadmap actually cares about at scale: per-tenant or per-brand theme assignment, theme version pinning per tenant, and runtime theme selection. Those require a management layer above this plugin. The indirect value is real, though: per-tenant theme versioning is only tractable if themes are consumable as versioned artifacts, and this plugin is what makes them so. Frame it that way in roadmap discussions — enabler, not capability.

Failure modes. Enumerate these in the risk register and attach a detection to each: (1) plugin blocked by allow-plugins → install fails in CI/Docker, detected at first pipeline run; (2) mis-typed theme package → silently installed to vendor/, detected only at runtime as "theme not found"; (3) upstream stall → we inherit unsupported code, detected by reviewing commit cadence quarterly; (4) Composer plugin-API break → hard install failure across all environments simultaneously; (5) uninstall residue or permission issues in themes/ → stale or unreadable theme assets in production; (6) path-configuration drift between environments → themes found locally but not in deploy targets.

Ramp-up. Developer ramp-up is near zero — one composer require and an understanding that themes are packages. The genuine ramp-up cost sits with platform engineering and DevEx: understanding what Composer plugins do at install time, establishing the allow-plugins allow-list and its review process, and updating deploy-artifact assumptions. Budget a half-day of pipeline/packaging education for whoever owns the build, and make one person explicitly accountable for tracking upstream releases and the Composer 3 migration.

TPM recommendation. Do not adopt as a strategic dependency and do not budget for it as a product capability. If a theming roadmap materializes, take the pattern — themes as versioned, lockfile-tracked artifacts with real rollback semantics — and either fork this package or implement the installer in-house under our own ownership and named maintainer. Revisit only if we commit to Orchestra Platform as a platform bet, in which case that lock-in decision deserves its own explicit roadmap line rather than being a footnote to a Composer plugin.