Asset Manifest Bundle Laravel Package

Getting Started

Read this first: zenstruck/asset-manifest-bundle is a Symfony bundle, not a Laravel package. There is no ServiceProvider, no facade, no publishable config, and no auto-discovery. It was last released in December 2016, is archived, and has zero dependents — so the realistic "getting started" for a Laravel developer is: do not install it. Laravel already ships the same capability through Vite (@vite, Vite::asset()), and this bundle targets Symfony 2/3-era APIs that will collide with the Symfony 6/7 components modern Laravel pulls in.

If you're assessing it because you have a legacy Symfony service or you're porting an app, the minimal path is:

1. composer require zenstruck/asset-manifest-bundle in the Symfony app only.
2. Register the bundle in AppKernel/bundles.php.
3. Point its manifest_path config at your generated manifest (e.g. web/build/manifest.json).
4. Use the provided asset/manifest service wherever you previously hardcoded filenames.

Where to look first: the bundle class and its DependencyInjection/ extension. The whole package is effectively one small service that json_decodes a manifest file and maps a logical asset name to a hashed output path. That is the entire value proposition — about 30 lines of code.

First Laravel use case (the reason you're here): replacing asset('css/app.css') with a lookup against public/build/manifest.json so hashed filenames resolve correctly in production. Do this with Vite's built-in helpers; only hand-roll it if you're consuming a non-Vite manifest (Webpack Encore, Rollup, a CMS-generated map).

Implementation Patterns

Treat the bundle as a reference implementation, then implement the pattern natively in Laravel.

• Manifest reader service. A small class with __construct(string $manifestPath) and resolve(string $entry): string. Parse once, cache in a property, expose a clear failure mode.
• Container binding. Register it as a singleton in AppServiceProvider so the JSON is read once per request/worker, not per Blade render.
• Blade integration. Either a global helper (manifest_asset('images/logo.png')) or a custom directive @asset('...'). Keep HTML escaping at the Blade layer, not in the resolver.
• Dev vs. prod branching. Local dev should fall back to unhashed source paths (or the Vite dev server URL); production should require a manifest entry. This mirrors what the bundle did with its "no manifest / dev" fallback, just done explicitly.
• CDN / asset URL prefixing. Resolve the path first, then pass through URL::asset() or prepend config('app.asset_url'). Don't bake absolute URLs into the manifest.
• Normalizing formats. If you consume both Encore (entrypoints.json) and Vite (manifest.json), write one adapter that emits a common { entry: { file, css, imports } } shape so the helper has a single contract.
• Deploy-time validation. Add a tiny artisan command that asserts every entry your app references exists in the freshly built manifest — much cheaper than discovering missing hashes at runtime.

Integration tip: bind your reader and inject it where needed rather than calling a global helper from services; helpers are fine at the Blade edge only.

Gotchas and Tips

• It will not install cleanly in a modern Laravel app. No Laravel service provider, and its Symfony DI/HttpKernel constraints predate current Symfony. You'd be adding dead weight plus dependency conflicts.
• Abandoned software. Archived since 2016, 8 stars, 0 dependents, no PHP 8 or security maintenance. Never a new-project dependency.
• Manifest format drift is the #1 bug. Old Symfony/Encore manifests are flat ({"app.js": "app.abc123.js"}); Vite's manifest is nested ({"resources/js/app.js": {"file": "...", "css": [...], "imports": [...]}}). Copy-pasting the bundle's lookup logic into Laravel will break on Vite immediately.
• Path vs. URL confusion. Manifest keys are source paths; values are output paths relative to public/. Don't double-prefix /build/ or you'll get /build/build/app.abc.js.
• Missing-entry behavior. Decide deliberately: throw loudly in production, fall back in local. Silent fallbacks in prod surface as 404s found by users, not tests.
• Caching pitfalls. Don't file_get_contents per call, but also don't Cache::rememberForever without invalidation — you'll serve stale hashes after a release. Key the cache by manifest mtime or app version.
• Atomic deploys. With release symlinks, a long-lived cache or a public/ symlink can resolve to the previous release's manifest. Clear/rebuild per deploy.
• Sub-path hosting. A hand-rolled resolver often forgets URL::asset(), breaking apps served under /subdir.
• Extension point, if you must. Decorate Laravel's Illuminate\Foundation\Vite or bind your own manifest reader. Do not attempt to bridge Symfony's asset packages into Laravel.
• Verdict: good idea, wrong ecosystem, dead package. Steal the 30-line manifest-lookup pattern (or just use Vite) and leave the dependency behind.