Basset Laravel Package

Product Decisions This Supports

• Component-level asset ownership. Lets each Blade component, widget, or package partial declare the CSS/JS it needs and trust the page to include it exactly once — removing the need for a central "asset manifest" maintained by hand as the UI grows.
• Build vs. buy on plumbing. A custom "has this script already been rendered?" registry is trivial to write and expensive to keep correct (render order, nested components, partials rendered twice, AJAX-refreshed regions). This is a classic buy-the-commodity decision; the package is MIT and small enough that the buy side is cheap.
• Roadmap enabler for composable surfaces. Any roadmap item that adds repeatable UI blocks — dashboard widgets, form field types, admin panel plugins, marketing page sections, embeddable modules — benefits from a dedupe primitive existing before those blocks ship, rather than retrofitting one after duplicate-asset bugs surface.
• Performance and correctness budget. Duplicate <script> tags mean duplicate downloads (when not cached), duplicate parse/execute cost, and occasionally duplicate event listener registration — a class of bug that is hard to reproduce and easy to prevent.
• Ecosystem/extension posture. Signals that third-party extensions can ship their own assets without coordinating with the host app, which is a prerequisite for any plugin marketplace or partner-integration strategy.
• Low-regret adoption. Single-purpose, no build-step, no runtime service, no data model. Reversible in an afternoon if it disappoints.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Laravel 10+ with server-rendered Blade, not an SPA or a bundler-first frontend.
• You have — or expect — multiple independent contributors to markup: internal components, packages, admin-panel widgets, or tenant-specific partials that each want to enqueue assets.
• You have observed, or can reasonably anticipate, duplicate asset inclusion (the same <script src> twice on a page, or a widget rendered twice in a layout).
• You want the fix to be a one-line directive at the call site rather than a convention documented in a wiki that new engineers will miss.

Look elsewhere when:

• Vite/npm already owns the asset graph. If everything goes through a bundler with a single entry point, dedupe is largely solved for you and this adds a second, parallel mechanism.
• You need vendor-backed support or a broad dependency footprint. 208 stars and effectively no downstream dependents means the community signal is thin; treat the Backpack team's maintenance as the real support contract and confirm their release cadence matches your Laravel upgrade cadence.
• Your frontend is Inertia/Livewire-heavy and asset inclusion happens through component lifecycles rather than full page renders — verify behavior across partial re-renders before committing.
• HTTP/2, preload hints, or an edge/CDN layer already collapse the cost of the duplication you're seeing; the package fixes correctness, not bandwidth, and if bandwidth is the actual problem this is the wrong lever.
• You are on Laravel 9 or below, or on a version outside the package's supported window — a hard constraint given the explicit Laravel 10+ framing.
• A single layout with a handful of static assets. The coordination problem this solves does not exist yet; adopt later when it does.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed utility that makes sure a given CSS or JS file is loaded only once per page, no matter how many UI components ask for it. The business case is narrow but real: as we add reusable interface blocks — dashboard widgets, admin panels, embeddable modules — each one brings its own styles and scripts, and without a dedupe layer the same files get shipped and executed multiple times. That shows up as slower pages, flaky duplicate-event bugs, and engineering time spent debugging them. Cost is near zero, the code is ours to read, and removal is a one-day reversal if it doesn't earn its place. The tradeoff to accept explicitly: support is community-grade with a thin public footprint, so we are betting on the maintainers' track record rather than on a large ecosystem.

To engineering (the ask): Adopt it as the standard way components declare assets. It's a Blade-level directive, no build step, no config, no service provider gymnastics — it slots into what we already do. It replaces the bespoke "check if already rendered" helper that keeps getting reimplemented per project and keeps getting the edge cases wrong. Spike it in one module first: instrument duplicate asset inclusions and total page weight before and after, and confirm behavior when a component renders twice in a single request and across partial refreshes. If the numbers don't move, we drop it.

To the adopting team (guardrails): Pin the version, track the upstream Laravel support matrix against our upgrade calendar, and keep the call sites behind our own thin wrapper so a future swap is mechanical. Do not let it become the only asset path — the bundler still owns anything that needs compilation.