`~` as syntactic sugar for `base` in URLs

[boyeln]

Describe the problem

We're deploying svelte kit under different subpaths of our domain (e.g. our-domain.tld/app1/ our-domain.tld/app2/ etc). It's a bit tedious to always have to remember to include the base when linking to a local app path:

<script>
  import { base } from "$app/paths";
</script>

<a href="{base}/local/application/path">Link</a>

Describe the proposed solution

It would be very nice if ~ could be used as syntactic sugar for {base} in the href prop on links, and when using navigation functionality like the SvelteKit provided goto method etc:

<a href="~/local/application/path">Link</a>

One obvious problem with this is that using ~ in routes could cause problems when creating relative links.

Alternatives considered

One alternative is to just create a custom link component:

<script>
  import { base } from "$app/paths";
  
  export let href;
  // other props

  function transformUrl(url) {
    if (!url.startsWith("~")) return url;
    return base + url.slice(1);
  }
</script>

<a href={transformUrl(href)}>
  <slot />
</a>

One disadvantage with this is that you have to handle how to style the anchor tags somehow. And also this doesn't cover things like goto. To fix this, you could just export the transformUrl function and use that directly. However, when you have to write <a href={tranformUrl("~/my/link")}>link</a> you might be better off just sticking to <a href="{base}/application/path">link</a>

I started to look into if you could create a vite plugin for this, but it seems a bit complicated to cover all cases (like goto and links generated through functions etc).

As a side note, we already have %sveltekit.assets%, so adding ~ hopefully wouldn't add that much overhead.

Importance

nice to have

Additional Information

Would make it more aesthetically pleasing and ergonomic to create links, but using {base} works perfectly fine. I also understand that this might lead to undesirable breaking changes for people relying on ~ in their routes, hence might not be worth doing.

Nevertheless, I feel it's worth sharing that having to add {base} to every URL in your app feels kind of awkward.

[oodavid]

On this, I'd love to see other syntactic sugar:

• ~/path - base
• ./path - relative to the current page
• ../path - relative to the parent page

[Rich-Harris]

I don't see a way to make this work if I'm honest. URLs appear in lots of different contexts:

• there's href and src attributes. some are in the template (href="~/blah") and could probably be handled with a preprocessor, but some aren't (href={foo}); for these you'd need cooperation with Svelte itself, which would be finicky and introduce overhead
• what about {@html post.body} where post.body includes <a href="~/blah">?
• there's things like fetch — do we monkey-patch? if not, why not? what if there are things we can't monkey-patch? what constitutes an acceptable level of magic, and how do we draw the boundaries in a non-arbitrary way?
• does this work for CSS too? does that just include <style> in components, or imported .css files? can we make it work reliably whatever CSS preprocessor you're using?

Meanwhile, /~ is a perfectly legitimate route. All told, we're talking about a lot of additional complexity, for very little gain (I'm not sure why remembering to include {base} is more tedious than remember to include ~).

You could try adding <base href="/app1/"> to your src/app.html. Then, any relative links will be relative to that URL rather than the current page URL. There's a known prerendering issue (#8559) but it'll get fixed soon.

@oodavid ./path and ../path already have a clear meaning that's no different in SvelteKit than in any other web development context — I'm not sure I follow?

[oodavid]

@oodavid ./path and ../path already have a clear meaning that's no different in SvelteKit than in any other web development context — I'm not sure I follow?

Oh my, I'd forgotten that behaviour. Somehow feels very 1990.

[Rich-Harris]

Going to close this as it's vanishingly unlikely we'd implement this feature