Assets Version Bundle Laravel Package

Product Decisions This Supports

• Asset cache-busting strategy: build vs. buy vs. borrow. The package addresses one narrow problem — keeping a single global "assets version" token in sync so browsers and CDNs fetch fresh CSS/JS/images after a deploy. The decision it actually informs is how we invalidate static assets: a deploy-time global version string, per-file content hashes, or a manifest-driven pipeline. That decision matters regardless of framework.
• Framework-fit triage — the headline output. This is a Symfony 2/3 bundle, not a Laravel package. It wires up through Symfony's DI container, bundle registration, and Twig helpers — none of which exist in Laravel. Composer may install it, but Laravel will never boot it. The useful product conversation therefore shifts from "should we install this?" to "should we replicate the pattern?"
• Roadmap signal on legacy support. Symfony 2.x/3.x are end-of-life. A package still scoped to them tells us the maintainer's audience sits on unsupported infrastructure — relevant only if we inherit a legacy Symfony estate, and even then it points toward a framework upgrade, not a bundle adoption.
• Patterns worth borrowing into our own stack: a version token bumped automatically at deploy, threaded into asset URLs so we can set aggressive cache headers; CDN purge triggers keyed to the same token; and canary/staged rollouts where the version string doubles as a release identifier.
• Maintenance-cost ceiling. The underlying feature is tiny — a config value, a deploy hook to increment it, a view helper to append ?v=. That sets a realistic cap on what we should ever pay in license, integration time, or dependency risk for this capability: roughly a day of first-party work.
• Dependency-hygiene precedent. 0 stars, 0 dependents, single maintainer, no security response process — a useful calibration case for how we score "unmaintained build-path tooling" against "we could write this in 100 lines."

When to Consider This Package

Adopt only under a narrow set of conditions:

• The codebase is a live Symfony 2.x or 3.x application already using Twig and the Symfony DI container.
• The team explicitly wants a single global version string rather than per-file hashing — acceptable only when assets are few, change together, and long-term per-file caching isn't a requirement.
• There is no existing build pipeline (Webpack Encore, Vite, Assetic) already emitting a manifest — if one exists, it already solves the problem better.
• The team has formally accepted the support risk: EOL framework target, no community, no upstream patch cadence, no advisory channel.

Look elsewhere — or build in-house — when:

• We are on Laravel. Use the native path: Vite (or Mix) with a manifest, consumed via @vite / mix(). That delivers per-file content hashing, long-term immutable caching, and zero new dependencies.
• We are on Symfony 4+. Use symfony/asset versioning with Encore's manifest.json / entrypoints.json.
• We need production-grade asset delivery: per-file fingerprinting, SRI, CDN integration, atomic rollbacks. A global token invalidates everything on every deploy — a poor trade for large asset graphs and a thundering-herd cache miss at each release.
• Dependency hygiene matters — which it does for anything crossing the build/deploy path. Zero dependents is a strong prior against community vetting.
• A global token is genuinely mandated (CDN purge contract, cache-warming scripts, mobile webview pinning). Satisfy it with a CI-generated APP_ASSET_VERSION env var read via config() — no package required.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated grizzlylab/assets-version-bundle as a candidate for solving browser-cache staleness on static assets. It is not a fit for our Laravel platform: it is a Symfony 2/3 bundle with no Laravel integration path, no community adoption (0 stars, 0 dependents, single maintainer), and a framework target that reached end-of-life years ago. The capability it provides is small and well understood, and our existing Vite/asset pipeline already delivers a strictly better version of it for free. Recommendation: do not adopt. Treat it as a documented reference pattern and close the evaluation. No cost, no added risk, no further time spent.

For engineering (the substance): The pattern is worth naming even though the package isn't. It maintains a single project-wide version identifier, bumped as part of the deploy process and appended to asset URLs — a cheap, crude cache-bust. In Laravel we already get a better version automatically: content-hashed filenames via the Vite manifest, resolved by @vite(), which invalidates only changed files instead of everything. If we ever need a global release token for CDN purge coordination or staged rollouts, we should build a small first-party helper — config value plus deploy step plus Blade directive, roughly a day including tests — rather than carry an unmaintained third-party dependency into the release path. Installing this bundle would either fail on PHP/Symfony constraints or leave dead code in vendor/ that never boots, while creating a false sense that the capability is covered. Next step, if a concrete gap is proven: a one-day spike on a first-party helper or an APP_ASSET_VERSION env var — not an integration ticket for this bundle.