Explain the no-navigation-without-resolve rationale

[nickolay]

I was completely baffled by the explanation at https://sveltejs.github.io/eslint-plugin-svelte/rules/no-navigation-without-resolve/ , since I had no idea there was even a possibility to configure the base URL of an app.

Before finding the docs I assumed the "Found a link with a url that isn't resolved." message shown in VS code meant it couldn't find my API route (cf. sveltejs/kit#13195), which I was accessing like this: <a href="/report/download>Download</a> — perhaps "Found a link with a URL that would break if the app is configured with a non-root base path" would be clearer?

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7b55bb1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[baseballyama]

@nickolay How about #1377? I didn’t change the detailed rule description, but I clarified the error messages themselves.

[marekdedic]

@baseballyama Why not both? :D I actually like both :)

[baseballyama]

I think the correct approach to the original issue is to improve the rule so that it doesn’t report an error when either data-sveltekit-reload or rel="external" is present.
It’s fine to merge this PR if it’s useful, but at least for me, I still don’t understand the meaning of the configured to live on a non-root path properly, so I’d appreciate it if someone could provide additional clarification.

[nickolay]

@baseballyama I like your change to the linter messages, as it removes the source of my original confusion. I see my doc change to be complementary, as I’m trying to clarify why the rule exists at all.

The added link points to paths.base documentation, which I believe adequately explains the need for resolve():

[paths.base] specifies where your app is served from and allows the app to live on a non-root path. Note that you need to prepend all your root-relative links with the base value or they will point to the root of your domain, not your base

In other words, if multiple apps coexist on a single domain a page belonging to app1 https://my.company/app1/page1 must prepend paths.base (== “/app1”) to any internal links. Failing to do that (<a href=“/page2”>) will point to https://my.company/page2 instead of /app1/page2.

I didn’t think the rule docs is the right place to go into such details, but if you meant the wording I chose is unhelpful in getting the point across, perhaps this is better:

When using any way of internal navigation, the URL must be resolved using SvelteKit's resolve(), otherwise the site may break when paths.base is changed to be non-empty.

I don’t care much about the wording or this PR, so please feel free to just make the changes you want, if that’s easier.

[nickolay]

I think the correct approach to the original issue is to improve the rule so that it doesn’t report an error when either data-sveltekit-reload or rel="external" is present.

If original issue refers to my API endpoint problem (sveltejs/kit#13195), I believe I’d actually need the resolve() if I ever decide to use non-empty paths.base.

(On the other hand, I would argue that supporting non-empty base should be opt-in — e.g. if you have actually configured such a base, — and not on by default.)