Weave Code
Resources Laravel Package
orchestra/resources
Resources component for Orchestra Platform, giving Laravel applications a consistent API to register, load, and publish package resources such as views, translations, configuration files, and migrations.
Orchestra Resources provides a lightweight resource and asset management layer for the Orchestra Platform on Laravel. It handles the registration, publishing, and organization of package assets—CSS, JavaScript, images, and other public files—so extensions can ship resources without manual copy steps.
- Centralized asset registration and publishing
- Seamless integration with Orchestra extensions
- Configurable destination paths for public assets
- Simple API for listing and resolving resources
Frequently asked questions about Resources
- What is orchestra/resources used for in Laravel?
- Orchestra Resources is a lightweight registry and facade layer for the Orchestra Platform on Laravel. It lets extensions register named resources, resolve them through a facade, and publish CSS, JavaScript, images, views, translations, config files, and migrations to configured public paths. It is scaffolding for resource registration and routing workflows, not a system of record for business logic.
- Does orchestra/resources support Laravel 10, Laravel 11, or Laravel 5.3+?
- No. orchestra/resources is pinned to Laravel 5.2 and its illuminate/* constraints conflict with Laravel 5.3 and every modern release. Treat Laravel 5.2 as a hard ceiling, and do not attempt to install it in Laravel 5.3+ or current Laravel applications.
- How do I install orchestra/resources in a Laravel 5.2 app?
- Install the pinned version with Composer, then manually register the service provider and facade alias in config/app.php because the package has no auto-discovery. Resource registration must run before routes or controllers resolve resources, so check provider boot order. Avoid exposing a global Resources alias if it can collide with your application classes.
- How do I migrate from Orchestra\Support\Facades\Resources to Orchestra\Resources\Facade?
- Replace imports and alias entries for Orchestra\Support\Facades\Resources with Orchestra\Resources\Facade, which was added in v3.2.0 as the replacement. Inventory every reference across controllers, views, jobs, tests, and config/app.php before changing namespaces. Then re-run the suite to catch any unresolved facade calls.
- How do I publish package assets to a custom public path with orchestra/resources?
- Register the resource with the package and configure the destination path for the public assets; the package handles publishing to that configured location. Keep registration in a service provider that boots before code resolves the resource. Verify the published files land in the expected public directory and are not overwritten by later deploys.
- Is orchestra/resources deprecated, and what are the production risks?
- Yes, it is formally deprecated and carries high, compounding technical risk. It is pinned to Laravel 5.2 and PHP 5.6–7.0-era runtimes that no longer receive security patches, and upstream could delete the repository or Packagist entry. The scheduled removal of Orchestra\Support\Facades\Resources is also a known future break. Get explicit, time-boxed risk acceptance and a dated exit plan.
- How should I test code that uses orchestra/resources?
- Wrap all registration and resolution calls behind a thin application-level adapter instead of calling the facade directly from controllers or views. Bind a fake adapter in your test suite so tests do not depend on Orchestra's facade or provider boot order. This keeps replacement work to one class and removes direct facade usage from application code.
- What are alternatives to orchestra/resources for managing package assets in Laravel?
- On a supported Laravel version, use native resource controllers, routing, and route model binding for the routing layer, and Laravel's service provider asset registration and vendor:publish for package files. Modern front-end builds typically use Vite rather than a custom asset registry. The migration is a reimplementation, not a drop-in package swap.
- Can I still use orchestra/resources if Packagist or the GitHub repository disappears?
- Only if you pin the exact version, commit composer.lock, and mirror the package artifacts in a private Composer repository or satis. That protects builds from upstream removal but does not fix the EOL Laravel and PHP runtime or the deprecated facade. Treat the mirror as containment while you execute the exit plan.
- How do I remove orchestra/resources and migrate to native Laravel resources?
- Inventory every call site, facade namespace, alias, route, controller, view, test, and job that touches the package. Pin the version, commit the lock file, and introduce one adapter that owns all registration and resolution calls. Then reimplement the resource behavior natively on a supported Laravel version and remove orchestra/resources as part of the framework upgrade, not as an isolated swap.
Weaver
How can I help you explore Laravel packages today?