Weave Code
Asset Laravel Package
orchestra/asset
Asset management and pipeline component for Laravel: define named containers, register scripts and stylesheets with dependencies, then render combined, versioned output—keeping templates clean while cache busting and asset URLs stay automatic. Part of the Orchestra Platform ecosystem.
Orchestra Asset is a Laravel package that provides a lightweight asset pipeline for managing and rendering CSS and JavaScript files. It organizes stylesheets and scripts into named containers, making it easy to register, group, and output assets from anywhere in your application.
Assets can declare dependencies, and the container resolves them into the correct loading order automatically. Rendering is handled through simple helper methods or Blade usage, keeping your views clean and your front-end assets centralized.
- Named containers for separating asset groups
- Automatic dependency sorting for scripts and styles
- Register and render assets from PHP or Blade
- Simple helper API for appending, prepending, and outputting
- Integrates cleanly with the Orchestra Platform ecosystem
Frequently asked questions about Asset
- How do I install Orchestra Asset in a Laravel application?
- Install it with composer require orchestra/asset. The service provider is auto-discovered, so you only need to publish the configuration file and then add the two Blade calls: styles() inside the head and scripts() before the closing body tag. A working two-container spike is roughly a one to two dev-day task, since the cost is governance and naming conventions rather than integration.
- Does Orchestra Asset replace Vite or Laravel Mix?
- No. Orchestra Asset is a thin orchestration layer, not a build tool: it never compiles SCSS, bundles modules, or hashes output. Vite should keep owning compiled application bundles, while Orchestra Asset owns the runtime tail such as CDN vendor scripts with hard ordering constraints, per-tenant theme bundles, marketing tags, and legacy pages that have not been migrated yet. Adopting it as a build pipeline makes your front-end story worse, not better.
- How do I render CSS and JavaScript in a Blade template?
- Call styles() inside your head element and scripts() just before the closing body tag; each call renders a container's combined, versioned output so cache busting and asset URLs stay automatic. Registration itself should live in a service provider, controller, or view composer rather than in Blade, so contributors never need to edit the host layout. That separation is what keeps templates clean and assets centralized.
- How does dependency sorting for scripts and styles work?
- Each registered asset can declare dependencies, and the container resolves them into the correct loading order automatically, so you never hand-order tags in a layout. Keep namespaced names such as billing.app instead of a generic app, and keep dependency declarations coarse enough to reason about on a napkin. Because the resolver is silent on mistakes, pair every ordering constraint you declare with an assertSeeInOrder test.
- Which Laravel versions does Orchestra Asset support?
- Orchestra version-tracks Laravel majors, so a given package major (v6.x, for example) maps to a specific Laravel major. Check the composer.json constraints before you plan an upgrade, because framework upgrades become coordinated package upgrades. Put that pairing on your dependency-upgrade runbook rather than discovering it mid-sprint.
- Can I register assets from a controller or service provider instead of a Blade view?
- Yes. The helper API supports appending, prepending, and registering assets from anywhere in the application, including service providers, controllers, and view composers. This is the intended pattern: views only render containers, while registration stays in PHP where it can be reviewed and tested. It is what makes the package a good fit for modules, plugins, and white-label skins injecting into a host layout nobody wants to edit.
- Is Orchestra Asset safe to use with Laravel Octane?
- Octane state persistence is announced in the package but not proven, and containers accumulate state across registrations. A singleton that survives requests is a contamination risk, with the worst case being tenant A receiving tenant B's theme CSS. Treat a soak test with worker recycling, or flushing containers in middleware and documenting it, as a pre-adoption gate rather than a follow-up ticket.
- Why is my stylesheet or script missing from the page?
- The package fails open silently: a misspelled asset or container name produces no tag and no exception. The production symptom looks like a cache problem, which is why it can burn an afternoon of debugging. Add a non-production listener that logs each container's resolved contents, and write assertSeeInOrder tests for every ordering constraint you rely on.
- Does Orchestra Asset support CSP nonces or SRI integrity attributes?
- Rendered tags are plain strings, so nonce and integrity attributes are almost certainly unhandled out of the box. If you enforce a Content Security Policy with nonces, or require integrity= on third-party scripts, budget for post-processing the rendered output or extending the render path. Validate in staging with your production headers actually enforced before rollout.
- Is Orchestra Asset actively maintained, and what happens if it is abandoned?
- It has a single maintainer and zero dependents, so you will be the first to hit your edge cases and abandonment is a realistic scenario. The upside is size: the container and ordering logic is only a few hundred lines, so vendoring it behind the same facade or keeping a fork reduces an abandonment event to a composer.json edit. Decide who owns that vendor-or-fork contingency before rollout, not after an incident.
Weaver
How can I help you explore Laravel packages today?