trailingSlash option to `never` is not in line with $page.params

[SteelAlloy]

Describe the bug

When settings the following config in svelte.config.js, I expect all paths to contain no trailing slashes.

const config = {
  kit: {
    trailingSlash: "never",
  }
};

But when looking at the $page.params store, this is not always the case. This happens when navigating on the website with links and looking at rest parameters.

Reproduction

Reproduction repo: https://github.com/oganexon/sveltejs-kit-trailing-slash-page-store

Stackblitz: https://stackblitz.com/edit/sveltejs-kit-template-default-vlxa2g

1. Go to /test/foo/bar/

2. See that $page.params.path == "/test/foo/bar"

3. Click on "Go up" (href=".")

4. $page.params.path == "/test/foo/" There's a trailing slash

Note: The URL doesn't update in the search bar in stackblitz. That's not part of the issue.

Logs

No response

System Info

__Local:__

  System:
    OS: Windows 10 10.0.19044
    CPU: (12) x64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
    Memory: 4.36 GB / 15.75 GB
  Binaries:
    Node: 16.14.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.17 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.3.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (104.0.1293.47)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    @sveltejs/adapter-node: ^1.0.0-next.85 => 1.0.0-next.85
    @sveltejs/kit: ^1.0.0-next.405 => 1.0.0-next.405
    svelte: ^3.49.0 => 3.49.0
    vite: ^3.0.3 => 3.0.3

__StackBlitz:__

  System:
    OS: Linux 5.0 undefined
    CPU: (4) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.10 - /bin/yarn
    npm: 7.17.0 - /bin/npm
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.64 
    @sveltejs/kit: next => 1.0.0-next.405 
    svelte: ^3.46.0 => 3.49.0 
    vite: ^3.0.0 => 3.0.5

Severity

serious, but I can work around it

Additional Information

No response

[dummdidumm]

This is super tricky - we're sort of tied here. The trailingSlash option is determined by the route that is loaded. beforeNavigate and $navigating contain params which are updated before that route's nodes are loaded, therefore before the trailingsSlash value is determined. We could modify params afterwards so that it's correct for $page.params and for the load functions, but it would be different to the value in beforeNavigate and $navigating, which sounds like a bad solution. I'm tempted to mark this as "won't fix" since it's such an edge case:

1. you need a <a href=".">
2. you need a [..rest] route
3. you need someone to navigate upwards within that rest route

Btw the URL in the browser bar is wrong, too, since . apparently triggers this behavior. The best way to avoid this is therefore to not use href="."

To fix this we would need to move loading the nodes prior to beforeNavigate. On the server we did this, I'm not sure if loading the code before using it (beforeNavigate could cancel) is the right solution. In practice it wouldn't make that much of a difference though (probably).