Assets Laravel Package

Product Decisions This Supports

• Framework upgrade sequencing (Laravel 9 → 10). This release removes a hard blocker in the dependency graph. If digitallyhappy/assets (Basset) sits in the critical path of our admin panel or any Blade-rendered surface, we can now schedule that upgrade rather than defer it or fork the package.
• Build vs. buy on asset delivery. Basset covers a narrow but real gap: registering CSS/JS from Blade views and from controllers, deduplicating loads, and optionally caching CDN-hosted files to local disk. Building this in-house is ~1–2 sprints of work plus ongoing maintenance; buying it is a composer require.
• Feature work it unblocks. Controller-level asset injection lets feature modules and third-party packages ship their own JS/CSS without editing a central layout — useful for plugin architectures, white-label admin panels, and per-tenant UI variants.
• Resilience/ops decisions. The CDN-with-local-cache mode is a lever for reducing third-party CDN dependency at runtime and improving cold-start performance in restrictive or air-gapped environments.
• Not a bundler decision. This does not replace Vite. The realistic roadmap position is: Vite for first-party app bundles, Basset for runtime-registered, package-supplied, and admin-panel assets. Treating it as a Vite alternative would be a misread.

When to Consider This Package

Adopt when:

• The product is server-rendered Blade (including Livewire/Inertia hybrids where Blade still owns the layout).
• You are on Laravel 8, 9, or 10 — this release explicitly extends the supported range to 10.
• You use or plan to use Backpack for Laravel, where this package is the native asset pipeline and carries the lowest integration cost.
• You have a modular/plugin architecture where packages must contribute assets without central layout edits.
• You need deduplication of the same asset loaded from multiple partials, or CDN-to-local caching for performance, offline, or compliance reasons.
• You want a small, low-config surface rather than a build-toolchain commitment.

Look elsewhere when:

• The frontend is fully bundled via Vite (or Webpack) with no meaningful runtime asset registration — the package adds a parallel path with little payoff.
• You need HMR, tree-shaking, code-splitting, or TypeScript transpilation — that is a bundler's job, not this package's.
• You are on Laravel 11+. This release tops out at 10; verify the composer.json constraint and CI matrix before assuming forward compatibility.
• Bus-factor is a hard constraint. This is a small-team/community-maintained package under the DigitallyHappy (Backpack) umbrella. If it becomes load-bearing for a revenue-critical surface, budget for the possibility of pinning or vendoring.
• You need asset integrity/SRI, CSP nonce management, or fine-grained cache invalidation as first-class features — confirm support explicitly rather than assuming.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source Laravel package that manages how CSS and JavaScript get loaded into our server-rendered pages. Its new 2.1.0 release adds Laravel 10 support, which means it no longer blocks our framework upgrade — that is the headline. It is a low-cost, low-risk dependency: it eliminates duplicate asset loads, lets individual features and third-party packages ship their own styling and scripts without touching a central template, and can cache CDN-hosted files locally so pages stay fast and resilient if a CDN degrades. It does not replace our frontend build tooling, and it is maintained by a small team, so we would pin the version and treat it as infrastructure to monitor rather than a strategic platform bet.

For engineering (bullets):

• What changed: 2.1.0 is a minor, additive release — Laravel 10 support added (PR #16). No breaking changes, no deprecations, no API surface changes indicated. Upgrade from 2.0.4 is low-risk.
• What it buys us: asset registration from both Blade directives and controllers, automatic deduplication across partials, optional CDN-to-local caching with artisan cache/check commands, and inline asset blocks.
• How it fits: run it alongside Vite, not instead of it. Vite owns the app bundle; Basset owns runtime-registered and package-supplied assets. Document that boundary or we will get two competing asset paths.
• Risks to close before rollout: confirm the Laravel 10 constraint is actually exercised in CI (a one-line changelog is not evidence of a tested matrix), confirm our PHP version is inside the supported range, and check whether an 11.x/12.x constraint is on the maintainer's roadmap.
• Migration note: if we are mid-upgrade, land the framework bump and this dependency together in a single PR so we do not strand a half-upgraded asset pipeline; smoke-test the admin panel's asset rendering and the cache-warm command specifically.
• Ownership: assign a named maintainer for version pinning and upgrade watch.