Wrong generated link for sub/sub page

[charlyoleg2]

Describe the bug

In +layout.svelte, i have a link <a href="{base}">home</a>. For the homepage (src/routes/+page.svelte) and the sub1-page (src/routes/sub1/+page.svelte), the link brings to the expected page (i.e. the homepage). But for the sub2-page (src/routes/sub1/sub2/+page.svelte), the link brings to the sub1-page. I'm using the adapter-static. The bug is present if you start the sveltekit at the homepage: Load the homepage, then navigate to sub2-page, then use the link and you get the bug. But if you start the sveltekit at the sub2-page, the bug is not present: Load the sub2-page, then use the link, you are now at the homepage as expected.

Reproduction

You can experiment the bug on this github page: https://charlyoleg2.github.io/parame51 The +layout.svelte that contains the buggy link: https://github.com/charlyoleg2/parame51/blob/main/pkg/desi51-ui/src/routes/%2Blayout.svelte

Logs

No log. Just landing on a wrong page.

System Info

System:
    OS: Linux 6.5 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz
    Memory: 12.28 GB / 15.36 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 20.11.1 - /usr/bin/node
    npm: 10.2.4 - /usr/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: ^3.0.0 => 3.1.1 
    @sveltejs/adapter-static: ^3.0.1 => 3.0.1 
    @sveltejs/kit: ^2.0.0 => 2.5.1 
    @sveltejs/vite-plugin-svelte: ^3.0.0 => 3.0.2 
    svelte: ^4.2.7 => 4.2.11 
    vite: ^5.0.3 => 5.1.4

Severity

annoyance

Additional Information

No response

[teemingc]

The base is set to a relative path during SSR. https://github.com/sveltejs/kit/blob/4ae1cd152a60a22044ab3b8aa5572a2b79864583/packages/kit/src/runtime/server/page/render.js#L99-L101

However, navigating to another page does not re-render the root layout so the href stays the same (which is incorrect if we're on a different page).

For example, if the base is /parame51, loading the route /parame51/ will render the href as ./. But when we navigate to /parame51/example the href is still ./.

You can workaround this by setting kit.config.paths.relative to false. This will always use an absolute URL for anchor elements.

EDIT: The base seems to be repaired when it reaches the client. But I can't figure out why that isn't in the case in your reproduction.

https://stackblitz.com/edit/sveltejs-kit-template-default-gpxktc?file=src%2Froutes%2FHeader.svelte

[teemingc]

I can't reproduce the issue with the given reproduction or my own. The repository you have linked requires installing packages from a private(?) registry.

[charlyoleg2]

I have create a more minimalist code base: https://github.com/charlyoleg2/link_issue npm run build npm run preview load the homepage, go to sub2, use the homepage link. You are in sub1, which is unexpected.

[ykyki]

I encountered the same issue as well. I found it that an <a> tag with href defined in base had an unexpected pathname property when a page transition was occured.

My code: https://github.com/ykyki/blog/blob/6bc034c0e7d55480b67b17d4401e341edf8c52b5/sveltecf/src/lib/component/BlogHeader.svelte#L6-L14

[charlyoleg2]

After playing with svelte.config.js, I see that setting paths.relative to false makes things worse: On each page, the homepage-link points to the page itself. And 'npm run dev' has link issues.

[charlyoleg2]

With the two following changes, it works: 1- use a trailing slash in the url with base <a href="{base}/">home</a> 2- in svelte.config.js, set paths.relative to false Now the homepage-link works as expected in preview and debug mode

[charlyoleg2]

To summarize, we have four cases: 1- paths.relative = false and url with trailing slash: No bug, it works 2- paths.relative = false and url without trailing slash: Buggy 3- paths.relative = true and url with trailing slash: Buggy 4- paths.relative = true and url without trailing slash: Buggy

[ykyki]

Setting "paths.relative = false" resolved my problem. commit: https://github.com/ykyki/blog/pull/13/commits/5d4e0ca0fd0647ccf77c7947f5c1a931ef8be2d7

If this modification is not made, it will work correctly in develop mode but not in preview mode.

[jycouet]

I guess that the usage of resolve() will make it work.