Weave Code
Support Providers Laravel Package
orchestra/support-providers
Orchestra Support Providers delivers service-provider bindings and bootstrap helpers for Orchestra Platform, simplifying registration of core support services and keeping Laravel package integration consistent across applications.
Support (Providers) Component for Laravel and Orchestra Platform
Frequently asked questions about Support Providers
- What is orchestra/support-providers used for?
- It provides base service-provider classes and bootstrap helpers that Orchestra Platform packages extend to register bindings, merge configuration, and participate in deferred loading. It is provider-registration plumbing rather than an end-user feature, so it mainly matters when you are building or maintaining Orchestra-style extensions. A standard Laravel application has little reason to install it.
- Does orchestra/support-providers work in a vanilla Laravel app?
- Mechanically yes, since it is a Composer package that autoloads under Laravel, but it adds no capability over Illuminate\Support\ServiceProvider and DeferrableProvider. It couples your bootstrap to Orchestra conventions that the framework itself does not know about. For a standard app the recommendation is to decline adoption unless a real Orchestra interop requirement exists.
- How do I install orchestra/support-providers?
- Install it with Composer, for example composer require orchestra/support-providers, and let PSR-4 autoloading pick up the classes. No publish step is required just to use the base provider classes. If you are already on Orchestra Platform it is likely present transitively, so the real task is pinning an explicit version and documenting ownership.
- Which Laravel and PHP versions does orchestra/support-providers support?
- The authoritative answer is the require block in the composer.json of the specific tag you install, not release dates or the README. Check that the Laravel major range explicitly covers the version you run, and treat the Laravel constraint as the binding one rather than the PHP range. Never force an install with --ignore-platform-reqs, because that converts a compatibility question into a silent runtime bug.
- What do the base providers add beyond Laravel's native ServiceProvider?
- They add Orchestra-specific conventions such as config merge behavior, provider bindings, and participation in Orchestra's deferred loading and manifest patterns. That is useful when other Orchestra packages expect those conventions. It is not a general-purpose improvement over Illuminate\Support\ServiceProvider, so the value depends entirely on whether your code must target Orchestra.
- Is orchestra/support-providers a hard dependency of Orchestra Platform?
- It is part of the Orchestra Platform support layer and is often pulled in transitively by Orchestra applications, so many teams adopt it simply by having it in the lockfile. Whether it is strictly required or an optional convenience depends on the Orchestra packages you use, so run a dependency-tree audit before assuming. The practical action is an explicit pin plus a note on who owns the upgrade cadence.
- How do I test a package that extends the Orchestra support provider?
- Write normal Laravel package tests against your concrete provider and assert the bindings and merged config your package promises. Use Orchestra Testbench if your package targets Orchestra conventions, since it boots an application container for you. Keep a thin wrapper provider so most of your test surface stays on Illuminate contracts rather than Orchestra internals.
- Does orchestra/support-providers support deferred service providers?
- Yes, deferred registration is one of the reasons the abstraction exists, and the base classes are designed to plug into Orchestra's provider lifecycle. The exact behavior follows Orchestra's implementation rather than Laravel's, so verify it against the tag you install. If you only need standard deferred loading, Laravel's DeferrableProvider already covers that.
- What are the production risks of depending on orchestra/support-providers?
- The main risks are ecosystem-driven rather than code-driven: a bus factor of one, a thin community surface with no third-party validation, and version constraints that can gate a Laravel major upgrade for the whole application. Because you cannot self-unblock lifecycle changes without forking, define an ownership trigger such as no compatible release within a set number of weeks after a Laravel major. Also watch for convention drift between Orchestra's config merge and standard vendor:publish flows.
- Is orchestra/support-providers maintained, and what are the alternatives?
- It is effectively single-maintainer and follows Laravel majors without a responsiveness guarantee, so treat maintenance as a risk you own rather than a vendor promise. The direct alternative for standard applications is Illuminate\Support\ServiceProvider and DeferrableProvider, which cover ordinary bindings and deferred loading. If you need Orchestra interop, the pragmatic alternative is a thin internal base provider that delegates to Orchestra only where required.
Weaver
How can I help you explore Laravel packages today?