Dev server does not apply base path correctly

[andycarlberg]

Describe the bug

I'm using a code-server cloud environment to develop a SvelteKit project. In order to access the dev server, a proxy is provided that uses a subpath to proxy the dev server port (see docs. This leads me to need a base path to be set for the dev server.

If I set kit.paths.base as stated in the documentation, the first page load works correctly but the import statements are relative to the root which returns a 404, correctly, because those files are not available without the proxy. If I run build and preview everything works as expected since the base path is built into the compiled project.

Expected behavior
All paths in the dev server reference the base path instead of being relative to the root domain.

Reproduction

1. Create a new SvelteKit project
2. Set kit.paths.base to a non-root path
3. Run the dev server

Expected result
All import statements look for paths with the base path or relative to the base path

Actual result
Module import statements are relative to the root

Example

Logs

GEThttp://domain.tld/.svelte-kit/dev/runtime/internal/start.js
[HTTP/1.1 404 Not Found 8ms]

Loading module from “http://domain.tld/.svelte-kit/dev/runtime/internal/start.js” was blocked because of a disallowed MIME type (“application/json”). 3000
Loading failed for the module with source “http://domain.tld/.svelte-kit/dev/runtime/internal/start.js”. 3000:13:1
GEThttp://domain.tld/favicon.png
[HTTP/1.1 404 Not Found 6ms]

System Info

System:
    OS: Linux 5.10 Ubuntu 20.04.3 LTS (Focal Fossa)
    CPU: (12) x64 Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz
    Memory: 283.55 MB / 15.32 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 14.18.2 - /usr/bin/node
    Yarn: 1.22.15 - /usr/bin/yarn
    npm: 6.14.15 - /usr/bin/npm
  npmPackages:
    @sveltejs/kit: ^1.0.0-next.201 => 1.0.0-next.201 
    svelte: ^3.42.6 => 3.44.2

Severity

annoyance

Additional Information

I've been using the absproxy method with code-server. This passes the full path with the /absproxy/3000 portion intact. This seems like the correct approach for usage with kit.paths.base. I think this method would work fine if the dev server accounted for it when building the pages.

However, there is also the proxy method. The proxy method strips of the proxy subpath before passing the request to the dev server. Thus, on the dev server, all the paths are relative to root. If there was a way to specify a subpath only for use on the client side, this may also be a reasonable solution.

I've made some inline edits to the @sveltejs/kit package in node_modules and was able to get the proxy method working. It would require a config field to set it, of course. Obviously, not everyone is working in a cloud server 😄

[andycarlberg]

Decided to see if I could fix this myself. After digging in it looks like this might actually be a Vite issue, not a SvelteKit issue.

It's possible that SvelteKit may need additional updates beyond the fix for Vite as well.

[Bastian]

I'm having the same issue. My dev server is running behind a Traefik Reverse Proxy and thus it fails to resolve the .svelte-kit/* files which are ignoring the kit.paths.base setting:

This is the config with the kit.paths.base set to /demo:

import adapter from '@sveltejs/adapter-node';
import preprocess from 'svelte-preprocess';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	// Consult https://github.com/sveltejs/svelte-preprocess
	// for more information about preprocessors
	preprocess: [
		preprocess({
			postcss: true
		})
	],

	kit: {
		adapter: adapter(),

		// hydrate the <div id="svelte"> element in src/app.html
		target: '#svelte',
		ssr: true,
		trailingSlash: 'ignore',
		paths: {
			base: '/demo'
		}
	}
};

export default config;

[andycarlberg]

@Bastian is correct, this is not actually a Vite issue as I first suspected. It does seem to be specific to SvelteKit. So I'll keep looking but I'm probably out of my depth here for a quick fix.

I started looking at it as a Vite problem because I always seemed to come back to Vite when trying to trace the issue through SvelteKit. I must have missed something though since a vanilla Vite project applies the base path as expected.

[rassie]

@andycarlberg

I've made some inline edits to the @sveltejs/kit package in node_modules and was able to get the proxy method working. It would require a config field to set it, of course. Obviously, not everyone is working in a cloud server smile

Could you share a gist of what you've changed?

[andycarlberg]

@rassie
I've pushed up some of my work-in-progress tinkering with the change essentially here.

This applies the base path prefix to the entry file. This is not a complete fix because I'm having trouble finding where these paths should actually be set. It's not a complete solution, more proof that there's an issue to be addressed I think.

[andycarlberg]

I feel like I'm on the right track here with this change.

It correctly outputs the file path with the base prefix but it 404's when looking for that start.js file. In debugging, it seems like that file is treated differently than other requests since the SvelteKit middleware doesn't process that file without my change (i.e. root-relative).

Any hints on where I might look to get it to recognize that file as the special start file even if it has the prefix?

[bjaskj]

I spent some time on something I think is similar, but I did not manage to figure out a fix for it.

I'm trying to use svelte kit via proxy server, and it works fine with static build and serve via other folder than root (having kit.paths.base) but it goes around and tries to include files that are in "root", like node modules etc. I only got it working if I set the base in vite config in the kit package and also modified the prefix, see below:

I think it boils down to the core/dev/index.js having a hardcoded value of "/", I tried playing around with this with some success but I ran into other issues trying to find a way to set it.

I also looked into prefix set to value of "" in this core/dev/plugin.js

This makes the paths to the script resources etc used in start method inside runtime/server/page/render.js

Maybe someone can help with a fix on this?

[johnnysprinkles]

Not sure if this stackoverflow question is related: https://stackoverflow.com/questions/69378392/sveltekit-base-url-for-subdirectory-throws-404 They don't seem to be using a proxy though. I am using a proxy with stunnel and running into this issue, just working around with conditional svelteconfig, like:

{
  kit: {
    paths: {
      base: process.env.NODE_ENV === 'development' ? undefined : '/mybase',
    },
  },
}

Edit: The downside of this though is navigation, if I have a header on various pages at different levels in the tree, and it has links or "goto" calls, it'll need an absolute path which can't work in both prod and dev.

[johnnysprinkles]

So it turns out this is only the index route that fails to load, any deeper path works fine.

[bjaskj]

What happen to me was that if I set kit.paths.base and then also the vite base path, which is hardcoded to '/' in kit, then I have to use /mypath/mypath to get to index. So something is a bit bork. Also if I managed to get it use /mypath, then all the other paths (node_modules, svelte kit etc) would still go to root/hostname http://localhost/.svelte-kit.

[johnnysprinkles]

So I just wanted to clarify and provide simple repo steps, and make sure I'm actually in the right bug (I can open a new one if not.) This doesn't have anything to do with proxies or missing js/css assets, it's actually that the main HTML document is 404 when using a base path and running in dev mode.

1. Init a brand new SvelteKit app with npm init svelte@next sv which gives as of now, SvelteKit v1.0.0-next.230
2. Choose the Demo App
3. cd sv; npm i
4. npm run dev
5. Everything works fine
6. Kill that, edit svelte.config.js to include kit.paths.base = '/foo'
7. Start up again with npm run dev
8. Note that both http://localhost:3000 and http://localhost:3000/foo give you a 404.
9. Note that deeper paths do work however, i.e. http://localhost:3000/foo/about