Relative paths considered relative to the current url (differs from Sapper behaviour)

[antony]

Porting the hackernews app I have found that:

From the ask page, hitting the ask navigation link:

<li><a rel="prefetch" class='{segment === "ask" ? "selected" : ""}' href='ask/1'>ask</a></li>

in Sapper - visits the /ask/1 page
In Svelte App - visits /ask/ask/1 page (which 404s)

I'm assuming this has something to do with baseUrl.

Note that in line with the thinking in #16 - we recently made this change to baseUrl which should be considered sveltejs/sapper#1562

This also isn't specific to hrefs since I've noticed that from the ask page, all references to static assets are attempting to be loaded under the /ask/ path.

[Conduitry]

Being able to not have a baseurl is something that people have been asking for in Sapper for a long time, and there is an old PR for it. My main concern with all of this is how to deal with trailing slashes in URLs, as routes will match either with or without one, and which way you happened to have visited the current page will affect how all URLs are resolved. I don't have a good answer to this, which is probably one of the main reasons this feature has stalled.

If we don't want to sort this out now, we should probably follow Sapper's behavior for the time being, as much as that will disappoint certain people.

[Rich-Harris]

Yeah, I hadn't got round to implementing baseUrl yet and was quite enjoying relative URLs in the meantime.

I think I might know the answer though: can we have a baseUrl per page? So if the app-level baseUrl is '', then if you're on /foo/bar or /foo/bar/ or /foo/bar/index.html the baseUrl is always /foo/bar. This gets written into the page as <base href="/foo/bar"> and is updated by the client-side router upon navigation.

This would be a substantial departure from Sapper's current behaviour, but it seems like it would be a popular one.

Relatedly, I changed the behaviour of this.fetch slightly — it will now resolve URLs relative to the URL of the requested page.

[Conduitry]

There are always going to be some pages where you'd prefer the baseurl to have there trailing slash and some where you'd prefer it didn't, though. (Depending on whether there are nested URLs under this one, say.) Are we okay saying that it'd always work the same way? Is there a reasonable way to make this configurable?

[Rich-Harris]

In order of my personal preference:

1. Figure out the behaviour that solves 99% of cases and implement that (trailing slashes for non-leaf routes?)
2. Add an option to svelte.config.js (trailingSlashes: 'always' | 'never' | 'auto')
3. Some regex-driven monstrosity for customising on a per-route basis

It does get a little tricky though as you need to start documenting the difference between visible and invisible trailing slashes (e.g. https://my.site/blog looks nicer than https://my.site/blog/, but you probably want the trailing slash in the baseURI so that the page can contain links like <a href="my-first-post">)

Man, I dunno. This stuff is complicated

[antony]

One blocking issue I've run into with the current Sapper is that I can't rewrite urls from various sites that we want to host a "whitelabel" version of our app on, because the basepath has to be set in stone at build time:

https://example.com/some-path/ <-- does not work
https://subdomain.example.com/ <-- works fine

rather than host a different app for people who want to mount it under a subpath, ideally basepath could be a runtime concern. However I don't know if this is feasible, but it's worth considering.

[antony]

A note about why dynamic basepaths (or non-present basepaths) are useful from a discord user (ronan (wighawag)):

Cool. For me it is to support ipfs website both when served through an ENS domain or through a gateway with ipfs/ base path
for example, both url point to the same exact content : https://ipfs.io/ipfs/bafybeieeuq3av6jdys2q2zwhfv5hutcqejczr46wzjikd5vulfaxfi72r4/
https://jolly-roger.eth.link/
for the hash version, I have to compute at runtime the basepath since it is not possible to know the hash of an ipfs website at build time

https://ptb.discord.com/channels/457912077277855764/750388563354583071/771786495152357386

[Rich-Harris]

This is really two separate issues — #192, which we decided to close for now, and #595 which I'll close this in favour of