spekkionu/assetcachebuster
A Laravel package that adds cache-busting version strings to asset URLs, helping browsers load updated CSS and JavaScript after deployments. It integrates with Laravel's asset helper and supports configurable versioning for reliable cache invalidation.
Architecture fit: Unchanged in substance. The package still solves a narrow, well-understood problem — appending a build-unique hash to asset URLs so browsers fetch fresh files after a deploy — via a service provider, a config file, a hash-generation step, and a Blade helper/directive that rewrites asset() output. v2.0.0 does not add capability; it widens the framework constraint. The architectural verdict therefore stands: clean and low-ceremony for an app serving assets from public/ with no bundler, but competing with a first-party feature. The release marginally enlarges the defensible window — Laravel 5.0 through 5.3, before Mix arrived in 5.4 — which is a real but very small slice of the install base. From 5.4 onward (mix()) and 9+ (@vite), the framework does this natively with build-time manifest hashing, and the package remains strictly redundant.
Integration feasibility: Improved at the margin, still gated. The v2.0.0 note — "Adds compatibility with Laravel 5" — retires the specific blocker the previous assessment called out, namely that the release line was pinned to Laravel 4.x / early 5.0 and would fail Composer resolution on a Laravel 5 app. That makes adoption on a Laravel 5.x codebase a genuine composer require rather than a constraint-surgery exercise. Three caveats keep this from being a green light. First, the release note does not state which Laravel 5 minors are covered; given the project's vintage, the realistic ceiling is 5.0–5.3, and a 5.4+ app should be using Mix regardless. Second, the note says nothing about PHP version support — PHP 5.5/5.6-era constraints are likely, so a Laravel 5 app running on PHP 7.x/8.x may still hit platform resolution failures. Third, a 1.x→2.0.0 major bump nominally signals breaking changes while the note describes only additive compatibility; with zero known dependents the blast radius is nil, but if we have any internal 1.x usage it needs a diff review before upgrading. Anything on Laravel 6+ remains a fork-and-port task, unchanged.
Technical risk: The dominant risk is still abandonment, not correctness, and v2.0.0 does little to retire it. A single compatibility commit after roughly a decade of dormancy is a weak liveness signal — it reads as a one-off patch from a maintainer who is not actively stewarding the project, not as the start of a support cadence. There is no evidence in the release note of a CI matrix, a changelog policy, a deprecation path, or a maintainer handoff. Bus factor remains one; dependents remain effectively zero; there is no security-response process. Supply-chain exposure is unchanged: any use is an internal fork obligation on every future PHP upgrade. The secondary behavioral risks are untouched by this release — request-time hash generation as a per-request I/O and correctness liability, and divergent hashes across nodes when the stamp is computed locally rather than baked into the build artifact.
Key questions:
mix()?php and illuminate/* constraints ship in the v2.0.0 composer.json? Does it resolve on PHP 7.x/8.x?asset() helper, and what else in the codebase depends on that behavior?Stack fit: Poor-to-moderate on a current stack, moderate on a legacy one — up one notch from the prior assessment. On a greenfield or recently upgraded app the correct integration is still no integration: use mix() (5.4+) or @vite (9+), both of which content-hash filenames and rewrite URLs at build time. On a genuinely legacy Laravel 5.0–5.3 app that we are keeping alive but not upgrading, v2.0.0 makes adoption as-is defensible and cheaper than building equivalent plumbing — that is the one scenario this release improves. For Laravel 5.4–5.8, prefer Mix and treat the package as unnecessary.
Migration path: Unchanged, and still an intake-and-displace decision rather than a long-term adoption. Sequence: (1) inventory every usage of the package's helper or Blade directive; (2) verify what the native alternative produces for each call site; (3) replace call sites with asset(), mix(), or @vite; (4) remove the provider and the dependency; (5) delete the hash-generation config and any cron/build step that wrote it. Where no native equivalent exists — assets served from a CDN bucket outside the bundler — extract the hash-prefixing behavior into a small internal helper with a test so the logic survives independently of the abandoned dependency.
Compatibility: The constraint matrix question is now answerable rather than presumed, so answer it first: read the v2.0.0 composer.json for php and illuminate/support bounds and test resolution against the actual target app before planning anything. Expect to need a fork with widened illuminate/* and php constraints for Laravel 6+. Any fork must be registered as a VCS or path repository and pinned to a commit; do not rely on Packagist, since a single compatibility commit does not establish an active release stream. Verify facade registration, config publishing, and Blade directive compilation against the target framework version — those three APIs are precisely what changed across Laravel 5→11.
Sequencing: If we must ship this quarter, adopt-and-fork behind a feature flag with the fork owned by the team and pinned. In parallel, schedule replacement with the native build-tool mechanism as part of the next frontend build migration, not as a standalone project. Do not adopt the package in any service slated for a framework upgrade within twelve months — the upgrade forces displacement anyway, and doing both at once doubles the blast radius. The v2.0.0 release does not change this sequencing; it only makes the interim step viable on Laravel 5 without constraint surgery.
Maintenance: Still the decisive factor. One compatibility release after a decade of dormancy is not a maintenance cadence — there is no evidence of upstream triage, CVE response, deprecation policy, or community support behind it. Every future PHP or Laravel bump remains a manual compatibility review against code nobody owns. Budget the true cost as "internal fork maintenance forever," not "free OSS dependency." If v2.0.0 turns out to be the first of a regular series, revisit; one data point is not a trend.
Support: No vendor, no SLA, no responsiveness expectation. Internal engineers are the support tier, and knowledge will concentrate in whoever performs the fork — a single-point-of-failure pattern worth avoiding for a component that touches every rendered page. The v2.0.0 author's identity and availability are worth confirming before anyone depends on this.
Scaling: The logic scales fine; it is a string prefix. The scaling risk is deployment topology, untouched by this release. Hash-prefixed URLs must be identical across all web nodes, and old hashes must remain resolvable through rolling deploys and CDN TTL windows. If the hash is computed per request or per node, we get cache-busting that doesn't bust consistently, plus broken asset URLs for users mid-deploy. Any use must bake the hash into the build artifact and serve both old and new asset paths for at least one deploy cycle.
Failure modes:
asset(), cache busting quietly stops working, and users see stale assets with no error.asset() colliding with other packages or app code that expects native behavior.Ramp-up: Effectively zero for a Laravel developer — the concept and API are self-evident and the source is small enough to read end-to-end. The real cost is organizational: establishing fork ownership, pinning, and an upgrade-review ritual for a component the framework has since replaced. Recreating this behavior in-house or adopting the native build-tool mechanism remains under a day of engineering and removes the dependency entirely. v2.0.0 makes the package usable on a legacy Laravel 5 target and does not change the recommendation for anything modern: use the framework's own mechanism.
How can I help you explore Laravel packages today?