Unexpected href link without resolve().

[bennajah]

C:\Users\benna\dev\svelte-demo\src\routes\+layout.svelte
  15:6  error  Unexpected href link without resolve()  svelte/no-navigation-without-resolve

✖ 1 problem (1 error, 0 warnings)

error: script "lint" exited with code 1

create sv project then run lint

repo: https://github.com/bennajah/svelte-demo

[samuelstroschein]

Thanks for reporting! I fixed the example in #640 and also made an upstream PR to Svelte's CLI sveltejs/cli#990.

The issue should auto close once Svelte merges the PR

[doughoff]

hm im missing something?

even while using:

<a href={resolve(localizeHref('/'))}>
	{m.auth_login()}
</a>

Because at least here on my versions:

├── @inlang/paraglide-js@2.15.0
└── @sveltejs/kit@2.55.0

The return type of localizeHref is a string:

localizeHref(href: string, options?: {
    locale?: "en" | "es" | undefined;
}): string

While the input type for resolve is a enum for the routes on the application.

it can be "solved" by using a wrapper to cast, like this:

export function safeLocaleRoute(
	...args: Parameters<typeof localizeHref>
): Parameters<typeof resolve> {
	return [localizeHref(...args)] as Parameters<typeof resolve>;
}

// usage:
resolve(...safeLocaleRoute('/'))

its bad to lose type safety for the routes so i was experimenting some alternatives, but:

export function exampleResolveWrapper(...args: Parameters<typeof resolve>): ResolvedPathname {
	return resolve(...args);
}

The linter doesnt use the return type, instead it checks by the actual resolve function call on the svelte template, on ts it works fine.

trying another alternative:

export function experimentalLocaleRoute(
	...args: Parameters<typeof resolve>
): Parameters<typeof resolve> {
	return [localizeHref(resolve(...args))] as Parameters<typeof resolve>;
}

this works fine for svelte template routes (did not test it completely), like <a href={resolve(...experimentalLocaleRoute)}>
But when using it in remote functions the behavior is strange:

[404] GET /ttp:/localhost:5173/
example from remote function:  ./ttp:/localhost:5173/

the href resolves to full path eg: http://localhost:5173/
then resolve gets that and tries to match a route like http://localhost:5173/ttp:/localhost:5173/

debug sample:

	const searchParams = new URLSearchParams();
		searchParams.append('example_key', 'example_value');
		const [aux] = experimentalLocaleRoute('/(app)');
		const fullURL = new URL(aux + `?${searchParams}`);
		const path = fullURL.pathname;
		const search = fullURL.searchParams;
		console.log({
			path,
			aux,
			fullURL
		});

		redirect(303, (path as ResolvedPathname) + `?${search}`);

{
  path: '/',
  aux: 'http://localhost:5173/',
  fullURL: URL {
    href: 'http://localhost:5173/?example_key=example_value',
    origin: 'http://localhost:5173',
    protocol: 'http:',
    username: '',
    password: '',
    host: 'localhost:5173',
    hostname: 'localhost',
    port: '5173',
    pathname: '/',
    search: '?example_key=example_value',
    searchParams: URLSearchParams { 'example_key' => 'example_value' },
    hash: ''
  }
}

So the end result as a hacky solution to have type safety im using:

export function experimentalLocaleRoute(
	...args: Parameters<typeof resolve>
): Parameters<typeof resolve> {
	const localizedResult = localizeHref(resolve(...args));

	if (URL.canParse(localizedResult)) {
		const { pathname } = new URL(localizedResult);
		return [pathname] as Parameters<typeof resolve>;
	}

	return [localizedResult] as Parameters<typeof resolve>;
}

maybe im just crazy and this all doesn't make sense. This solution is not ideal, running resolve multiple times, parsing url etc.. is inefficient, i hope my examples help.

[sacrosanctic]

