Re: [ServiceWorker] Pattern for handling fingerprinted assets in cache? (#657)

If there's asset fingerprinting then there's almost certainly a build process for the site. If that's the case, then modifying the server worker script during the build process is an option, and that modification can include injecting an array of the up to date fingerprinted URLs into the script file.

This also plays nicely with the service worker lifecycle, in that the modified script will kick off a new `install` → `update` flow, letting you handle additional caching and expiration inside the standard events.

You do have to think a bit about timing in order to ensure that the cache is properly populated with the latest fingerprinted assets by the time the URLs in the controlled page are updated to refer to those assets.

That being said, I'd love to see some additional metadata, be it `tag` or something else, added to the Cache Storage API. My specific use case, in the [`sw-precache`](https://github.com/GoogleChrome/sw-precache) library, is related to the issue described here: resources that don't necessarily have fingerprints in their filenames, but get fingerprinted at build time, and that metadata about each file needs to be stored somewhere. The workaround I'm using is to  create individual `Cache` objects, each with one entry and with a name that includes the fingerprint, and it's kind of ugly.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/657#issuecomment-151866195