[elliott-with-the-longest-name-on-github]

Closes #9934.

Adds a resolvePath export for building relative paths from route IDs and params:

resolvePath(
  `/blog/[slug]/[...somethingElse]`,
  {
    slug: 'hello-world',
    somethingElse: 'something/else'
  }
); // `/blog/hello-world/something/else`

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: 110d716

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	Minor

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

[dummdidumm]

Since we call it route id in other places I think it would make sense to reuse that nomenclature here

Suggested change

	export function resolvePath(id, params) {
	export function resolveRoute(id, params) {

Alternatively even resolveRouteId.

Thoughts?

[Rich-Harris]

I think resolvePath is correct — we're resolving a path from a route ID + some parameters.

That said, resolvePath sounds like path.resolve, i.e. you might expect to see resolvePath(base, relative). I don't know if there's a good name for this that doesn't sound clunky and un-SvelteKit-like.

[elliott-with-the-longest-name-on-github]

Yeah, that was my reasoning as well, Rich -- I think the current name is a good mix of what it does and brevity, and the example is pretty darn clear

[Rich-Harris]

rather than calling the function indirectly like this, we should either a) re-export it or b) put the implementation here, and use that internally instead of resolve_entry (probably better, though a more significant change)

[elliott-with-the-longest-name-on-github]

Agreed, let's put the implementation here. Makes it more clear that changing the implementation affects the public API.

[Rich-Harris]

ugh i just realised that this doesn't show up in the docs, because we also need to update ambient.d.ts

this fuels my desire to build the missing library for generating .d.ts bundles with declare module from source #9895 (comment)

[Rich-Harris]

ah i tell a lie, it's not ambient.d.ts, it's types/index.d.ts which is even worse

[Rich-Harris]

Why is the second argument optional?

[elliott-with-the-longest-name-on-github]

@Rich-Harris

The second argument isn't optional, but the values of that record are because because optional route params are optional, so if you wanted to resolvePath(id, params) with auto typed params in a route with optional params, you'd need the function to accept Record<string, string | undefined> for params.

[Rich-Harris]

ohhh i read it as Record<string, string> | undefined instead of Record<string, string | undefined>

[darrylyeo]

Woohoo! That was fast.