Typescript error when `resolve` has a query string parameter

[mikenikles]

Describe the bug

This is fine:

This should be fine, but is not:

Reproduction

Use the new resolve function with a query string parameter in the first parameter's string.

Logs

System Info

npx envinfo --system --npmPackages svelte,rollup,webpack --binaries --browsers

  System:
    OS: macOS 15.5
    CPU: (8) arm64 Apple M2
    Memory: 227.25 MB / 16.00 GB
    Shell: 3.7.1 - /Users/m/.local/share/devbox/global/default/.devbox/nix/profile/default/bin/fish
  Binaries:
    Node: 22.14.0 - ~/projects/github/pipestack/webapp/main/.devbox/nix/profile/default/bin/node
    npm: 10.9.2 - ~/projects/github/pipestack/webapp/main/.devbox/nix/profile/default/bin/npm
  Browsers:
    Brave Browser: 137.1.79.118
    Chrome: 138.0.7204.184
    Safari: 18.5
  npmPackages:
    svelte: ^5.37.3 => 5.37.3

Severity

blocking an upgrade of svelte

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

I think this is intentional... or at least I'm not sure there's any way around it. I would do this: ${resolve('/[workspaceSlug]/pipeline', { workspaceSlug: 'demo' })}?{queryParams}

Maybe @Rich-Harris has a more-clever idea for something we could do with types to make this work? But in my mental model resolve operates on pathnames, not full-blown URLs.

[Conduitry]

See also #14062 for another thing we need to decide whether it's intentional - It was my impression that this should be passed actual route identifiers, which would mean including named groups where they exist, and not including query parameters.

[mikenikles]

Ah fair enough, operating on route identifiers is fine. The now deprecated resolveRoute function accepted query parameters and my global find & replace migration to resolve was a bit too basic 😊.

[mispp]

there is also a 2nd problem here, underlined on the screenshot: expected one argument but got 2. Is this being also addressed somewhere?

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

@mispp this is expected -- you can only provide the second parameter if the first is a valid path in your app. See my comment above for the workaround.

[theodore-s-beers]

Ah fair enough, operating on route identifiers is fine. The now deprecated resolveRoute function accepted query parameters and my global find & replace migration to resolve was a bit too basic 😊.

The thing is, if there's no way to add query params inside a resolve call, that means there's also no way (afaik) to satisfy the linter that a relative URL has been resolved if it includes params. We're stuck between a rock and a hard place.

[mdanilakis]

Is there any planned work to add support for query params? I'm stuck in so many cases where eslint complains with:

Unexpected goto() call without resolve()

But there's no way to make it happy with tricks like:

goto(`${resolve('/[slug]/path', { slug: 'demo' })}?key=val`)

[theodore-s-beers]

Fwiw, I set "svelte/no-navigation-without-resolve": "warn" in ESLint config in all my Svelte projects and am just dealing with the warnings on a best-effort basis.

I still find it confusing that the lint rule landed, defaulting to "error", when the feature that it depends on seems not to be 100% finished.