Describe the bug
After upgrading from SvelteKit 2.64.0 to 2.65.0, the built client entry file (_app/immutable/entry/app.[hash].js) emits CSS and JS dependency paths in __vite__mapDeps as ./-prefixed relative paths:
"./_app/immutable/assets/Prose.BmvqhkXc.css"
When a browser loads that entry file from /_app/immutable/entry/, it resolves ./ relative to the file's directory, producing a doubled URL:
/_app/immutable/entry/_app/immutable/assets/Prose.BmvqhkXc.css
This causes 404s for every lazily-loaded CSS and JS chunk. The site fails to render after the initial HTML load.
Config in svelte.config.js:
paths: {
relative: false,
}What changed between 2.64.0 and 2.65.0:
In 2.64.0, SvelteKit set Vite's base config to the absolute base path (/ when paths.relative: false). Rolldown respects this and generates __vite__mapDeps entries without a ./ prefix, which the Vite runtime then prepends / to at runtime (via t = function(e) { return '/' + e }), producing correct absolute paths.
In 2.65.0, the code was changed to always use base: './' and instead rely on experimental.renderBuiltUrl returning { relative: false } to produce absolute paths per-asset. Rolldown does not appear to honor renderBuiltUrl for the __vite__mapDeps dependency array, so the paths remain relative to the ./ base — producing the doubled-URL bug.
Workaround: Pin @sveltejs/kit to 2.64.0.
Reproduction
https://github.com/leereamsnyder/sveltekit-2-dot-65-relative-paths-repro
Build with npm run build, then inspect _app/immutable/entry/app.[hash].js — search for ./_app/immutable/assets/ in the __vite__mapDeps array. Serve the build with npm run preview and open DevTools Network to observe 404s at the doubled paths.
Logs
GET /_app/immutable/entry/_app/immutable/assets/Prose.BmvqhkXc.css 404
GET /_app/immutable/entry/_app/immutable/chunks/CeONHeB4.js 404
A ServiceWorker intercepted the request and encountered an unexpected error.
System Info
System:
OS: macOS 26.5.1
CPU: (10) arm64 Apple M5
Memory: 135.14 MB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 22.22.3 - /opt/homebrew/bin/node
Yarn: 1.22.22 - /opt/homebrew/bin/yarn
npm: 10.9.8 - /opt/homebrew/bin/npm
Browsers:
Chrome: 149.0.7827.104
Safari: 26.5
npmPackages:
@sveltejs/adapter-cloudflare: 7.2.8
@sveltejs/kit: 2.65.0 ← bug present; 2.64.0 = working
@sveltejs/vite-plugin-svelte: 7.1.2
svelte: 5.56.3
vite: 8.0.16Severity
blocking an upgrade
Additional Information
The specific change in SvelteKit between 2.64.0 and 2.65.0 is in src/exports/vite/index.js:
- 2.64.0:
const client_base = kit.paths.relative !== false || kit.paths.assets ? './' : kit_paths_base; — passes this as Vite's base, so Rolldown generates root-relative dep paths and the preload runtime prepends / correctly.
- 2.65.0:
base: './' is hardcoded; experimental.renderBuiltUrl returning { relative: false } is used instead — Rolldown does not respect this for the __vite__mapDeps array, leaving ./-relative paths in the output.
This may be a Rolldown limitation with experimental.renderBuiltUrl, but since 2.64.0 worked around it via the base config and 2.65.0 removed that workaround, the regression is observable at the SvelteKit level.
Describe the bug
After upgrading from SvelteKit 2.64.0 to 2.65.0, the built client entry file (
_app/immutable/entry/app.[hash].js) emits CSS and JS dependency paths in__vite__mapDepsas./-prefixed relative paths:When a browser loads that entry file from
/_app/immutable/entry/, it resolves./relative to the file's directory, producing a doubled URL:This causes 404s for every lazily-loaded CSS and JS chunk. The site fails to render after the initial HTML load.
Config in
svelte.config.js:What changed between 2.64.0 and 2.65.0:
In 2.64.0, SvelteKit set Vite's
baseconfig to the absolute base path (/whenpaths.relative: false). Rolldown respects this and generates__vite__mapDepsentries without a./prefix, which the Vite runtime then prepends/to at runtime (viat = function(e) { return '/' + e }), producing correct absolute paths.In 2.65.0, the code was changed to always use
base: './'and instead rely onexperimental.renderBuiltUrlreturning{ relative: false }to produce absolute paths per-asset. Rolldown does not appear to honorrenderBuiltUrlfor the__vite__mapDepsdependency array, so the paths remain relative to the./base — producing the doubled-URL bug.Workaround: Pin
@sveltejs/kitto2.64.0.Reproduction
https://github.com/leereamsnyder/sveltekit-2-dot-65-relative-paths-repro
Build with
npm run build, then inspect_app/immutable/entry/app.[hash].js— search for./_app/immutable/assets/in the__vite__mapDepsarray. Serve the build withnpm run previewand open DevTools Network to observe 404s at the doubled paths.Logs
System Info
System: OS: macOS 26.5.1 CPU: (10) arm64 Apple M5 Memory: 135.14 MB / 32.00 GB Shell: 5.9 - /bin/zsh Binaries: Node: 22.22.3 - /opt/homebrew/bin/node Yarn: 1.22.22 - /opt/homebrew/bin/yarn npm: 10.9.8 - /opt/homebrew/bin/npm Browsers: Chrome: 149.0.7827.104 Safari: 26.5 npmPackages: @sveltejs/adapter-cloudflare: 7.2.8 @sveltejs/kit: 2.65.0 ← bug present; 2.64.0 = working @sveltejs/vite-plugin-svelte: 7.1.2 svelte: 5.56.3 vite: 8.0.16Severity
blocking an upgrade
Additional Information
The specific change in SvelteKit between 2.64.0 and 2.65.0 is in
src/exports/vite/index.js:const client_base = kit.paths.relative !== false || kit.paths.assets ? './' : kit_paths_base;— passes this as Vite'sbase, so Rolldown generates root-relative dep paths and the preload runtime prepends/correctly.base: './'is hardcoded;experimental.renderBuiltUrlreturning{ relative: false }is used instead — Rolldown does not respect this for the__vite__mapDepsarray, leaving./-relative paths in the output.This may be a Rolldown limitation with
experimental.renderBuiltUrl, but since 2.64.0 worked around it via thebaseconfig and 2.65.0 removed that workaround, the regression is observable at the SvelteKit level.