Ask HN: Cache-busting for static sites (Jekyll/gh/Cloudflare) and WASM
I'm having trouble with one of my static sites, and my current predicament when a new release doesn't always work right due to older cached assets.
Initially, I started with just GitHub Pages serving the Jekyll site.
By default, my Jekyll theme has a form of cache-busting for the style.css file by appending the git sha as a query param:
``` <link rel="stylesheet" href="{{ '/assets/css/style.css?v=' | append: site.github.build_revision | relative_url }}"> ```
Later, I added CloudFlare on top of my GH pages setup for speed/SEO purposes. I decided to use a 1-day cache header for both the CloudFlare remote cache and the local browser cache.
In addition to the typical js, html, css files, I have a custom WASM module compiled with emcmake and emscripten, with artifacts `foo.js`, `foo.wasm`
Eventually I discovered that when I made a drastic code change in the WASM module, the old WASM module was being served through the CloudFlare cache, creating problems for end users.
I can add query-parameter cache busting to the `foo.js` file: `importScripts("foo.js?v=blahblah")`. However, that's not so easy to do with the `foo.wasm` file, whose name is automatically embedded into the `foo.js` file generated by emscripten. For this, I ended up changing the module name (foo_v1, foo_v2, etc.) in CMakeLists.txt. However, this is overkill since the `foo.js` file is not cached/easy to update, but `foo.wasm` is the actual important one to cache due to its size.
Now I'm considering adding a ServiceWorker pattern to the code, which has its own cache name.
At this point, I'm mired in total confusion and have this mix of cache-busting paradigms and whatnot: 1. Sometimes query params 2. Sometimes file names 3. Service worker interacting with browser cache header and Cloudflare cache
What's a simple and clean approach to deal with "cache-busting" on new/breaking releases?