Every deploy of your app creates a new named cache with the browser's Cache API, and users' storage grows without bound. How should named caches be versioned and cleaned up, and what order must the operations happen in?

## CacheStorage is a permanent, flat namespace `caches` maps arbitrary strings to `Cache` objects. Three facts follow, and together they explain the unbounded growth: 1. `caches.open('static-v4')` creates the cache if it does not exist and returns it if it does. It never inspects, migrates or removes any other name. 2. There is no expiry, no LRU and no generational cleanup. A cache named `static-v1` created two years ago still exists, still holds every entry it was given, and still counts against the origin's storage. 3. The namespace is shared by everything running on the origin — your own code, an analytics SDK, a framework's build tooling. Names collide silently. So an app that bumps a version string each deploy accumulates one full copy of its assets per release until the browser evicts the entire origin under storage pressure — which is a blunt, user-visible event, not a cleanup strategy. ## The standard shape Derive every name from one constant, and treat "names I recognise" as the definition of what to keep: ```js const VERSION = 'v4'; const CURRENT = new Set([`static-${VERSION}`, `pages-${VERSION}`]); async function cleanUp() { const names = await caches.keys(); await Promise.all( names .filter((n) => n.startsWith('static-') || n.startsWith('pages-')) .filter((n) => !CURRENT.has(n)) .map((n) => caches.delete(n)) ); } ``` The prefix filter is not decoration. `caches.keys()` returns every cache on the origin, so a naive "delete anything not in CURRENT" wipes caches owned by other code on the same origin. Own a namespace and stay inside it. ## Ordering: populate, then delete The sequence must be **create and fully populate the new generation, then delete the old ones**. Reversing it opens a window where the old entries are gone and the new ones are not yet written; a user who loads the app in that window — or goes offline in it — finds nothing cached at all. Because `cache.addAll()` is all-or-nothing, it is a natural gate: if it rejects, you have not deleted anything, and the previous generation is still intact and serving. There is a second ordering hazard on the other side. Deleting a cache while something is still reading from it does not throw, but subsequent `match()` calls against that name resolve with `undefined`. If a page loaded against `static-v3` is still running when `static-v3` disappears, its lookups start missing and fall through to the network. That is survivable when online and not when offline, which is why cleanup is conventionally done at a point where the new generation has already taken over rather than immediately on script evaluation. ## What the return values tell you - `caches.keys()` resolves with the names in creation order — the cheapest audit of what is actually on a user's disk. - `caches.delete(name)` resolves with `true` if a cache with that name existed and was removed, `false` otherwise. Logging a `false` where you expected `true` catches a version-string typo that would otherwise leak a whole generation. - `caches.has(name)` exists but is rarely the right call; `keys()` gives you the full picture in one round trip and avoids a check-then-act race. ## Entry-level versus cache-level invalidation Two granularities are available and they suit different content. **Cache-level** (bump the name, delete the old one) is right for immutable build output. Every asset of one release lives or dies together, so you never serve a new HTML shell against an old JavaScript bundle — the classic skew bug. **Entry-level** (`cache.delete(request)`) is right for long-lived data caches that must survive deploys. Bumping the name here would discard, on every release, content the user may need offline. `cache.keys()` plus your own metadata — a timestamp stored alongside, or a parallel IndexedDB record — is how you implement age-based pruning, because the API itself records no insertion time. ## A note on naming Make the name carry the schema, not just the release: `static-v4` is fine when the layout of the entries never changes, but if you change *how* you key entries — adding a synthetic query, switching from full URLs to hashed names — the old generation is not merely stale, it is unreadable by the new code. Bumping a separate schema segment (`static-s2-v4`) makes that explicit and makes the cleanup filter obvious.