False positive with svelte/no-navigation-without-resolve using variable in a list

[patte]

Before You File a Bug Report Please Confirm You Have Done The Following...

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.

What version of ESLint are you using?

9.34.0

What version of eslint-plugin-svelte are you using?

3.12.0

What did you do?

Resolved links in a list are not detected as resolved.

Minimal reproduction:

<script lang="ts">
	import { resolve } from '$app/paths';

	const works = resolve(`/`);

	const notWorkingList = [
		{ title: 'Home', url: resolve(`/`) },
		{ title: 'Clients', url: resolve(`/clients`) },
	];
</script>

<!-- ✅ works as expected -->
<a href={works}>Go to Home</a>

{#each notWorkingList as item (item.title)}
	<!-- ❌ Found a link with a url that isn't resolved. -->
	<a href={item.url}>{item.title}</a>
{/each}

This also doesn't work:

<script lang="ts">
	import { resolve } from '$app/paths';

	const notWorkingList = [
		{ title: 'Home', url: `/` },
		{ title: 'Clients', url: `/clients` },
	];
</script>

{#each notWorkingList as item (item.title)}
	<!-- ❌ Argument of type '[string]' is not assignable to parameter of type '[route: "/"] | [route: "/clients"] | ... -->
	<a href={resolve(item.url)}>{item.title}</a>
{/each}

What did you expect to happen?

Already resolved pathnames are detected whether they are in a list or not.

What actually happened?

Error: Found a link with a url that isn't resolved.eslintsvelte/no-navigation-without-resolve

Link to GitHub Repo with Minimal Reproducible Example

Will provide later if needed.

Additional comments

Related question: How to handle dynamic values like the pushState when shallow routing?

[cnolte]

It also doesn’t work in combination with Paraglide JS, the localization tool recommended by the Svelte CLI. They use something like this:

<a href={localizeHref("/blog")}>Blog</a>

[marekdedic]

Thanks for the report, but I'm not really sure what to do with this... Let's take the last example (and I think the rest is the same):

<a href={localizeHref("/blog")}>Blog</a>

I mean... The link isn't resolved and it doesn't seem to be an absolute URL, so I'd say the rule works as intended...

At the same time, I understand that this can seem impractical, but I'd probably just follow the same rules as when escaping values - do it at the last possible moment, ideally inside the link itself (but the rule should also work if you use a variable that is defined in the same file).

So if you are localising for internal navigation, then you should resolve. I don't really see a use-case for localising for external navigation (though I'm sure there is somebody somewhere doing that :D).

[patte]

@marekdedic Thank you very much for the reply. I find the example of @cnolte not very helpful for the discussion.

Trying to follow your suggestion to "do it at the last possible moment". This does indeed work using as const

<script lang="ts">
	import { resolve } from '$app/paths';

	const notWorkingList = [
		{ title: 'Home', url: `/` as const },
		{ title: 'Clients', url: `/clients` as const },
	];
</script>

{#each notWorkingList as item (item.title)}
	<!-- ✅ --> 
	<a href={resolve(item.url)}>{item.title}</a>
{/each}

But it's confusing. Can you explain why notWorkingList.url which is a ResolvedPathname, does not work? But if it's a variable it does?

I have a nav component with a nested list, which requires to define the type beforehand. Neither as const nor as ResolvedPathname works in this case. Is there a trick to make this work?

<script lang="ts">
type MenuItem = {
	  title: string;
		url: string;
		icon?: typeof IconType;
		subItems: Array<Omit<MenuItem, 'subItems'>>;
	};

	const items: MenuItem[] = [
		{
			title: m['sidebar.home'](),
			url: '/',
			icon: House,
			subItems: [],
		},
		{
			title: m['sidebar.clients'](),
			url: '/clients',
			icon: HandHeart,
			subItems: [],
		},
		{
			title: m['sidebar.documents'](),
			url: '/documents',
			icon: File,
			subItems: [
				{
					title: m['document.types.unassigned'](),
					url: '/documents?docsView=unassigned',
				},
				{
					title: m['document.types.inbox'](),
					url: '/documents?docsView=inbox',
				},
			],
		},
		// ...
	];
</script>

[marekdedic]

Ha, sorry, didn't realize there were comments by 2 people. I will look into the issue with locally defined lists, that should be similar to variables...

[cnolte]

Maybe I should have opened a new ticket, but how do I avoid the svelte/no-navigation-without-resolve in my example?

<a href={localizeHref(resolve('/'))}>Home</a> <!-- This throws the error -->

[marekdedic]

@cnolte This should solve your issue:

<a href={resolve(localizeHref('/'))}>Home</a>

[cnolte]

@marekdedic no it doesn‘t because this throws a Type error. LocalizeHref returns a string and resolve expects a valid path.

[marekdedic]

Well, that seems to me like a correct type error... localizeHref can actually return anything, not just valid paths. If you are sure that all the return values are valid, you should use a type assertion. While that may not look as clean, I think it actually better expresses that the return value of localizeHref may not be a valid path and you are asserting that in your particular case it is.

[marekdedic]

As for the original issue: Let's wait for #1321 and #1322 and take a look after that.

[gleich]

I am getting this error even when the variable is defined within the same file as the a tag:

<script lang="ts">
	import HevyIcon from '$lib/icons/hevy-icon.svelte';
	import StravaIcon from '$lib/icons/strava-icon.svelte';
	import type { LcpResponse } from '$lib/lcp/lcp.server';
	import { type Workout as LcpWorkout } from '$lib/lcp/workouts';
	import Loading from '$lib/loading.svelte';
	import ViewButton from '$lib/view-button.svelte';
	import { Error } from '@gleich/ui';
	import Section from '../../section.svelte';
	import Workout from './workout.svelte';
	import { resolve } from '$app/paths';

	const { workouts, loading }: { workouts?: LcpResponse<LcpWorkout[]> | null; loading?: boolean } =
		$props();

	const stravaURL = 'https://www.strava.com/about';
	const hevyURL = 'https://www.hevyapp.com';
</script>

<Section
	name="Workouts"
	liveData={{
		sources: [
			{
				name: 'Strava',
				icon: StravaIcon,
				url: stravaURL,
				iconLeftMargin: '8px',
				iconRightMargin: '5px'
			},
			{
				name: 'Hevy',
				icon: HevyIcon,
				url: hevyURL,
				iconLeftMargin: '10px',
				iconRightMargin: '8px'
			}
		],
		updated: workouts?.updated
	}}
>
	{#if loading}
		<Loading height={529.91} />
	{:else if workouts != null}
		<p>
			One of my favorite things is staying active and enjoying the outdoors. I grew up in New
			Hampshire hiking, biking, snowshoeing, and traveling with my family. Out of all of those
			things I especially love cycling mainly through gravel cycling, road cycling, and mountain
			biking. Recently I've been getting into lifting which has been a ton of fun. Below are 2 of my
			most recent <a href={stravaURL} rel="external" target="_blank">Strava</a>/<a
				href={hevyURL}
				rel="external">Hevy</a
			>
			workouts:
		</p>
		<div class="workouts">
			{#each workouts.data.slice(0, 2) as workout (workout.id)}
				<div class="workout">
					<Workout {workout} />
				</div>
			{/each}
		</div>
		<a class="view-more" href={resolve('/workouts')}>
			<ViewButton more of="workouts" />
		</a>
	{:else}
		<Error msg="Failed to load workout data" />
	{/if}
</Section>

[ivodolenc]

I just bump into these issues after updating dependencies, with the new rules throwing errors all over the project. It's beyond annoying, and I can't even express how frustrated I am.

And all of this started with typed params, which were breaking changes, and now you're forcing them through linting?

I'm also using dynamic links for header menus or other sidebar menus, where you generate a dynamic list from a loop or custom data. In these cases, you can't guarantee types, or you simply want to use a basic string type, and now it throws errors all over the place.

When looking at this, it becomes ultra confusing and overly complicated, and I see no point in having a plain <a> tag when we have to deal with some resolve function or other magic.

Prev:

<a href="/"></a>

New:

<script lang="ts">
  import { resolve } from '$app/paths'
</script>

<a href={resolve('/')}></a>

At this point, it would probably be best to have a built-in SvelteKit Link component that solves all this logic under the hood. All other meta frameworks have similar solutions.

Having a simple <a> tag and needing to deal with some resolve stuff has absolutely ZERO advantage over a custom Link component. So a custom component from SvelteKit would solve all this linting and resolving under the hood.

Why are these changes being forced before the docs and official tutorials are even updated?

Where is this new syntax mentioned in the documentation?

[marekdedic]

Hi,
unfortunately, I don't understand the issue with params as I am not a maintainer and/or contributor to SvelteKit.

In the provided example, in the first version, your link will break if you use a base path. It won't with the second.

AFAIK SvelteKit is considering doing something like a resolve automatically for goto (not sure about a plain <a>), but that would be a breaking change, so here we are in the meantime.