The linter doesnt use the return type, instead it checks by the actual resolve function call on the svelte template, on ts it works fine.

That's a bug, here's the issue. sveltejs/eslint-plugin-svelte#1319

[bennajah]

@samuelstroschein
There is still a type error when using resolve with localizeHref.

resolve expects a ResolvedPathname type , but localizeHref(page.url.pathname, { locale }) returns a string, which causes a type mismatch.

Error: Argument of type '[string]' is not assignable to parameter of type '[route: "/"] | [route: "/(web)"] | [route: "/(auth)"] | [route: `/?${string}`] | [route: `/(web)?${string}`] | [route: `/(auth)?${string}`] | [route: `/#${string}`] | [route: `/(web)#${string}`] | [route: `/(auth)#${string}`]'.
Type '[string]' is not assignable to type '[route: `/(auth)#${string}`]'.
Type 'string' is not assignable to type '`/(auth)#${string}`'. (ts)

[samuelstroschein]

Yeah but like what else should localizeHref return? it has to be a string. I hope the Svelte maintainers can jump in to clarify what's the expectation here

[bennajah]

Yeah but like what else should localizeHref return? it has to be a string. I hope the Svelte maintainers can jump in to clarify what's the expectation here

The return type of resolve should be ResolvedPathname, ensuring it is restricted to valid route patterns rather than a generic string.

For instance, given routes / and /about, the resulting ResolvedPathname type should resolve to:

/ | /#${string} | /about | /about#${string}

see this https://svelte.dev/docs/kit/$app-types#ResolvedPathname

[samuelstroschein]

LocalizeHref is a generic API. It won't return Svelte specific types. The big learning of Paraglide JS is that we can have an API that works for every framework. I am ensure why Svelte a normal anchor tag in Svelte(Kit) suddenly requires the resolve() function instead of taking a plain string

[bennajah]

LocalizeHref is a generic API. It won't return Svelte specific types. The big learning of Paraglide JS is that we can have an API that works for every framework. I am ensure why Svelte a normal anchor tag in Svelte(Kit) suddenly requires the resolve() function instead of taking a plain string

localizeHref is intentionally framework-agnostic—it returns a plain string and doesn’t include Svelte-specific types. That’s actually one of the core ideas behind Paraglide JS: providing a universal API that works consistently across different frameworks.

However, in SvelteKit, things are a bit stricter. A standard tag doesn’t always accept arbitrary strings for internal navigation, and instead expects properly resolved paths via resolve(). This creates a mismatch between Paraglide’s generic output and SvelteKit’s typed routing system.

To bridge that gap, it makes sense to introduce a small Link component that adapts localizeHref to SvelteKit’s expectations:

<script lang="ts">
  import type { HTMLAnchorAttributes } from "svelte/elements";
  import { resolve } from "$app/paths";
  import type { Pathname, ResolvedPathname } from "$app/types";
  import { type Locale, localizeHref } from "$lib/paraglide/runtime";

  let {
    href,
    options,
    children,
    ...props
  }: HTMLAnchorAttributes & {
    href: ResolvedPathname;
    options?: { locale?: Locale };
  } = $props();
</script>

<a href={resolve(localizeHref(href, options) as Pathname)} {...props}>
  {@render children?.()}
</a>

[samuelstroschein]

@bennajah hmmm so should paraglide-js-svelte expose a ParaglideLink component?

That seems utter complicated. Especially since good old Svelte accepted <a href = >

[sacrosanctic]

It's just an eslint warming. So you can just disable it.

[bennajah]

@bennajah hmmm so should paraglide-js-svelte expose a ParaglideLink component?

That seems utter complicated. Especially since good old Svelte accepted <a href = >

or just add the Link components to the Svelte docs to resolve the ESLint warning and reduce repetition.

[sacrosanctic]

There's no difference between a Link component and the resolve fn in this case.

The problem still stands where svelte expected a narrow string and paraglide provides a generic string.