Hashed Asset Bundle Laravel Package

Product Decisions This Supports

Flag first: this is not a Laravel package. It's a Symfony bundle (incenteev/hashed-asset-bundle) built for symfony/asset. If your stack is Laravel, this is out of scope — Laravel already gets content-hashed filenames from Vite/Mix manifests, and adopting this would mean introducing Symfony components for no reason. Treat this assessment as applying to Symfony-based services in the portfolio only.

For Symfony services, the decisions it informs are narrow but real:

• Cache-busting strategy on the roadmap. This package replaces a single global assets_version string with a per-file content hash. The product consequence: you can serve assets with Cache-Control: max-age=31536000, immutable and only invalidate the files that actually changed on deploy, instead of purging the whole CDN/browser cache on every release. That's a measurable win in CDN egress and repeat-visit latency for asset-heavy pages.
• Build-vs-buy for a small infra concern. The core capability is a custom VersionStrategy implementation — roughly 20–50 lines against Symfony's own interface. The realistic options are (a) write it in-house, (b) use Symfony's built-in JsonManifestVersionStrategy if you already emit a manifest, (c) adopt this bundle. This is a "buy" only if you value zero implementation time over supply-chain risk.
• Legacy Symfony modernization sequencing. If a service is on Symfony 4/5 and not yet on AssetMapper (Symfony 6.4+), this is a cheap interim improvement. If AssetMapper migration is already on the roadmap, adopting this bundle now is throwaway work — AssetMapper provides content-hashed, importmap-driven assets natively. This package should be evaluated as a bridge, not a destination.
• Static asset hosting / CDN contract decisions. Per-file hashing is a prerequisite for aggressive immutable caching at the edge. If a CDN cost or cache-hit-ratio initiative is active, this is a lever worth quantifying.
• Not a fit for: asset bundling, minification, transpiling, or image optimization. It does one thing — version strings derived from content hashes.

When to Consider This Package

Adopt (or seriously evaluate) when all of these hold:

• The service is Symfony 4.x/5.x (or 6.x pre-AssetMapper) using symfony/asset and Twig's asset().
• Assets are static files committed to or deployed alongside the repo — no Webpack Encore or Vite manifest already producing hashed filenames. If a manifest exists, you already have this.
• You serve assets through a CDN or reverse proxy with long TTLs and want per-file invalidation rather than full purges.
• AssetMapper migration is not planned in the next 1–2 quarters.

Look elsewhere (or skip) when:

• Laravel or any non-Symfony stack — wrong tool entirely.
• Symfony 6.4+ — use AssetMapper; it's first-party, maintained, and covers this plus more.
• Encore/Vite in use — JsonManifestVersionStrategy (or the framework's equivalent) already solves it with first-party support.
• Supply-chain sensitivity is high. This is the real risk: 26 stars, 0 dependents, effectively a single-maintainer project. Zero dependents means no downstream ecosystem has battle-tested it. Recent release activity (2026-02-13) is a positive signal for maintenance intent, but it does not substitute for adoption.
• You need anything beyond versioning — bundling, CSS preprocessing, integrity hashes (SRI), or preload hints.

If you do proceed: vendor the version-strategy class into your own codebase rather than taking a Composer dependency. MIT license permits it, the surface area is tiny, and it eliminates the abandonment risk entirely while keeping the behavior.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, MIT-licensed utility that makes browser and CDN caching more precise for our Symfony services — only assets that actually changed get re-downloaded, which improves repeat-visit performance and reduces CDN bandwidth. The catch is that it's a niche project with almost no adoption (26 GitHub stars, zero dependent packages), so I don't recommend taking it as a dependency. Instead, we can copy the ~50 lines of logic it implements into our own codebase under its permissive license and get the same benefit with zero maintenance risk. Treat this as a tactical optimization for older Symfony services, not a strategic platform choice, and it's superseded by Symfony's own AssetMapper for anything we modernize.

For engineering:

• Scope: implements Symfony\Component\Asset\VersionStrategyInterface, returning a content-hash-derived version per asset. Small, readable surface — review the source before deciding.
• Preferred path: read it, reimplement or vendor the strategy class in-house. MIT allows it. This sidesteps the 0-dependents / single-maintainer risk and lets us adapt hashing (e.g., truncation length, algorithm, handling of remote assets) to our needs.
• Do not adopt if we're on Encore/Vite (manifest strategy already covers it) or on Symfony 6.4+ (AssetMapper is the first-party answer).
• If we do add it as a dependency: pin an exact version, and confirm behavior for assets referencing other assets (fonts, images in CSS) and for non-local/remote URLs, since hash-of-file requires filesystem access.
• Effort estimate: hours, not days. The decision cost of evaluating this exceeds the implementation cost of writing it ourselves — which is itself a relevant signal.