Skip to content

Pin Vite entry filename to assets/app.js so the deploy wrapper template can hardcode a stable URL#75

Open
nx-thaddeusaid wants to merge 1 commit into
BattletechModders:mainfrom
nx-thaddeusaid:warmap-pin-entry-filename
Open

Pin Vite entry filename to assets/app.js so the deploy wrapper template can hardcode a stable URL#75
nx-thaddeusaid wants to merge 1 commit into
BattletechModders:mainfrom
nx-thaddeusaid:warmap-pin-entry-filename

Conversation

@nx-thaddeusaid
Copy link
Copy Markdown
Contributor

Summary

Pins the Vite entry script to dist/assets/app.js (no content hash) so the roguewar.org server template that produces the /warmap page can hardcode a single stable URL.

This is the WarMap-side change needed to unblock the wrapper template; see the companion writeup that Thaddeus is forwarding to the deploy owner (Nyx) for the full diagnosis and the matching one-line template edit.

Why

https://www.roguewar.org/warmap currently renders as a black page. The build is correct — every asset is on the server and returns 200 — but the wrapper template only loads /warmap/assets/vendor-ui-<hash>.js (the react-select + lucide-react chunk per vite.config.ts manualChunks) instead of the actual entry. Without the entry, React never mounts into #react-root.

A local docker reproduction using the deploy Dockerfile (node:22-alpine + yarn run build --base=/warmap) confirmed the build artifacts work when served directly via nginx. The bug is purely in the wrapper template's asset-picking logic.

The cleanest WarMap-side mitigation is to give the wrapper template a single stable URL it can hardcode and never need to extract again.

What changes

// vite.config.ts — under build.rollupOptions.output
entryFileNames: 'assets/app.js',

After this lands, the build emits:

File Before After
Entry assets/index-<hash>.js assets/app.js (stable)
CSS assets/index-<hash>.css assets/index-<hash>.css (unchanged)
rolldown-runtime, vendor-{core,ui,konva} hashed hashed (unchanged)

Vendor chunks and CSS keep their content-hash for cache-busting. They are loaded by the entry via dynamic imports / Vite's modulepreload links, not by the wrapper template, so their hashed names are not a problem.

Caching note for the deploy server

app.js no longer cache-busts via filename. The deploy should send a short or no-cache header on that one URL so changes take effect immediately, while keeping aggressive caching on the hashed assets:

location = /warmap/assets/app.js {
  add_header Cache-Control "no-cache";
}
location /warmap/assets/ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

This is a server-side config tweak, separate from this PR.

Test plan

  • yarn install, yarn lint, npx tsc -p tsconfig.app.json --noEmit, npx tsc -p tsconfig.vitest.json --noEmit, yarn test (155 tests), yarn test:coverage — all green
  • VITE_BASE_URL=/warmap yarn build produces dist/assets/app.js and dist/index.html references /warmap/assets/app.js as the entry
  • node:22-alpine reproduction of the deploy pipeline (yarn run build --base=/warmap) confirms the same — dist/assets/app.js is in the output, dist/index.html references it
  • After merge + deploy: wrapper template updated to hardcode /warmap/assets/app.jshttps://www.roguewar.org/warmap renders the galaxy map

…plate reference

The roguewar.org server template that produces /warmap currently hardcodes
or auto-extracts one script tag from dist/index.html and gets the wrong
file: it loads /warmap/assets/vendor-ui-<hash>.js (the react-select +
lucide-react chunk) instead of the actual entry. Without the entry, React
never mounts and the page renders only the dark body background.

Pinning the entry to assets/app.js gives the wrapper template a single
stable URL that does not change across builds. Vendor chunks and CSS keep
their content-hashed names — they are loaded by the entry via dynamic
imports and the modulepreload links Vite emits, not by the wrapper.

The deploy server should cache app.js with a short max-age (or no-cache)
since its URL no longer cache-busts; everything it imports is still
content-hashed and can be cached aggressively.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant