Feat/resolve route imp

[jycouet]

Fixes: #11386

• 1/ id typed with RouteId
• 2/ params typed with inferred params from the route (optionals, matcher)
• 3/ express SearchParams of a route.
• 4/ support SERVERS routes
• 5/ support ACTIONS routes

Current status

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
• This message body should clearly illustrate what problems it solves.
• 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 pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: 0fdec66

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

[jycouet]

Lint is not passing because I wrote the type here directly. It seems that we have to do it in JSDoc, but I don't manage to do it.
I would need some guidance.

[Rich-Harris]

I too am somewhat flummoxed by JSDoc in this case. For now I've put this stuff in a src .d.ts file, which sort of works, though there are some other problems that need solving separately.

I took the liberty of moving the RouteId type to $types rather than $app/paths — it's arguably more consistent with the various ./$types files, and it'll be convenient to have a single place to put all the generated types.

Right now it doesn't seem like that ambient declaration is getting picked up — working on it...

[david-plugge]

This is awesome!

[jycouet]

Maybe @Rich-Harris you can share your initial thoughts here or in the issue?
Who can help on the JSDoc part?

[Rich-Harris]

Here's a wrinkle: the generated types need to be in an ambient module declaration (per #11406 (comment), I changed this from $app/paths to $types), but ambient modules can't reference other modules via relative paths. As such, I don't think it's possible to use parameter matchers to provide finer-grained constraints for parameters than string.

I think that's probably fine, since the ParamMatcher type is just (param: string) => boolean, and it's finicky to express parameter constraints as types anyway (and hard to keep them in sync with the actual logic). So my inclination is to ditch the MatcherParam stuff from the generated types.

[Rich-Harris]

ok, this is working pretty well for me locally now — will stop fiddling about with the PR for a bit now that the types are being generated more or less as expected

excited for this! not totally sure what parts 3, 4 and 5 will entail?

[jycouet]

I kinda liked a lot the ParamMatcher++ (thx to #10755). As it allows:

export const match = (param: 'a' | 'b') => {
  return ['a', 'b'].includes(param)
}

// or

export const match = (param: number) => {
  return /^\d+$/.test(param.toString())
}

Maybe reconsidering $types vs $app/paths would allow to still keep it?

[Rich-Harris]

I'm not sure how it would — it's an ambient module declaration either way

[Rich-Harris]

Oh... unless it wasn't an ambient module declaration, but was actually an alias instead? Hmm