Multiple rest parameters: Make eagerness configurable or respect parameter matcher

[fkling]

Describe the problem

I was on the fence whether to file this as a bug report or feature request.

Consider the following route, /[...repo]/-/[...path], where repo would be an arbitrary repository name and path an arbitrary file path. Having a path that also contains the "separator" /-/ causes a problem. The repo rest parameter matches eagerly, i.e. it uses the longest match. Given a destination like /repo/-/some/path/-/to/file, the parameters would be matched as

repo: repo/-/some/path
path: to/file

whereas the desired match is

repo: repo
path some/path/-/to/file

Changing the route to include a parameter matcher that ensures that repo doesn't contain /-/ doesn't solve the problem either. Instead of trying a shorter match SvelteKit considers the page to not exist.

Here is a reproduction of the issue: https://github.com/fkling/sveltekit-rest-parameters-demo

Describe the proposed solution

It would be great if there was a way to indicate that a rest parameter should by lazy instead of eager or if SvelteKit would keep trying different slices of the path when the parameter matcher returns false.

Alternatives considered

Using parameter matchers was the alternative that I tried, but that didn't have the desired result. I don't see any other way to achieve this behavior.

Importance

i cannot use SvelteKit without it

Additional Information

I selected importance as "i cannot use SvelteKit without it" because our application has to work on arbitrary (customer) data. I.e we don't have control over the file paths used by customers (we have some control over the repository name mapping).
Somewhat ironically this issue prevents us from browsing the corresponding SvelteKit files with our app in our own repository.

[gterras]

This kind of sounds like a stick to beat you with considering your param is rest and can contain both slashes and the next segment separator. I see multiple solutions without expanding the params API (which has little to none room left):

• make repo a non-rest parameter
• have another separator segment like /@/ instead of /-/
• encode your repo parameter

The rest parameters docs has an example demonstrating exactly what you are trying to do, is there anything different in your case?

[fkling]

The rest parameters docs has an example demonstrating exactly what you are trying to do, is there anything different in your case?

The repository identifiers are relatively free form. The might match [codehost]/[org]/[repo] but they could also just be [repo] or any other pattern, e.g. on self-hosted instances.

• make repo a non-rest parameter
• encode your repo parameter

It seems like these would have to go together since repo cannot contain / without being encoded. This is not practical in our case because it wouldn't work for existing links. And, to a lesser degree, it doesn't look good either.

have another separator segment like /@/ instead of /-/

That would result in the same problem if file path contains /@/ anywhere. Also it would break existing links so changing the overall structure of these URLs is not really possible.

This kind of sounds like a stick to beat you with considering your param is rest and can contain both slashes and the next segment separator.

repo cannot contain /-/. That's one of the few restrictions and is encoded in the parameter matcher. That's why I was surprised that adding the matcher doesn't solve the problem. I expected the routing logic to match the whole path differently.

---

It's an existing application that I'm build a prototype in SvelteKit for.
I acknowledge that the situation is not ideal, but the server as well as the existing client is able to parse these URLs as desired. So it doesn't seem too unreasonable to allow more control over the parsing process, even if it's something that needs to be done carefully.