[fix] 1714 rest params in endpoint

[dreitzner]

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• fixes Allow rest parameters as end of endpoint route #1714
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: fae0950

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[bluwy]

I doubt we want a hard-coded check for [...rest].json.js. .json is a convention and it can be anything else by the user. Also, have you confirm with this change that a SvelteKit app still routes normally? I have a hunch there are other places to fix as well.

With that said, I'm not sure what's the path forward, or maybe we should stick with the issue workaround for now. I'll see if the others has an opinion on this.

[dreitzner]

It might be good to make it more flexible in the future.

But there are strong reasons to implement that fix:

• .json is the framework convention for endpoints
• .json is used in the example project
• because of that we would create unnecessary friction for new users coming to the framework

[Rich-Harris]

Thank you. The answer is both simpler and more complicated than this — simpler in that we can just allow any rest segment to have a prefix/suffix (as I believe was the case with Sapper), and more complex in that we need to tweak the implementation a bit. Closing this in favour of #3240.