As discussed e.g. in this thread, aggressive caching by reverse-proxies can sometimes lead to hard-to-debug issues.
Apparently, there’s a fairly widespread practice of adding a content-hash to Javascript filenames, known as “cache busting”. Apparently Deno Fresh does this, and esbuild can also be configured to do this.
I tried doing this for silverbullet (v2), by adding entryNames: "[name].[hash]" everywhere esbuild.build is called. However, this section tries to modify a file with a now-invalid filename, and there are probably other places like this. This section is already seemingly discussing something called CACHE_NAME, but the commit that introduces it is too large to easily reason about what exactly that’s doing.
Does this seem like a useful, and feasible, thing to add?
This is pretty common on frontend projects, but it gets a bit more complicated when involving Service Workers, so I’m not sure how effective it can be in SB’s case. See this article for the details: The service worker lifecycle | Articles | web.dev
Personally, when I upgrade my SB container, I also go through the trouble of manually busting client-side caching in my browser to avoid weird errors.
This is somewhat out-of-date for me as I’ve switched to using tailscale for silverbullet, but it’s still relevant for people using Cloudflare or other caching reverse-proxies. Cloudflare’s default behavior is to cache .js files unless they have a query string.
With a correctly-installed client, upon loading the page, there’s a GET / (but that’s for HTML, so not cached by default, OK), followed by a GET /.client/client.js - without any query parameters. So that’s not doing the cache-busting. However, the request is sent with client header Cache-Control: no-cache, which is respected. I’m not entirely sure why that happens - this header is only specified in the fileMetaToHeaders function, which isn’t used to fetch client.js (that is just directly from the <script> tag returned by GET /).
However, on a fresh install - or on an incognito tab - that first request is sent without a Cache-Control request header. So if someone is very confused about why their prod version isn’t working correctly after an update, and is testing using incognito (or another browser, or deleting the service worker), and they’re using a caching reverse-proxy - they’ll just be served the old version. That is why we need cachebusting.
That being said, using query parameters instead of renaming the file is probably the right way to go here. Lots has changed now since the backend is now in Go. Presumably a hash needs to be added here, though that’s not currently in the struct fed into it here. It’s entirely possible I’m missing a simpler solution too.
