Assets Version Bundle Laravel Package

Product Decisions This Supports

Label check first: this is a Symfony 2/3 bundle, not a Laravel package. That correction drives every decision below — there is no service provider, no Laravel-facing API, and no adoption path on a Laravel stack.

• Cache-busting as a deploy-time concern, not a feature. The real product need is "no user sees stale CSS/JS after a release, and rollback is predictable." That need is legitimate and recurring. This bundle is one historical implementation of it.
• Build vs. buy vs. own. The functionality is a deploy hook that writes a version token plus a template helper that appends it to asset URLs — a few dozen lines. The buy option is weak here: archived upstream, zero dependents, 57 stars. Default to "own the pattern."
• Legacy estate triage. Finding this in a dependency audit forces a retain / replace / retire decision, not an adopt/no-adopt one. It is evidence of an unmodernized Symfony application, and therefore an input to the platform-upgrade or re-platform business case.
• Roadmap signal, not a roadmap input. Symfony 2.8 (EOL 2018) and 3.4 (EOL 2021) are out of support. Presence in the tree is a lagging indicator of technical debt — useful for prioritization, not for enabling new features.
• Laravel-side applicability: effectively zero. Vite and Mix already emit content-hashed filenames with @vite/Vite::asset()/mix(). Adding this would be strictly worse than what ships in the framework today.
• Where the pattern still earns attention: CDN invalidation on release, QA/customer reproducibility ("which build am I on?"), and coordinating cache purge with the deploy pipeline. Solve these deliberately — just not by adding this dependency.

When to Consider This Package

Only consider it if all of the following hold:

• You operate an existing Symfony 2.x/3.x application that is not being upgraded this cycle.
• Assets are served from web/ with stable filenames — no build pipeline producing hashes.
• You need deploy-time version stamping and accept forking the code, since upstream is archived and will receive no fixes.
• Security and licensing review accepts an archived MIT dependency you now effectively maintain.

Look elsewhere — or don't bother — when:

• Stack is Laravel: use Vite (Laravel 9+) or Mix content hashing. This package is inapplicable.
• Stack is Symfony 4+: use Webpack Encore, AssetMapper, or the native framework.assets.version. The framework already does this.
• You need vendor support, CVE response, or SBOM provenance: archived + zero dependents means no safety net; every break is yours to fix.
• A framework upgrade is already planned: fold cache-busting into that work rather than bolting on a dead dependency first.
• Assets are already content-addressed: query-string versioning is redundant, and a single global version is coarser than per-file hashes.

Treat any engagement as "vendor the code, not the dependency" — copy the pattern into a deploy step you own.

How to Pitch It (Stakeholders)

For executives: This is a tiny, archived Symfony 2/3 utility for cache-busting static assets — not a Laravel package, and not something to add to our stack. Its value is diagnostic: it tells us where we still run end-of-life Symfony. Recommendation: no new adoption. If it appears in a legacy app, replace it with a small deploy script we own during the next maintenance window. Low effort, removes an unmaintained dependency, and cuts supply-chain risk at negligible cost.

For engineering: The mechanism is version-stamping — write a build/version token at deploy time and append it to asset URLs so browsers and CDNs fetch fresh files. We can reproduce that in a short deploy hook plus a template helper, which beats carrying an archived bundle with zero dependents. On Laravel this is already solved by Vite/Mix hashing; on Symfony 4+ use the native assets.version or Encore. Action: audit the estate for usage, replace with owned code or native tooling, and log the finding as evidence for the platform-upgrade backlog. Watch the deploy-ordering failure mode: upload new assets first, flip the version last, and never prune the previous generation until cache TTLs expire.