SPA fallback pages with paths.relative: true should use truly relative paths for enhanced portability

[ouksal]

Describe the problem

The SvelteKit documentation for kit.paths.relative states: "Single-page app fallback pages will always use absolute paths, regardless of this setting." This presents a challenge for deploying SPAs to non-root directories (subfolders) in a truly portable "drop-in" manner.

My goal, and I believe a common one, is to be able to build an SPA once and then deploy that static output to any subfolder on a web server (e.g., /project-a/, /some/other/path/) without needing to:

1. Reconfigure kit.paths.base and rebuild for each different deployment path.
2. Implement complex server-side rewrite rules to handle absolute paths when served from a subfolder.

The current behavior, where SPA fallbacks use absolute paths (even if they respect a configured base path), means the build isn't inherently portable to any path without these "hoops." As the user, "I want to be able to drop my SPA into a folder and have things work without jumping through a lot of hoops" because "not everybody gets to host from the root."

Describe the proposed solution

When kit.paths.relative = true is configured for an SPA (e.g., using adapter-static with a fallback like index.html or 200.html), I propose that the SPA fallback page itself should use truly relative paths for all its asset links (JavaScript, CSS, images, etc.).

For example, instead of generating asset links like:

• /_app/immutable/start-...js (root-relative)
• Or even /my-base/_app/immutable/start-...js (base-relative, requiring base to be known and static)

The links within the index.html (or other SPA fallback) should be relative to its current location, such as:

• ./_app/immutable/start-...js
• ./assets/my-image.png

This would align with the stated benefit of relative: true: "resulting in more portable HTML." If the main HTML entry point for an SPA (the fallback page) doesn't use relative paths for its critical assets, its portability is significantly limited.

Alternatives considered

Describe alternatives you've considered

• Using kit.paths.base: This works, but it requires knowing the deployment subpath at build time. If the path changes, a rebuild is necessary. This isn't ideal for generic builds or for users who may not control the build process but need to deploy the output to various subfolders.
• Server-side rewrites: This adds complexity and isn't always possible, especially on simple static hosting platforms or CDNs.

Importance

i cannot use SvelteKit without it

Additional Information

This is quite important for developers who need to deploy SPAs in environments where they don't control the root of the domain or where deployment paths might vary without the opportunity to rebuild the application. It simplifies deployment significantly for common use cases like:

• Hosting on shared servers in a user-specific subfolder.
• Deploying to static site hosting services (like GitHub Pages in a subpath) where base path configuration can be fiddly or lead to extra setup.
• Distributing an SPA for others to host easily in their own varied environments.

[dummdidumm]

This wouldn't work when you app is served from /foo and you visit /foo/bar - the assets would be requested from a path that doesn't exist.
We could only reliably do that if you're using hash routing.

[ouksal]

Feels like fighting the framework just to support non root deployments.

[dummdidumm]

This isn't about deploying, it's about when a user visits your site. Then the asset paths are all wrong and the user would only see a white page because everything's broken.

[ouksal]

Thanks for your time, @dummdidumm.
I now understand the limitations and issues with relative paths.