View Laravel Package

Technical Evaluation

Architecture fit. orchestra/view is not a templating engine and should not be evaluated as one. Its entire footprint is a container-level swap of Laravel's view.finder for an ordered, theme-aware FileViewFinder, a view factory that layers Orchestra's package/module conventions on top of Illuminate\View, and lifecycle events around composition and rendering. That means architectural fit is a binary question: does the product need ordered, override-first template resolution across themes, packages, and modules as a first-class framework concern? If yes, this package is a working reference implementation of that pattern. If no, it is pure overhead on top of native Blade. It fits cleanly only inside the Orchestra Platform ecosystem (orchestra/theme, orchestra/extension pushing paths through the same finder); outside that ecosystem it is a solution without a platform.

Integration feasibility. Technically straightforward, organizationally questionable. The integration surface is genuinely small — read ViewServiceProvider::register()/boot() to see which container keys get rebound (view, view.finder, the engine resolver) and in what order, then read FileViewFinder for the path/hint/extension methods. That is the whole API. A competent Laravel engineer can wire it up in under a day. The gate is not API complexity, it is framework compatibility: the release trail ends at v6.0.0 pinning Laravel 8, with no evidence of forward-porting. On a modern Laravel estate the integration work is a fork-and-maintain exercise, not an adoption exercise.

Technical risk.

• Version drift is the default assumption, not an edge case. Laravel 8 is out of support; the package tracks Orchestra's support matrix, not the community's. Everything downstream of that (PHP version, Octane behavior, view caching internals, mail rendering) is unvalidated on current versions.
• Blast radius is maximal. Rendering sits on every web request, every queued mail and notification, and the exception page. A defect here is a site-down defect, not a cosmetic one.
• No upstream validation. Zero stars and zero dependents means no production bug reports, no compatibility pressure, and no third party to lean on when resolution order behaves unexpectedly. Adoption transfers de facto maintainership to our team.
• Ordering semantics are implicit and fragile. Prepend order is a stack, last call typically wins, and sibling Orchestra packages push paths through the same finder. Two providers owning the view layer produces double path entries and unpredictable precedence — a class of bug that surfaces as "the wrong theme rendered" and takes hours to isolate.
• Silent failure modes. Rebinding view.finder instead of extend()ing it discards other providers' registrations without an error. Registering in register() instead of boot() can resolve and mutate a throwaway finder. Both fail quietly.

Key questions for the team.

1. Are we already running Orchestra Platform on a compatible Laravel version, or would this be a net-new dependency? (If net-new: the answer is almost certainly no.)
2. Which specific behaviors do we actually consume — namespace override, prepend precedence, lifecycle events, engine resolver — and can we enumerate them? That list is both the business case and the replacement spec.
3. What is our current Laravel/PHP matrix, and is there any path to this package on it that does not involve us forking?
4. Who is the named internal owner, and what is the CI compatibility matrix they will maintain?
5. What is the fallback if resolution behaves differently in production — can the provider be gated behind a config flag for a one-line revert to native view services?
6. Is a ~200-line internal implementation of ordered path registration plus a composer hook actually cheaper than owning this? (In most cases: yes.)

Integration Approach

Stack fit. Fit is narrow and version-bounded. The package is Laravel 8 / Orchestra-aligned. It is a legitimate fit if we are already on Orchestra and inheriting it as a platform dependency — in that case this is not an adoption decision we get to make independently, it is a component we must govern. It is a poor fit for a greenfield Laravel product with no Orchestra requirement, and a poor fit for any estate that has moved past Laravel 8, where the honest framing is "vendor and forward-port" rather than "integrate."

Migration path. Treat the package as a pattern to replicate, not a dependency to install, unless Orchestra is already present. The migration is:

1. Enumerate consumed behaviors. Namespaced package views with an app-level override seam (acme::dashboard resolving from resources/views/vendor/acme/ first), active-theme precedence via prepend, and whichever lifecycle hooks we use for cross-cutting output.
2. Implement the narrow slice natively. An extend('view.finder', ...) in a single theme/module service provider that calls prependLocation() for the active theme and addLocation()/addNamespace() for modules, plus class-based composers. This is small, auditable, and ours.
3. Or, if Orchestra is present, pin the version, gate the provider behind a config flag, and document the fallback.

