Weave Code
View Laravel Package
orchestra/view
Orchestra View provides view-layer utilities for Laravel applications, extending the framework's view factory with helpers for resolving, composing, and managing templates within the Orchestra ecosystem. It keeps theme and template handling lightweight and consistent.
View Component for Orchestra Platform
Frequently asked questions about View
- What does orchestra/view do in a Laravel application?
- Orchestra View is not a templating engine. It extends Laravel's view factory and swaps the view.finder for an ordered, theme-aware FileViewFinder so templates resolve across themes, packages, and modules. It keeps Blade rendering consistent within the Orchestra Platform ecosystem.
- Which Laravel versions does orchestra/view support?
- The release trail ends at v6.0.0, which pins Laravel 8. There is no evidence of forward-porting to newer Laravel releases, so Laravel 9, 10, 11, and later are not validated. On a modern estate, using it is a fork-and-maintain exercise rather than a normal adoption.
- How do I install orchestra/view with Composer?
- Install it with Composer using a version constraint that matches the Orchestra Platform and Laravel 8 support matrix. Then confirm the package service provider is registered, either through package discovery or manually. The integration surface is small: review ViewServiceProvider register and boot to see which container keys are rebound.
- Does orchestra/view work outside the Orchestra Platform ecosystem?
- No. It fits cleanly only inside the Orchestra Platform ecosystem, where orchestra/theme and orchestra/extension push paths through the same finder. Outside that ecosystem it is overhead on top of native Blade. Treat it as a solution without a platform unless you already run Orchestra.
- How does theme-aware view resolution work in orchestra/view?
- A container-level swap replaces Laravel's view.finder with an ordered FileViewFinder that supports prepend, namespace hints, and extension methods. Theme, package, and module paths are pushed through the same finder, and prepend order behaves like a stack where the last call typically wins. The ordering semantics are implicit and fragile, so enumerate the exact behaviors you consume.
- Can orchestra/view conflict with other packages that register view paths?
- Yes. Two providers owning the view layer can produce double path entries and unpredictable precedence, which often surfaces as the wrong theme rendering. Rebinding view.finder instead of extending it can also discard other providers' registrations without an error. Registering in register instead of boot can resolve and mutate a throwaway finder.
- Is orchestra/view actively maintained and safe for production?
- There is no evidence of active maintenance: the release trail stops at Laravel 8, and the package has zero stars and zero dependents. That means no production bug reports, no compatibility pressure, and no third party to lean on. Adoption effectively transfers maintainership to your team.
- What are alternatives to orchestra/view for theme-aware Blade templates?
- For most teams, native Blade with explicit view paths and namespaces is the safer baseline. A roughly 200-line internal implementation of ordered path registration plus a Composer hook is often cheaper than owning this package. If you are already on Orchestra, use the maintained Orchestra theme and extension packages rather than adding a second view owner.
- How should I test a Laravel app that uses orchestra/view?
- Test resolution order, namespace overrides, prepend precedence, lifecycle events, and the engine resolver, because those are the behaviors you would actually consume. Add a CI compatibility matrix for your Laravel and PHP versions, and gate the provider behind a config flag so you can revert to native view services in one line. Also test mail, notifications, and the exception page, since rendering sits on every request.
- What are the main risks of adopting orchestra/view?
- The main risks are version drift, maximal blast radius, silent failure modes, and fragile ordering semantics. Rendering touches every web request, queued mail, notification, and exception page, so a defect is a site-down defect. With no upstream validation, you also own the compatibility matrix and the fallback plan.
Weaver
How can I help you explore Laravel packages today?