Optional route with matcher followed by rest parameters

Describe the bug

Given a [[lang=lang]]/[...path] route, kit will fail to catch non-matched URLs with the rest parameters route.

The same doesn’t happen if the optional route is followed by a static one: [[lang=lang]]/t/[...path].

// params/lang.js
export const match = (param) => {
  return ['fr', 'de'].includes(param);
};

I would expect:

/home -> { lang: undefined, path: 'home' } -> gives 404
/de/home -> { lang: 'de', path: 'home' } -> correct

In the [[lang=lang]]/t/[...path] scenario, it works as expected:

/t/home -> { lang: undefined, path: 'home' } -> correct
/de/t/home -> { lang: 'de', path: 'home' } -> correct

A common use case for this would be an i18n site with dynamic pages being served by a CMS.

Reproduction

Here’s a stackblitz reproducing the issue: https://stackblitz.com/edit/sveltejs-kit-template-default-4srbff?file=src/routes/+layout.svelte

And here’s another one showing the correct expected behaviour by placing a static route after the optional one: https://stackblitz.com/edit/sveltejs-kit-template-default-a3vmdd?file=src/routes/+layout.svelte

Logs

No response

System Info

System:
    OS: macOS 13.0
    CPU: (8) arm64 Apple M2
    Memory: 50.08 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.10.0 - ~/.nvm/versions/node/v18.10.0/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v18.10.0/bin/npm
    Watchman: 2022.10.03.00 - /opt/homebrew/bin/watchman
  Browsers:
    Brave Browser: 107.1.45.116
    Chrome: 107.0.5304.87
    Firefox: 106.0.5
    Safari: 16.1
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.87
    @sveltejs/kit: 1.0.0-next.538  => 1.0.0-next.538
    svelte: ^3.44.0 => 3.52.0
    vite: ^3.1.0 => 3.2.3

Severity

serious, but I can work around it

Additional Information

No response

[pdrbrnd]

That’s right. I see that we have access to params on every load function, even in a layout outside.

Even tho I understand the limitation of the greedy Regex approach, it still feels a bit inconsistent when taking into account static routes. I feel that it’s easy for a case like the current example in the optional routing docs to evolve into a catch-all route and, suddenly, the behaviour changes because of implementation details. Anyway, the addition to the docs is most welcome.

Feel free to close the issue if this is indeed working as designed.

Thank you for all the support 😃

[dummdidumm]

[...rest] includes zero to n segments, so in a sense it’s also optional, yes. I don’t know for what you use the lang parameter, but you could still infer it from the rest segment. For de/home the params object would be { rest: "de/home" } so you could add your own little check to that and extract the language from that. You could do that inside your load function, no handle hook needed.