We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation .
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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]/-/[...path]
repo
path
/-/
/repo/-/some/path/-/to/file
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
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 .
false
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.
i cannot use SvelteKit without it
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.
The text was updated successfully, but these errors were encountered:
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):
/@/
The rest parameters docs has an example demonstrating exactly what you are trying to do, is there anything different in your case?
Sorry, something went wrong.
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.
[codehost]/[org]/[repo]
[repo]
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.
No branches or pull requests
