# Cachebusting-naming the JS files

**URL:** https://community.silverbullet.md/t/cachebusting-naming-the-js-files/2098
**Category:** General
**Created:** [April 1, 2025, 8:17pm UTC](https://community.silverbullet.md/t/cachebusting-naming-the-js-files/2098 "2025-04-01T20:17:29Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![lutzky](https://community.silverbullet.md/user_avatar/community.silverbullet.md/lutzky/32/624_2.png) [@lutzky](https://community.silverbullet.md/u/lutzky)
#### Post date: [April 1, 2025, 8:17pm UTC](https://community.silverbullet.md/t/cachebusting-naming-the-js-files/2098/1 "2025-04-01T20:17:29Z")

</div>

As discussed e.g. in [this thread](https://community.silverbullet.md/t/could-not-fetch-configuration-from-server-because-of-401-on-config/2073/8), 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](https://github.com/silverbulletmd/silverbullet/blob/9f1b38ef2a3a620fd563da0b007fb12ac106e386/build_web.ts#L119-L121) 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?

---

<div class="post-metadata">

### Author: ![laurybueno](https://community.silverbullet.md/user_avatar/community.silverbullet.md/laurybueno/32/1601_2.png) [@laurybueno](https://community.silverbullet.md/u/laurybueno)
#### Post date: [October 21, 2025, 11:43pm UTC](https://community.silverbullet.md/t/cachebusting-naming-the-js-files/2098/2 "2025-10-21T23:43:14Z")

</div>

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 &nbsp;|&nbsp; Articles &nbsp;|&nbsp; web.dev](https://web.dev/articles/service-worker-lifecycle#avoid-url-change)

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.

---

<div class="post-metadata">

### Author: ![MrMugame](https://community.silverbullet.md/user_avatar/community.silverbullet.md/mrmugame/32/358_2.png) [@MrMugame](https://community.silverbullet.md/u/MrMugame)
#### Post date: [October 22, 2025, 8:24am UTC](https://community.silverbullet.md/t/cachebusting-naming-the-js-files/2098/3 "2025-10-22T08:24:28Z")

</div>

AHAHAHA someone touched the build code. Call the brigade.

But seriously, two things.

- There is cache busting using query parameters. Try searching the code. What motivated you to look into this?
- The build process is very … a … questionable overall

---

<div class="post-metadata">

### Author: ![lutzky](https://community.silverbullet.md/user_avatar/community.silverbullet.md/lutzky/32/624_2.png) [@lutzky](https://community.silverbullet.md/u/lutzky)
#### Post date: [October 24, 2025, 1:51pm UTC](https://community.silverbullet.md/t/cachebusting-naming-the-js-files/2098/4 "2025-10-24T13:51:00Z")

</div>

Alright, fine, I’ll dig. 😁

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](https://github.com/silverbulletmd/silverbullet/blob/1838cc4eb158385fc4d05c4300238664cf5d27b9/client/html/index.html#L54), though that’s not currently in the struct fed into it [here](https://github.com/silverbulletmd/silverbullet/blob/1838cc4eb158385fc4d05c4300238664cf5d27b9/server/ssr.go#L65). It’s entirely possible I’m missing a simpler solution too.