-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic basepath #595
Comments
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. |
Pretty sure we could make it an environment variable |
this is critical for deploying exported static files into github pages because generated urls for custom repos are |
@blackshot in those cases, |
sorry, my bad. i didn't understand it well. |
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 <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 Throwaway thought: this could be useful in the context of i18n, where the basepath is a language identifier like |
This is affected by the issue described in #1155 |
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. |
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 |
I updated my ipfs adapter repo with link to the various issues in svelte kit, it describe what is missing in svelte-kit for proper support of ipfs (and other hosting platform that require basepath to be dynamic) : https://github.com/wighawag/sveltejs-adapter-ipfs It currentl implements the solutions as a post-process steps and so it is currently very brittle. I also setup a demo repo that uses the adapter succesfully : https://github.com/wighawag/sveltekit-ipfs-demo |
But then I cannot do |
My application is a prerendered site which is deployed on a webspace at my Uni. I guess a solution for me could be what @KonradHoeffner is doing plus somehow checking for dev vs. prod and then prepend base depending on that. |
No its perfectly reasonable. I made a start but work got in the way. I hope to pick it up again as soon as I can.
|
I have the exact same problem now. i am just trying to deploy a svelte kit app with adapter-node to mydomain.com/svelteapp and unfortunately all links are broken. is this here the correct ticket however for that? because as far as i understand it, this ticket goes further and wants to fix dynamic basepath during rendering, whereas this problem i am facing is merely lack of considering the base path in the router when navigating. |
I wanted to get the dev server and the uploaded build to work in the setup for my university-project. import adapter_static from '@sveltejs/adapter-static';
import preprocess from 'svelte-preprocess';
import path from 'path';
const dev = process.env.NODE_ENV == 'development';
const base = dev ? '' : '/path/on/server';
/** @type {import('@sveltejs/kit').Config} */
const config = {
preprocess: preprocess(),
kit: {
adapter: adapter_static({
// default options are shown
pages: 'build',
assets: 'build',
fallback: null
}),
target: '#svelte',
paths: {
base: base
}
}
}
export default config; Then I import base from other components/pages and prefix my links with it. This works, if I remember to set it on all the links: <script lang="ts">
import { auth } from '$lib/stores.js';
import { goto } from '$app/navigation';
import { onMount } from "svelte";
import { base } from '$app/paths'
onMount(() => {
if (!$auth) {
console.log("Not authenticated, going back to login.")
goto(base + '/login');
}
})
// or like so:
<RoundButton link={base + '/banking'} name={'SEND BUCKS'}/>
</script> Like I said, I'm not sure I'm qualified really to discuss this stuff, but just saying this works for me if anyone else is looking for a workaround and finds this. |
@johannesrave of course for programmaticaly invoking the navigation it works and is one workaround. however all static links like |
I absolutely agree, I'm just glad it's running for the moment :P Also there are two things in this, I think. EDIT: Spent another few hours down that rabbithole. The When I manually move it to the top (in the browser inspector!) the links show up right on hover, including the correct domain path. When moving the element up in the generated html in It's been pretty fruitless, and I'll stop trying to work on this at the root and just go with my silly prepended hrefs until someone qualified fixes this in a release. |
Came here when realizing I need to prefix all URLs with '/static/' or replace '/./' with '/static/' for using SvelteKit builds with Python (with the Flask framework). I put static assets in static/static/ in the SvelteKit app dir to get those right at least (so those will resolve to mydomain.com/static/... after build). But I need to customize the other URLs for prod builds. I know this issue is about dynamically handling basepath during runtime, but hoping to at least have static basepath configurable at some point |
Trying to deploy a SPA to arweave, similar to IPFS, having to prepend Worth noting here, arweave is a protocol for permanent storage, once you upload a file it's there permanently. It provides the foundation for something called the 'permaweb'. Files are submitted with transactions whose transaction id is a hash of the transactions fields. The transaction id ultimately becomes the basepath when the file is hosted, but once you know what that id is, you can't go back and edit your files to include it without violating the hash. It's a chicken and egg thing. 🥚 🐔 So from a transaction id:
...where the transaction id becomes part of the basepath. It would be great to be able to host Svelte SPAs without having to specify a base path explicitly ahead of time to support the "developing permaweb SPAs on arweave" usecase. 👍 Edit: I was able to use @wighawag 's |
not fully caught up on this thread but wanted to add a further thought: apps that expect the basepath to be something specific are liable to break when they're archived. The Wayback Machine has URLs like https://web.archive.org/web/20200331000251/https://www.yoursite.com/, and naturally that causes stuff to break. I've been bitten by this today (though not by a SvelteKit app). If you're doing SSR that's not necessarily catastrophic — it means that the router won't fire, but hopefully at least your content and styles will behave correctly. But it'd be a hell of a lot better for future historians if client-side routers were designed with portability in mind. |
I think, at least for the assets it is very important to be able to set the base path to CDN during runtime. Keeping CDN url in the envs/package.json is suboptimal to say the least, especially when you have multiple environments to deploy to (qa, staging, prod), because you have to suddenly have 3 envs in your repo AND build three times to deploy to them. Which is a waste of CI time and dev time, on waiting (ergo, money). Example from webpack usage is also a very concise one: webpack.config.js
Template:
|
You can already set the cdn/assets url in sveltekit config. This is about basepath which relates to the path which the application itself runs from.
Setting things on the window object is fine for clientside but won't solve SSR, so the we pack solution you posted won't work for sveltekit. I'm not 100% sure how secure it is either - it strikes me that loading a malicious clientside app might be made trivial by overriding this variable?
|
I have the use case where it is not known at build time. |
In that case, I think it should be made available in the html (via the base tag) by whoever deploys the site and the framework should pick it up. The way to pick it up is probably not by looking up the presence of Which means in the example of the waybackmachine, they should make sure to modify/include the proper base before serving the html. Am I mistaken? |
@benmccann Thanks for looking into it. I did not yet found the time to update the ipfs-adapter for 1.0 but I just got the basic demo setup with an ipfs node emulator to showcase the issues. https://github.com/bug-reproduction/svelte-kit-static-ipfs Note though that this only highlight some of the issues as more complex scenario will likely exhibit more |
For anyone struggling to find a workaround, I've had a little luck with using the static adapter and an empty base path. I can't get sveltekit's routing to work, but I can use a different client-side router. In svelte.config.js (among other config settings) -
and in the outer +layout.ts
With IPFS, the base folder name is the "content identifier" and based on a hash of the site contents. So you don't know it until after build. But... you do know that it is going to be one-level deep and follow a certain pattern. I can use a regex pattern in my top level layout to extract the base path from the window.location and then use that to set up the client-side routing. Maybe an adapter could do something similar with a regex pattern and get sveltekit's router working. Maybe it could inject a top-level runtime request handler that determines the base path and makes it available in [Edit: some of the ideas in #8559 around setting base combined with optional route parameters / rest parameters seem like they could solve this use case and allow using sveltekit routing] |
hi @rmarscher, thanks for chiming in I just tried adding Re adapter, have a look at the adapter I created here : https://github.com/wighawag/sveltejs-adapter-ipfs It is now quite old and might be outdated to work with v1 but it perform the IPFS base path extraction you mention and inject it. My next step is to figure out what of the processing step I can remove now that svelte-kit is in v1. |
Just some update after trying to get sveltejs-adapter-ipfs works with v1 While I can continue to inject the base at runtime and have routing works with IPFS, I get issues with EDIT: I updated the demo to showcase the issue with I think this demo cover most of the issues. I ll try to isolate more if I can find (I tried the service worker and seems that sveltekit v1 handles them better now, even with the builtin registration) I could try to get around the issues again with my Let use this demo as a first benchmark to achieve. you can play with it here by the way: Work fine when on the root: https://bafybeia5gowaldvs5mwxdr2wbq7a2ssrwjsapkevy5xlmn2khu3luczkjm.ipfs.dweb.link/ Does not work on a path: https://cloudflare-ipfs.com/ipfs/bafybeia5gowaldvs5mwxdr2wbq7a2ssrwjsapkevy5xlmn2khu3luczkjm/ |
I continued my effort and got my adapter working with sveltekit 1.0 again But note that it is not full proof. I documented what svelte kit need to fix in details here : https://github.com/bug-reproduction/svelte-kit-static-ipfs/tree/fixes#fixes I am not familiar with sveltekit code base to fix it myself but more than happy to help |
Thanks @wighawag for the PR! I'm not sure if there's anything left to be done or if this issue should be closed. Please let me know. Thanks! |
@wighawag a true champion 🙇♂️ |
Going to go ahead and close this issue — if there are bits that we've missed, please open new ones! |
Thanks @Rich-Harris and @benmccann for implementing it! This is a really cool feature for a framework like sveltekit to have.
@DanMacDonald if you look at the commit history my contribution was minuscule but happy to be part of it :) |
Not just recent commits, your static-adapter for IPFS was also a big help. 🍻 |
@benmccann It appears that this issue has been disrupted by the solution introduced in issue #2958. Specifically, when using a reverse-proxy with a path such as |
@janabimustafa I don't have a good grasp of your issue, but please open a new bug/feature request as appropriate. A comment on a long-running closed issue like this will easily get lost. |
I read through this thread and the linked docs at https://kit.svelte.dev/docs/configuration#paths, but I don't think this solves my problem. My problem is that I want to deploy my site on a dynamic subdirectory. For example I would like to deploy the site at This may seem like a niche issue, but I am not the only one having it (https://www.reddit.com/r/sveltejs/comments/vd4qcu/how_to_run_svelte_app_from_unknown_sub_directory/). Ideally I would like to express to svelte to ignore the first two paths Maybe the |
@msdrigg what is your issue exactly ? I have my website work with it on ipfs : |
Okay relative paths solved my issue. I was still having an issue due to #10235 Thank you for pointing me to your source I could reference. |
Moving this here:
paths.base
is baked into the app at build time. Changing this would likely need to be done in Vite: vitejs/vite#2009The text was updated successfully, but these errors were encountered: