Incorrect Paths generated when using `paths.relative: true` in SPAs

[Giggiux]

Describe the bug

As suggested in #595, I attempted to use kit.paths.relative: true to enable my Single Page Application (SPA) to load from any path. However, upon building the application, I noticed that the output in the build folder contains only absolute paths.

This issue only occurs when ssr = false and there are no pre-rendered pages. If there is at least one pre-rendered page, the paths are indeed relative (./ on the scripts, and base: new URL(".", location).pathname.slice(0, -1)).

My use case is somewhat specialized: I am attempting to build a Twitch Extension, which technically operates as a static website. Hence, I need my app to be an SPA.
Twitch extensions encounter a similar issue to IPFS: one doesn't know the base path until the extension is opened on the site. The URL is composed like so: [extension-host-domain]/[twitch-extension-id]/[extension-version]/[upload-id], with the last upload-id being the unknown variable. This is my understanding based on the documentation and inspection.

From my interpretation of #595, the kit.paths.relative: true configuration should have resolved this issue, but it appears not to function as expected. I also tried using sveltekit-adapter-ipfs, but without success (I am dealing with a separate issue related to a missing paths- file).

I have created a simple repository where pnpm build generates these incorrect paths.

Perhaps I am making a mistake, but I cannot understand what it is.

Regards,
Luigi

Reproduction

https://github.com/Giggiux/reproduce-no-ssr-relative

Logs

No response

System Info

System:
    OS: macOS 13.4.1
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Memory: 15.44 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.16.0 - ~/.volta/tools/image/node/18.16.0/bin/node
    Yarn: 3.5.1 - ~/.volta/tools/image/yarn/3.5.1/bin/yarn
    npm: 9.6.6 - ~/.volta/tools/image/npm/9.6.6/bin/npm
  Browsers:
    Brave Browser: 114.1.52.126
    Chrome: 114.0.5735.133
    Safari: 16.5.1
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.1.0
    @sveltejs/adapter-static: ^2.0.2 => 2.0.2
    @sveltejs/kit: ^1.20.4 => 1.20.5
    svelte: ^4.0.0 => 4.0.0
    vite: ^4.3.6 => 4.3.9

Severity

serious, but I can work around it

Additional Information

No response

[npeeples]

I believe I'm running into this issue as well, but not 100% sure. It seems that on the generated SPA landing page, the initial imports are just wrong? I believe in the hydration below, that /_app w/ relative paths should be ./_app? I see this also running npm run dev and the imports from @fs don't have the ./@fs...

{
	__sveltekit_7kovfn = {
		base: "",
		env: {}
	};

	const element = document.currentScript.parentElement;

	Promise.all([
		import("/_app/immutable/entry/start.5b4385b2.js"),
		import("/_app/immutable/entry/app.75bcc3d0.js")
	]).then(([kit, app]) => {
		kit.start(app, element);
	});
}

[Giggiux]

If it can be useful, @npeeples, I've worked around it by creating a random page (literally, into src/random/+page.svelte) with export const prerender = true; into the +page.ts file.
And the fallback on a different page rather than the one I was gonna be serving.
By doing this, my index.html has relative paths, but my 200.html doesn't.

Using the same file for fallback doesn't work, and without the pre-rendered page doesn't work either.

[npeeples]

@Giggiux appreciate that, that does the trick for the spa build files.

Still need to track down if it's possible to accomplish a workaround on the npm run dev side of things, but I think this is more a vite issue than a svelte(kit) issue.

[msdrigg]

Also having this issue still. The workaround did work for me though.

[dummdidumm]

Adding this to the 2.0 milestone in the sense of "look into this" - if we're changing the default to be true, the blast radius of this could become much higher.

[benmccann]

It sounds like the issue here is that absolute paths are being generated when relative paths are expected, but that the app is still functioning. Assuming I got that correct, I probably wouldn't call this a 2.0 blocker and would say it could be fixed at any time.

[Rich-Harris]

This sounds like expected behaviour. We can't use relative paths when creating a fallback page (i.e. the page that is served when you visit a route that wasn't explicitly prerendered), because ../ has a different meaning on / as on /foo/bar/baz.

We can update the docs to make that clearer, but I'm not sure there's anything else we could be doing here.

[Giggiux]

Could we consider adding a new configuration parameter that functions as the "workaround" mentioned in this discussion? Perhaps even a brief section in the documentation would do the trick!
I'm aware that Twitch's extensions represent a very specialized segment, similar to IPFS apps, but who knows if this solution might be useful in other contexts where a SPAs with an undefined server route is required.

On a related note, I am a bit rusty with this issue as several months have elapsed since I first opened it. However, I recall being surprised/confused at the time that the behavior I expected for SPAs with paths.relative only manifested in scenarios involving a pre-rendered single page with a fallback to another page. The paths.relative aspect seemed particularly promising as a solution for this project, but ultimately it proved to be somewhat confusing. 😂

[Rich-Harris]

I'm not 100% sure I understand the workaround — are you saying that you used the random.html (which would contain relative paths) as the fallback?

If the extension always opens on the root route (i.e. it's not possible to deep-link to a page within the extension app) then yeah, just having an empty src/routes/+page.svelte and prerendering that (and using the resulting index.html instead of the fallback 200.html as the entry point) should suffice.

[Rich-Harris]

Based on my reading of https://dev.twitch.tv/docs/extensions/, it also sounds like all you need to do is prerender / (you can still prerender a page with ssr = false, if that's necessary for whatever reason)

[Rich-Harris]

I'm going to close this, as the docs PR has been merged and I don't think there's a great deal else we can do