Assets Version Bundle Laravel Package

Technical Evaluation

Verdict: reject as a dependency; retain as a pattern reference and as a diagnostic signal.

Architecture fit — none for Laravel. kachkaev/assets-version-bundle is a Symfony 2/3 bundle, not a Laravel package. There is no service provider, no Laravel package-discovery metadata, and no Laravel-facing API. Its mechanics are Symfony-specific: bundle registration in AppKernel, DI parameters under a kachkaev_assets_version namespace, Twig asset helpers, and a Symfony console command that rewrites a version parameter in place. Nothing transfers to a Laravel application without a rewrite.

More importantly, the problem it solves is already solved natively on our stack. Laravel Mix (mix() + mix-manifest.json) and Vite (@vite, Vite::asset(), content-hashed manifest) provide per-file cache busting out of the box. The bundle's model is a single global version string, which is strictly worse: every deploy invalidates every asset, forcing full re-downloads, whereas content hashing gives per-file granularity and lets unchanged assets stay cached.

Integration feasibility — low and not worth pursuing. A Laravel port would require rewriting the console command as an Artisan command, swapping DI parameter lookup for config(), and replacing Twig integration with Blade directives or a helper — roughly the same effort as writing the capability from scratch against the Vite manifest, with a worse outcome and a permanently-owned fork.

Technical risk — high on the adopt branch, negligible on the reject branch. The upstream is archived, targets Symfony 2.x/3.x (2.8 EOL Nov 2018, 3.4 EOL Nov 2021), has 57 stars and zero dependents, and therefore no community to absorb a fork and no security triage path. Its PHP constraints will fail to resolve against modern base images (PHP 8.2/8.3) without --ignore-platform-reqs, which is itself a red flag for anything production-facing.

Key questions before any decision:

1. Is there a legacy Symfony 2/3 service in the estate that actually depends on this bundle? If so, the deliverable is a retirement plan for that service, not a Laravel integration.
2. What is our current asset pipeline — Vite, Mix, or custom esbuild/Webpack? If Vite, the package is redundant by definition.
3. Are assets fronted by a CDN? A query-string version bump does not purge edge caches; invalidation or hashed filenames are required regardless.
4. Does any downstream component require query-string versioning specifically (e.g., a proxy that strips path segments but preserves query strings)? This narrow case is the only scenario where the bundle's approach outperforms hashed names.
5. Where does cache-busting logic belong in our deploy pipeline (GitHub Actions, Deployer, Envoy) — and is the answer "nowhere yet"?

Integration Approach

Stack fit — out of scope for the Laravel codebase. The correct TPM output here is a written ADR entry: evaluated, rejected, native equivalent documented. That costs an hour and prevents a future engineer from rediscovering the package and re-litigating it.

Replacement map — prefer Laravel-native in every row:

Migration path — one-way, Symfony → modern Symfony, never Symfony → Laravel. If a legacy service depends on this bundle: (1) audit which Twig templates call the bundle's helper; (2) substitute Symfony's native asset() plus Webpack Encore or framework.assets.version; (3) remove the bundle from composer.json; (4) confirm no kachkaev_assets_version config keys remain referenced; (5) smoke-test that rendered asset URLs change on deploy. This work happens entirely on the Symfony side and does not touch Laravel.

Compatibility. The only compatibility surface is PHP. Verify pinned constraints against our platform minimum; expect resolution failures on current base images. If a fork were ever contemplated, that constraint set must be widened and tested — additional cost for a feature worth a few dozen lines.

Sequencing. Week 1: grep the estate to confirm whether any production service depends on it. If no dependency exists, close the ticket and log the ADR. If a dependency exists, schedule removal as routine tech debt inside the platform-upgrade workstream — do not open a Laravel port spike. Week 2: attach the Vite/native recommendation to the asset-pipeline section of the upgrade business case.

Operational Impact

Maintenance. Zero if not adopted — the correct end state. Adopting or forking inherits indefinite maintenance on code with no upstream, no dependable test suite, and no security feed. For functionality this small, "rewrite it in twenty lines we own" dominates "fork it" on every axis.

Support. No vendor, no active maintainer, no community safety net. Incidents become internal archaeology against Symfony 2-era code, with an escalation path of "the one engineer who has read the source." That is an unacceptable bus-factor profile for a production dependency, even a trivial one.

Scaling. The bundle's model scales poorly by design. A single global version invalidates the entire asset set on each deploy, producing a deploy-correlated bandwidth spike as every client re-fetches everything. If HTML is edge-cached, there is also a window where cached HTML references an asset version that has already been superseded or pruned. Content-hashed filenames avoid both characteristics.

Failure modes to design against — these outlive the package:

• Deploy race: version flipped before new assets are uploaded → 404s for the duration of the window. Fix: upload assets first, flip the version last.
• Stale HTML at the edge: cached HTML pins an old version whose files were pruned. Fix: retain the previous asset generation until cache TTLs expire, or invalidate HTML explicitly.
• Config cache drift: version baked into config:cache but not re-cached post-deploy → silent no-op cache busting. Fix: make php artisan config:cache an explicit deploy step with a smoke test asserting the rendered asset URL changed.
• Multi-instance skew: rolling deploys where old and new instances serve different version strings. Usually benign for assets; breaks any client that hardcodes a URL.

Ramp-up. Understanding the pattern — deploy-time token plus URL suffix — takes minutes for any mid-level engineer. Understanding the package is not a worthwhile investment, and that asymmetry is itself part of the case against adoption.

Bottom line for the roadmap: the 0.47 score and 7.31 opportunity rating reflect an interesting idea with no viable adoption path in a Laravel estate. Log it as evaluated-and-rejected with the native Vite recommendation attached, redirect any genuine cache-busting work into the deploy pipeline where it belongs, and use its presence in a dependency audit — if found — as evidence for the EOL-Symfony line item on the platform-upgrade business case.