-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Description
What version of Bun is running?
1.2.22+6bafe2602
What platform is your computer?
Linux 6.16.8-2-cachyos x86_64 unknown
What steps can reproduce the bug?
When bundling as a single file app/SFA, Bun.build does not seem to change the hash or etag header of the HTML entrypoint even though its dependencies did in fact change. This causes the browser to load the cached HTML file containing the old asset names, leading to 404s until you hard refresh.
I'm guessing that the HTML entrypoint hash gets generated before the asset URLs get injected into it, so asset filename/hash changes do not cause the HTML entrypoint hash to change.
First spotted at NDC-Tourney/stream-overlay#40 and #22807 was created to fix it but later closed.
Minimal repro:
build.ts
await Bun.build({
entrypoints: ["./server.ts"],
compile: {
outfile: "dist/app",
},
});
server.ts
import { serve } from "bun";
import index from "./index.html";
const server = serve({
routes: {
"/": index,
},
});
console.log(`Server started at ${server.url}`);
index.html
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
</head>
<body>
<script type="module" src="./index.js"></script>
</body>
</html>
index.js
console.log("1");
bun run build.ts
./dist/app
- Open http://localhost:3000
- Open devtools network tab, observe everything loading fine
- Stop
./dist/app
process - Modify index.js (e.g. incrementing
1
to2
) bun run build.ts
./dist/app
- Open http://localhost:3000
- Open devtools network tab, see that the HTML is loaded from cache and observe 404 error when the browser tries to load the JS file using its previous name
You can also reproduce this without compiling as SFA using naming: "[name]-[hash].[ext]"
, but generally people wouldn't add a hash to the HTML entrypoint filename i imagine so i figured i'd show the most common situation here (and how i ran into it as well).
What is the expected behavior?
The HTML entrypoint hash/etag header should update when the assets it depends on are updated, so that the browser fetches the new HTML with the new asset filenames, and doesn't try to load the old ones.
What do you see instead?
The browser loads the cached HTML which contains the old asset filenames, leading to 404s.
Additional information
No response