Laravel Theme Installer Laravel Package

Product Decisions This Supports

• White-label / multi-brand roadmap: If the roadmap includes per-client branding, this package lets each theme ship as a Composer package that lands in a project-controlled themes/ directory instead of vendor/, which is the difference between "branding is a redeploy-and-pray operation" and "branding is a versioned, diffable artifact your team can review."
• Build vs. buy on theming infrastructure: Themable UI is usually a 2–6 week internal build (theme resolution, asset publishing, fallback chains, per-tenant overrides). Adopting the hexadog/laravel-theme + installer pair converts that into a dependency decision, freeing that capacity for the differentiating surface of the product.
• Feature framing for a "theme marketplace" or partner-theme program: Themes as installable packages is the prerequisite for letting partners, agencies, or internal design teams publish themes independently of core releases. This package is the distribution mechanism, not the theming engine — that separation is what makes a marketplace conceivable later.
• Release and rollback policy: Because themes are Composer-versioned rather than hand-edited in resources/, theme changes become reviewable PRs with pinned versions and clean rollbacks. This supports a decision to hold themes to the same change-control standard as application code.
• Deployment topology choices: Supports deciding whether themes are baked into the image at build time (immutable, simpler) or mounted/overridden at deploy (per-tenant flexibility). The package makes the second option cheap; that is a product-flexibility decision, not just an ops one.
• Roadmap sequencing input: Low adoption cost means theming can be scheduled early and cheaply rather than deferred behind a large internal platform investment — useful when negotiating scope with stakeholders who want visible customization sooner.

When to Consider This Package

Consider it when all of the following hold:

• You are already committed to, or seriously evaluating, hexadog/laravel-theme as the theming layer. The installer is a satellite; it has no standalone value.
• Your product needs more than one visual identity — multi-tenant SaaS, agency-built client sites, white-label resale, or a design-system-driven brand refresh cadence.
• You want themes to live in source control alongside the app, be editable by designers/agencies, and be independently versioned — the "outside vendor" behavior is the entire point.
• Your team is comfortable with Composer plugins and can govern allow-plugins in composer.json. This is a supply-chain surface; treat it as such.
• The maintainer/ecosystem risk is acceptable for the value: ~10 GitHub stars means you should assume you may become the maintainer.

Look elsewhere when:

• Non-technical users must change themes at runtime. This is a Composer-time install, not an admin-panel theme switcher. If marketing wants to toggle themes without a deploy, you need a DB- or storage-backed theme registry instead.
• You need vendor immutability. Some security postures forbid Composer plugins or writing outside vendor/. Do not fight that policy for a convenience feature.
• You are on a different theming stack (e.g., a Vite/Tailwind multi-brand build, a CMS, or Laravel's own view namespacing). Adding a second theming concept creates two sources of truth.
• Long-horizon platform risk matters more than speed. Single-maintainer, low-star packages are fine for a spike, risky as the foundation of a paid customization offering without a fork-and-own plan.
• Your theming needs are trivial (one brand, colors from env). A config file and a CSS variable layer will outperform a package dependency here.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can offer per-client branding and white-label variants without building a theming platform ourselves. This package is a small, MIT-licensed Composer plugin that lets theme packages install into our own themes/ directory instead of vendor/, which means each brand becomes a versioned, reviewable, rollback-able artifact rather than a manual edit. It is a distribution mechanism, not a product in itself — the design system and theming engine still sit with us. Cost to trial is days, not weeks. The trade-off is maturity: it is a low-adoption open-source component, so we should pilot it on one product, keep it behind our own internal interface, and budget a few days a year for maintenance or a fork. Recommended decision: approve a scoped pilot; revisit ownership at the end of the first white-label engagement.

For engineering: This is a Composer plugin that hooks installation of laravel-theme packages and redirects them outside vendor/, so themes are first-class project code — editable, diffable, and independently versioned, with theme resolution handled by the parent package. Integration surface is small and mostly declarative. Two things to own explicitly: (1) allow-plugins governance and CI implications of a Composer plugin in the build chain, and (2) an internal theme-resolution wrapper so we are not coupled to the hexadog API at every call site. If the package ever goes unmaintained, that wrapper is what makes a fork or replacement a contained task rather than a migration.

For design/agency partners: Themes become installable, numbered releases. You can ship a brand update without waiting on an application release, and we can roll it back the same way.