Asset Manifest Bundle Laravel Package

Product Decisions This Supports

• Cache-busting / asset-versioning strategy: the package answers one narrow question — "given a build that emits hashed filenames, how does the app resolve app.css to app.4f3a9c.css at render time?" That is a real product decision (users seeing stale CSS after a release is a visible, support-ticket-generating defect), but it is a solved one.
• Build vs. buy vs. inline: with 8 stars, 0 dependents, and an archived repo, the "buy" option is effectively off the table. The decision becomes "adopt a maintained equivalent" (Symfony's native JsonManifestVersionStrategy, Webpack Encore, AssetMapper, or Vite in Laravel) or "write ~40 lines of manifest-reading code ourselves."
• Frontend toolchain roadmap: this bundle presumes a manifest-emitting build step (Gulp/Grunt/Webpack-era). Committing to it is a de facto decision to keep a legacy asset pipeline, which constrains any later move to Vite or AssetMapper.
• Deployment/CDN architecture: manifest-driven resolution is what makes immutable, long-max-age caching on a CDN safe. If that's on the roadmap, the capability matters even though this specific implementation doesn't.
• Migration sequencing: useful as a reference pattern if you're extracting a bespoke asset-versioning hack out of a legacy Symfony 2/3 codebase — read the source, don't depend on the package.

When to Consider This Package

Adopt only if all of the following hold:

• You are on a legacy Symfony application (roughly 2.x–3.x) that already depends on this bundle, and removing it is riskier this sprint than leaving it.
• Your build pipeline already emits a manifest in exactly the format this bundle expects, and no maintained alternative reads that format.
• You have accepted the maintenance burden: archived since 2016, no releases in ~9 years, zero dependents, no security response path. MIT licensing means you can fork and vendor it, but you own every future CVE and PHP-version incompatibility yourself.

Look elsewhere in essentially every other case:

• Any new Symfony project: use the framework's built-in manifest support (symfony/asset with JsonManifestVersionStrategy), Webpack Encore, pentatrion/vite-bundle, or AssetMapper (6.4+).
• Any Laravel project: this is not a Laravel package — it's a Symfony bundle and will not integrate via a Laravel service provider. Use laravel-vite-plugin + the @vite directive, or laravel-mix's mix-manifest.json on older stacks.
• Any project where the manifest is trivial: a small internal resolver function is less total cost than an unmaintained third-party dependency in your supply chain.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. zenstruck/asset-manifest-bundle solves a genuine problem — mapping logical asset names to content-hashed build outputs so browsers and CDNs never serve stale files — but the package is archived, last released in December 2016, has 8 GitHub stars and zero known dependents. That profile is a supply-chain liability, not a shortcut.

For executives: this is a "no" with a clear upside. The capability we care about (safe long-lived CDN caching plus reliable cache-busting on release) is available natively in our framework and in actively maintained tooling. Taking on an abandoned dependency would add a future forced-migration project with no offsetting benefit.

For engineering: the concept is worth stealing, the code isn't. If we're on modern Symfony, JsonManifestVersionStrategy or AssetMapper already does this with framework support; on Laravel, Vite handles it. If we find this bundle in a legacy codebase, treat it as migration debt — pin the version, vendor a fork if needed, and schedule replacement alongside the next asset-pipeline change. Recommend we record the decision as "capability adopted via maintained alternative; package rejected on maintenance-risk grounds."