Reference pages

Alongside the modern app (index.html), the build produces two legacy reference pages. They are debugging aids: a way to compare the modern renderer against a known-good baseline: not part of the product.

The three entry points

vite.config.ts declares three HTML inputs:

Entry	File	What it is
main	index.html	The modern EXEPERT app (TS + WASM).
vanilla	vanilla.html	A pristine legacy three.js r70 reference, served from public/vanilla/.
v1	v1.html	The legacy renderer wrapped in the modern UI shell, served from public/v1/ with <base href="/v1/">.

The vanilla page is the original visualization running on the old three.js version, untouched. The v1 page puts that same legacy renderer inside the current UI chrome. Together they let you isolate whether a visual difference comes from the renderer or from the surrounding app.

The standalone logger build

Both reference pages are plain HTML and cannot import the TypeScript diagnostics logger as an ES module. So scripts/build-vanilla-logger.mjs bundles src/diag/logger.ts into a self-contained IIFE they can load with a normal <script src> tag.

scripts/build-vanilla-logger.mjs (esbuild options)

format: 'iife'
target: 'es2017'
// inline sourcemap

It writes the bundle to public/vanilla/diag-logger.js and mirrors it to public/v1/diag-logger.js. Both outputs are gitignored and rebuilt by the dev and build scripts, so the reference pages always get the current logger.

This is why pnpm dev and pnpm build run build:vanilla-logger before starting Vite: see Development and Build & preview.

When to use them

• A rendering regression in the modern app: compare against vanilla.html.
• A UI vs. renderer question: compare vanilla.html (renderer only) against v1.html (renderer in the shell).

If you are only working on the simulation or the modern UI, you can ignore these pages entirely; they do not affect the main app build output beyond producing their own bundles.