Asset Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the asset pipeline — and the answer here is still "neither." This bundle remains a thin Symfony DI wrapper around hostnet/asset-lib (path resolution, versioning, URL generation). Version 1.0.7 changes only the version floor, not the capability. It stays a reference implementation of the domain model, not a dependency to adopt.
• Framework-fit triage — unchanged and now cleaner. Still Symfony-bundle-shaped: no Laravel service provider, no facade, no publishable config. Adopting it in a Laravel codebase is still a decision to import Symfony's DI and config components, which should be rejected on its own merits.
• Vendor-risk and maintenance-burden scoring. Still archived, still 5 stars, still 0 dependents, low composite score (0.1175). 1.0.7 does not reverse the archive; it is a single-line floor bump on a dead branch. The "who fixes the CVE / who merges the PHP 8.x compat PR" test still fails.
• Release-discipline signal (new). Raising the minimum Symfony version to 5.4 is a breaking change shipped in a patch release (1.0.6 → 1.0.7). Anyone on Symfony ≤5.3 gets a silent break on composer update. That is a governance data point for dependency policy — it belongs in the same bucket as "archived," not a separate argument.
• Roadmap de-prioritization — reinforced. Still confirms asset versioning is commoditized; keep it a configuration task in Vite / Mix / symfony/asset, not a roadmap line item.
• Legacy-estate use case — now narrower. The previous assessment scoped this to inherited Symfony 3/4 estates. The 5.4 floor removes that justification: the tool no longer helps the Symfony 3/4 apps it was most plausibly useful for, and Symfony 5.4 is itself at or past end of security support. The remaining addressable set is "Symfony 5.4+, already carrying hostnet/asset-lib, pre-migration" — a small and shrinking box.

When to Consider This Package

• Only if you are on Symfony 5.4 or later, already have hostnet/asset-lib in the dependency graph, and need the container wiring to unblock a legacy app before a planned migration. Pin the version explicitly — do not float on ^1.0, given the patch-level floor bump. Ship with a dated removal ticket.
• As a reading source, not a dependency. Still the cheapest use: a small worked example of asset versioning and public-path resolution. Read-only use carries no support obligation and is unaffected by the version floor.
• Look elsewhere when: the target is Laravel — use Vite (laravel-vite-plugin) or laravel-mix for fingerprinting plus asset() / Vite::asset() for URLs. Also look elsewhere for greenfield Symfony (symfony/asset + symfony/asset-mapper), for Symfony ≤5.3 (no longer supported — 1.0.7 will break you, and 1.0.6 is not a long-term answer), for anything needing active security response, for PHP 8.3+/8.4 support guarantees, and wherever "archived" is a disqualifier in your policy.

How to Pitch It (Stakeholders)

To executives: no change to the recommendation — this remains a small, archived Symfony plugin with no downstream users, and the new release is a one-line version floor rather than a revival. It is still not a candidate for adoption and carries no commercial upside. What the release does add is a cautionary data point: a breaking change was published as a patch version on an unmaintained branch, which is exactly the failure mode our dependency policy is meant to catch. Recommendation stands: no spend, no integration, no vendor conversation — close it out and reuse the pattern knowledge.

To engineering: do not add this to composer.json. 1.0.7 raises the minimum Symfony to 5.4 as a patch release, so it is now both Symfony-only and a floating-version hazard; if you ever inherit it, pin the exact version. It still would drag Symfony's DI/config stack into a Laravel app for functionality Laravel already ships — Vite's manifest gives you content hashing and Vite::asset() gives you URLs. Read hostnet/asset-lib's source for twenty minutes if you want the algorithm. Critically, re-scope any inherited-codebase flagging: the earlier "Symfony 3/4 migration" note no longer applies to this package, so re-check which version your inherited apps actually pin before planning a symfony/asset migration with a dated owner.