View Laravel Package

Product Decisions This Supports

• Build vs. buy for the view/theming layer — the honest answer here is "build a thin version." orchestra/view is not a templating product; it is a swap of Laravel's view.finder for an ordered, theme-aware finder plus render-lifecycle events. The capability is roughly a couple hundred lines of glue over native Illuminate\View. The decision this package informs is replicate the pattern in-house, not take the dependency.
• White-label and multi-tenant theming roadmap. The reusable primitive is: register multiple view roots, resolve in deliberate priority order, let an active theme override without forking templates. That maps directly onto customer skins, per-tenant template overrides, and agency configurations. Scope those epics against this pattern as the reference architecture; do not mistake the package for the feature.
• Extension / plugin ecosystem scoping. If the roadmap includes a third-party extension marketplace or a pluggable admin panel, the contract to copy is namespaced views (acme::dashboard) with a documented app-level override seam (resources/views/vendor/acme/...). This package demonstrates that contract cleanly enough to cite in an extension-SDK design doc.
• Supply-chain and dependency governance. Zero stars, zero dependents, last release v6.0.0 pinning to Laravel 8. Adoption makes the team the de facto maintainer of high-blast-radius rendering plumbing. That is a portfolio signal, and it argues for a stricter default policy on anything that touches view resolution.
• Roadmap prioritization. Nothing here is a differentiator — it is enabling infrastructure. Do not put "adopt orchestra/view" on a roadmap. At most, track "owned theme-aware view resolution" as a capability behind a theming or white-label epic.
• Upgrade-cost planning. If Orchestra is already in the stack, this is a proxy for your Laravel upgrade exposure: the release trail stops at Laravel 8, so any modernization plan must budget for either forking it or replacing it.

When to Consider This Package

Consider it only if all of the following hold:

• You already run — or have deliberately committed to — Orchestra Platform on a compatible Laravel version. Then it is an inherited platform dependency, not an independent adoption decision.
• You specifically need theme-aware resolution plus view lifecycle events as a first-class framework concern, and have no appetite to write that glue yourself.
• You have validated compatibility against a currently supported Laravel/PHP matrix in CI — package discovery, config caching, view caching, queue and mail rendering, test environment. This is the critical gate; assume drift until proven otherwise.
• You accept that you will vendor, pin, or fork it and assign a named internal owner, with a written statement of which behaviors (namespace override, theme precedence, lifecycle events) you actually consume — that list is your replacement spec.

Look elsewhere — or build a small owned implementation — when:

• You are on a modern Laravel and need only Blade, composers, View::share(), or standard view caching. Native Laravel covers it; the package is pure overhead.
• You need theming or multi-tenancy with a support contract, current documentation, or a security disclosure process.
• You need a small, auditable supply chain. Zero dependents lowers version-conflict risk but also means there is no evidence this has been validated on real production workloads.
• You are starting a greenfield Laravel product with no Orchestra requirement. Do not introduce this as a foundation.
• You cannot absorb the ownership cost — no named maintainer, no compatibility matrix, no capacity to fork.

How to Pitch It (Stakeholders)

For executives: this is infrastructure, not a product, and it carries no license cost but a real ownership cost. It is a theme-aware view layer that swaps how Laravel locates templates so that themes, packages, and extensions can each contribute templates with deterministic override precedence. The strategic point is that the value lives in the pattern, not the package: white-label skins, per-tenant template overrides, and a plugin ecosystem all need exactly this precedence model. Our recommendation is to treat it as an inherited Orchestra Platform dependency if we are already on Orchestra, and otherwise to implement the same pattern in-house on native Laravel rather than adopt a package with zero stars, zero dependents, and a support matrix that ends at Laravel 8. Either way, someone on our side owns it.

For engineering: the entire integration surface is Orchestra\View\ViewServiceProvider and Orchestra\View\FileViewFinder. Register paths in boot(), always with $app->extend('view.finder', ...) and never by rebinding the container key — rebinding silently discards theme and extension path registrations. Prefer prependNamespace() for app-level overrides and prependLocation() for the active theme, and centralize theme registration in one provider because prepend order is a stack you will have to debug at runtime. Namespace every first-party view (blog::post.index) so overrides have a documented seam. Use class-based composers over View::share(), scope wildcard composers away from * so mail and error pages do not hit the database, and debug resolution with app('view.finder')->getPaths() and getHints() before blaming Blade. Clear compiled views after any path or directive change. Pin ^6.0, gate provider registration behind a config flag for a one-line fallback to native view services, and put the Laravel/PHP compatibility matrix in CI — that matrix plus the consumed-behavior list is our replacement spec.