Root-absolute asset URLs, so the 404 page keeps its styles at any depth

[xuelink]

Every prerendered page linked its build artifacts relative to itself, e.g. ./_app/immutable/assets/0.1TuYpimw.css, because SvelteKit 2 defaults kit.paths.relative to true. Cloudflare Pages answers a missing URL at any depth with 404.html. On https://langx.io/some/deep/missing-page that ./_app/… resolves to /some/deep/_app/…, which is itself a 404 served as text/html. So the not-found page rendered unstyled, its modules never loaded and the client never started. Its favicons and manifest (%sveltekit.assets% in app.html) failed the same way. Pages at their own URLs were fine, because there the relative path lands at the root.

kit.paths.relative: false writes those references root-absolute (/_app/…, /favicons/…). The site is only ever served from the domain root, pages.dev branch previews included, so the relative form was not needed. The top-level config.paths = { base: … } further down is left alone. SvelteKit never reads it (paths belongs under kit), and moving it under kit would apply CI's BASE_PATH=/website to every URL.

Checked, on Kit 2.70.3 under Node 20 (as in CI):

• npm run check: 0 errors; the 2 warnings are the existing line-clamp ones. vite build: 1371 HTML files, the same as before.
• build/404.html and build/tools/say/hello.html link every stylesheet and module under /_app/. No page in the build has a relative href, src or import() left.
• I built before and after and compared all 1371 pages. With scripts, stylesheet links and hashes stripped, the only differences left are hrefs that became root-absolute: modulepreloads to /_app/ and favicon/manifest links to /favicons/. Each still names the same path. A stricter check: resolve every relative URL in the old build against the page's own URL, including the bootstrap's base and its import()s. That gives the new HTML byte for byte, scripts included, and the 237 artifacts referenced map one-to-one. Outside _app/ every file is identical. Inside it, the font url()s in the CSS and Vite's preload lists became absolute too, with the same targets. Two chunks keep their names even though their preload lists changed, because Vite fills those lists in after hashing. The preload helper did not change and resolves both forms to the same URLs, so a cached copy of either is harmless.
• vite preview: /, /tools/say/hello and /some/deep/missing-page load every stylesheet with no failed requests, and the client starts. However, vite preview renders unknown URLs on the server instead of serving 404.html, so it cannot show this bug. A small static server that answers the way Pages does (the file, else .html, else 404.html with status 404) can. On the old build, /some/deep/missing-page applied 0 of 6 stylesheets and all 25 _app requests failed. On the new build, all 6 applied, none failed, and "Back to the start" navigates client-side.

🤖 Generated with Claude Code