fuzzyworld

tower / commit

fix(build): reference assets relatively so Pages works at either URL

4a8aed841781f2c0b1ac95af98b345e0f73be845 · Pavel Safronov · 2026-09-06 20:15:45 -0700 · parents 09a64747b965

fix(build): reference assets relatively so Pages works at either URL

GitLab serves project pages either at <user>.gitlab.io/<project>/ or, when
unique domains are enabled, at the root of a generated domain. The base path
was derived from CI_PROJECT_NAME, which is correct for the first and 404s
every asset on the second — and which of the two applies is not knowable
until the first deploy.

Relative paths are correct for both. BASE still overrides, and the check is
explicit rather than ?? so that BASE="" cannot silently mean "relative".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 README.md      |  8 ++++----
 vite.config.ts | 18 +++++++++++++-----
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/README.md b/README.md
index 9f1ba5b..8cb6ca1 100644
--- a/README.md
+++ b/README.md
@@ -43,10 +43,10 @@ npm run terrain   # regenerate the maps from content/geography.json
 Vite + TypeScript, deployed to GitLab Pages by `.gitlab-ci.yml` on every push to the
 default branch. Three.js arrives with the 3D views.
 
-`vite.config.ts` takes its base path from `CI_PROJECT_NAME`, which gives `/tower/`
-— correct for `https://pavelsafronov.gitlab.io/tower/`. If GitLab assigns this
-project a *unique* Pages domain instead (served at the root), set a `BASE=/` CI
-variable and the build will follow.
+Assets are referenced **relatively**, so the same build works whether Pages serves
+it from `https://pavelsafronov.gitlab.io/tower/` or from a generated unique domain
+at a root. Set a `BASE` CI variable to force an absolute base if that is ever
+needed.
 
 ## Geography
 
diff --git a/vite.config.ts b/vite.config.ts
index 5c951f9..53fdc40 100644
--- a/vite.config.ts
+++ b/vite.config.ts
@@ -1,9 +1,17 @@
 import { defineConfig } from 'vite'
 
-// GitLab project pages live at https://<user>.gitlab.io/<project>/, so the build
-// needs that subpath as its base. CI_PROJECT_NAME is set by GitLab CI; locally it
-// is absent and the base is root. For a user/group pages repo (served at the
-// domain root) set BASE=/ in the CI variables.
-const base = process.env.BASE ?? (process.env.CI_PROJECT_NAME ? `/${process.env.CI_PROJECT_NAME}/` : '/')
+/**
+ * Relative asset paths by default, so the same build works wherever Pages puts it.
+ *
+ * GitLab serves project pages either at https://<user>.gitlab.io/<project>/ or, if
+ * unique domains are on, at the root of a generated domain. A hard-coded `/tower/`
+ * base 404s every asset in the second case, and there is no way to know which one
+ * applies until the first deploy. Relative paths are correct for both.
+ *
+ * Set BASE to override — an absolute base is needed if this ever gains client-side
+ * routing, since relative URLs resolve against the current path rather than the app
+ * root. `??` would not catch BASE="", so the check is explicit.
+ */
+const base = process.env.BASE || './'
 
 export default defineConfig({ base, build: { target: 'es2022' } })