Dynamic basepath

[Rich-Harris]

Moving this here:

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.

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

paths.base is baked into the app at build time. Changing this would likely need to be done in Vite: vitejs/vite#2009

[antony]

Yeah - this is super critical from my perspective, we have an ever growing range of people who use our main site with branding, and they hate subdomains because it's arguably not as good for SEO. Sapper doesn't support using a sub-path as the root without a totally separate build and deployment.

[Rich-Harris]

Pretty sure we could make it an environment variable

[blackshot]

this is critical for deploying exported static files into github pages because generated urls for custom repos are https://{username}.github.io/{repository} without it assets will be fetched at root level instead of subpath

[Rich-Harris]

@blackshot in those cases, repository is known at build time. Just configure paths.base accordingly. This issue is about cases where the basepath isn't known at build time

[blackshot]

sorry, my bad. i didn't understand it well.

[Rich-Harris]

To recap discussion elsewhere, environment variables solve the white-labelling problem in cases where pages are being server-rendered, but they don't solve the problem in cases where there are no environment variables (e.g. prerendering). For applications like IPFS, we (apparently — I know nothing about IPFS) don't know the basepath until the app is running in the browser.

Presumably we could construct the basepath by subtracting the initial pathname from location.pathname...

<script type="module">
  import { start } from '../../_app/start-xyz123.js';
  const path = '/foo/bar/baz'; // known at render time
  const base = location.pathname.slice(-path.length);

  start({
    target: document.body,
    paths: { base, assets: base || '/.' },
    // ...
  });
</script>

...then if location.pathname is something like /basepath/foo/bar/baz then we know that base is /basepath without needing to include that information in the HTML. Feels brittle but as long as you trust that pages and assets end up in the expected place relative to each other then it ought to work perfectly.

Throwaway thought: this could be useful in the context of i18n, where the basepath is a language identifier like /de or whatever.

[Rich-Harris]

This is affected by the issue described in #1155

[kayakyakr]

Another use case that this breaks is when trying to launch a sveltekit app from a chrome extension. This is a big deal in a content script, especially, where it's trying to preload those links via the embedded page's url.

I'm actually skipping the generated page to run the start script directly, but the module preload still throws a bunch of errors, and all of the css fails to load.

I'm still working out exactly what needs to happen and if there's a workaround, but this is pretty much putting the kibosh on my dreams of running sveltekit from an extension.

[wighawag]

By the way the method @Rich-Harris you describe in your comment is exactly how sveltejs-adapter-ipfs handle it currently :

It inject similar code directly in the html and it works nicely : https://github.com/wighawag/sveltejs-adapter-ipfs/blob/d52856d230796e09e560e183b7b0ddb9d7e08482/lib.js#L115

There are other problem that need to be tackled with to be able to have a static website completely independent of the path it will be hosted on.

For example font generated css currently use absolute path : #1477