If we do adopt, the finder is registered by extension only — $this->app->extend('view.finder', fn ($finder) => $finder->prependLocation($path)) in boot(). Rebinding is the single most common integration bug and the one that silently breaks sibling providers. All theme path registration lives in one place; scattered prepends produce a stack nobody can reason about during an incident.

Compatibility validation (the critical gate). Before any production exposure, validate against the actual matrix: package discovery on and off, config:cache and view:cache, queue and mail rendering, the exception page, Octane/long-running workers, and the test environment. Config caching freezes config/view.php, so anything computed at runtime (active theme, tenant) must be registered via the finder in boot(), never baked into config.

Sequencing. (1) Behavior inventory and replacement-spec writeup. (2) Decision: replicate vs. adopt-and-own, informed by whether Orchestra is already in the stack. (3) If adopting: pin, gate behind a flag, standalone integration provider, CI matrix. (4) Shadow-mode — run the finder alongside native resolution on a non-critical surface (admin panel, internal tool) before customer-facing paths. (5) Cutover, with the flag as the rollback. (6) Clear compiled views as a mandatory step in any path change, and document that two themes with identically named templates can share a compiled hash.

Operational Impact

Maintenance. We become the maintainer. There is no upstream cadence to ride and no community to absorb fixes. Budget a named owner, a CI compatibility matrix pinned to our Laravel/PHP versions, and a maintenance tax on every framework upgrade — this package will be a blocker in every Laravel major upgrade until it is replaced. Mitigate by keeping the consumed-surface list short and explicit; a small consumed surface is a small upgrade burden.

Support. Effectively none. No support contract, no documentation beyond a README and the provider source, no security disclosure process, no ecosystem pressure to stay compatible. For a component that touches every rendered page, the absence of a disclosure channel is a governance gap, not a convenience issue. Any security-relevant behavior in the finder or engine resolver is ours to audit.

Scaling. Performance is roughly neutral — path resolution is a linear scan over a small list, and compiled views are cached as with native Blade. The real scaling cost is operational, not throughput: as themes and modules accumulate, the path list grows and precedence becomes progressively harder to reason about. Standardize on namespaced views (blog::post.index, admin::layouts.app) from day one to prevent collisions; flat unprefixed names across multiple packages are a latent conflict that manifests as the wrong template rendering in production. Scope wildcard composers to layouts.* or admin::* — a * composer that hits the database will fire on mail, notifications, and the error page, and can turn a 500 into a fatal.

Failure modes to instrument for.

• Wrong theme renders. Almost always precedence or stale compiled views. Debug the finder state (getPaths(), getHints()) and run view:clear before touching Blade.
• Stale compiled artifacts after path changes. Two themes with identically named templates can collide on compiled hash path. Make view:clear a mandatory post-deploy step when theme directories move.
• Memoized existence checks in long-running processes. View::exists() and @includeIf go through the finder; paths added after a check produce surprising false results. Do not cache existence across requests under Octane or in queue workers without invalidation.
• Double ownership of the view layer. If orchestra/theme is present, do not register an independent theme resolver — you get double path entries and non-deterministic precedence.
• Partially compiled views. Conditional Blade::directive() registration leaves some views compiled with the directive and some without. Register directives unconditionally or not at all, and clear compiled views after changing them.
• Silent no-op registrations. A finder mutated in register() before the binding exists resolves and discards a throwaway instance with no error. The "view not found" message listing searched paths is the ground truth for whether a registration landed.

Ramp-up. Low for the mental model — "native Blade plus a configurable, ordered search path that packages, themes, and extensions push into" is a one-day concept for a mid-level Laravel engineer. The cost is concentrated in debugging precedence, which is a senior-engineer skill and an incident-time cost rather than an onboarding cost. Practical ramp plan: one engineer reads ViewServiceProvider and FileViewFinder end to end, writes the consumed-behavior list, and documents the debugging runbook (dump finder state, then clear compiled views, then inspect the not-found path list).

Bottom line for the roadmap. This is infrastructure, not a differentiator — it does not belong on a roadmap as "adopt orchestra/view." It belongs, at most, as an enabling capability behind a theming, white-label, or multi-tenant epic. The decision it actually informs is build the ordered-override pattern in ~200 lines versus take on ownership of an unmaintained Laravel 8 view-layer abstraction with maximal blast radius and zero upstream validation. Absent an existing Orchestra commitment, the recommendation is to use it as a reference architecture, cite the namespaced-views-with-app-override-seam contract in the extension-SDK design doc, and build the narrow slice ourselves.