kit: Dev server does not apply base path correctly

I am running a svelte-kit dev server behind a code-server proxy and can confirm that this is still an issue. Any fix or workaround available?

@johnnysprinkles sorry to be blunt, and I don’t think you intended this, but I think you derailed this issue for an unrelated problem.

@benmccann the problem in question still exists and it’s a different one. In the example above, localhost:3000/foo is working, but the reason why it’s working is because localhost:3000/.svelte-kit is still available without a proxy. If you put a proxy in front and only forward /foo to the server, you’d only forward requests to /foo, but not /.svelte-kit, you’ll be getting 404 errors for SvelteKit runtime and nothing will work at all. The issue here is that kit.paths.base should be applied to /.svelte-kit too, which it’s currently not.

You can easily verify it with the repro above, but look into Developer Tools, where you should see something like this:

If /.svelte-kit is not properly forwarded as /foo/.svelte-kit, nothing will work. And forwarding just /.svelte-kit is not a solution, since the whole reason people use proxies is to host multiple sites on the same domain, so most people need a /foo with /foo/.svelte-kit and a /bar with /bar/.svelte-kit.

Looks like this change works, I’m using coder’s code-server and serving from some-domain/proxy/5173

The page is loading the start script from the correct location.

I talked to the Vite team this morning and made quite a bit of progress on a plan for moving forward. I sent https://github.com/sveltejs/kit/pull/7343 to address one of the items. I also sent https://github.com/vitejs/vite/pull/10590 to address a good chunk of https://github.com/vitejs/vite/issues/9236. @BenediktAllendorf I’ll ping you after https://github.com/vitejs/vite/pull/10590 gets merged and perhaps if you’re still interested you can finish the rest of https://github.com/vitejs/vite/issues/9236 which would be the last blocker.

As OP, i wanted to verify that @rassie is correct. Their comment shows the issue I was originally trying to deal with. I haven’t personally made any further progress on it but would agree the issue is not fixed.

@benmccann pardon me asking, maybe I’m missing something here, but what exactly has been fixed? You basically just said “works for me” (which is fine and probably true for the example above), but has there been any change addressing the original problem and the comments above?

This is no longer blocked by Vite, but I believe an additional change will be needed on our side

In a setup with a reverse proxy, the “external base path” might or might not be preserved when forwarded to the server itself. So it would be nice to have either a) thw base paths: an external that is used when creating all the links and an internal that is used when interpreting the requests b) a flag that allows for the fact that the proxy might remove the external base path when relaying the request to the server.

It’s really annoying. I need to run the programm behind a reverse proxy in order get the correct authentication information. I would run “dev” mode, but that does not work in that setup. So i need to run buikd and preview after each change in code.

Above point_up_2 there are the routes you need to add to your proxy. Posted as an example for nginx. Adapt, and it works. Do you need any help with another proxy?

Only works for one proxied site. Two or more is currently impossible.

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

If you’re just running the dev server locally, you will be able to navigate the project. Check the browser dev tools and note the paths that are being requested. The /@fs/... paths don’t include the base path prefix. This is the actual issue that needs to be addressed.

It works for local development because the local dev server has access to both the base path and the non-prefixed paths. It becomes a problem for development behind a proxy where the base path is necessary to access any files on the dev server. In my case, this is surfaced when I’m trying to use code-server to develop. The dev server isn’t accessible locally because it isn’t running locally. Instead, I access it through a proxied base path. It works for the initial page load but those /@fs/... paths can’t be reached without the base path prefix.

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.

The solution appears to be inadequate in handling cases where paths.relative is enabled but paths.base is absent, which was implemented to enable flexible base paths.

If a reverse-proxy is created and directed to the site using a path like /site-pr-10, the app.js file will load correctly but the start.js file will not. Essentially, this solution disrupts the functionality described in issue #595 when used behind a reverse proxy.

Perhaps this line:

https://github.com/sveltejs/kit/blob/06a56ae587795113b17fec559ab49c93f40861e8/packages/kit/src/runtime/server/page/render.js#L168

Needs to be changed to:

const prefixed = (path) => (path.startsWith('/') ? base + path : `${resolved_assets}/${path}`);

Would someone affected by this problem be able to test it out?

My team uses nginx + docker-compose to set up a dev environment with multiple APIs/frontends. Since we only have one svelte-kit project, this is ok for now, but it is not ideal. In order to get the current version of svelte-kit to work in this set up, we need to set up nginx with the below configuration. I’d expect that analogous configuration is required in whatever reverse proxy environment is being used. (HMR config is separate, but easier to implement because it’s on a different port).

        location /svelte-kit-ui-base-path {
            set $target "http://svelte_kit_ui:3000";
            proxy_pass $target;
        }
        location  /@fs {
            set $target "http://svelte_kit_ui:3000";
            proxy_pass $target;
        }
        location /.svelte-kit {
            set $target "http://svelte_kit_ui:3000";
            proxy_pass $target;
        }
        location /node_modules {
            set $target "http://svelte_kit_ui:3000";
            proxy_pass $target;
        }
        location /@vite/client {
            set $target "http://svelte_kit_ui:3000";
            proxy_pass $target;
        }
        location /src {
            set $target "http://svelte_kit_ui:3000";
            proxy_pass $target;
        }

I’d view this as a work-around, not a long-term solution. Hopefully this saves time for anyone else having trouble with this.

It would be very nice to be able to prefix every route above with /svelte-kit-ui-base-path.

Note that both http://localhost:3000 and http://localhost:3000/foo give you a 404.

http://localhost:3000/foo works for me. Closing as fixed

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

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?