Multiple rest parameters: Make eagerness configurable or respect parameter matcher about kit HOT 2 OPEN

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?

from kit.

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.

from kit.