-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Paths #229
Comments
I did wonder if import { basePath, staticPath } from '$app/env'; ...is arguably somewhat nicer than this: const basePath = import.meta.env.SNOWPACK_PUBLIC_BASEPATH;
const staticPath = import.meta.env.SNOWPACK_PUBLIC_STATICPATH; In fact I now think we should probably put all env-related stuff in there: import {
basePath,
staticPath,
assetPath, // not that you'd ever need this one
browser, // boolean
dev // boolean
} from '$app/env'; |
Ugh I just realised that module.exports = {
// TODO adapterless builds
adapter: '@sveltejs/adapter-node',
paths: {
static: 'public',
routes: 'source/pages',
template: 'source/template.html'
},
target: '#content-goes-here',
// this creates `window.start` which starts the app, instead of
// it starting automatically — allows test runner to control
// when hydration occurs
startGlobal: 'start'
};
|
General note: I think it would be better to have all svelte-kit related config within a property called |
Yeah, I reluctantly agree. maybe Thought about the shape of this a little more and I'm now in favour of this: module.exports = {
kitOptions: {
// renamed from current 'paths'
files: {
static: 'public',
routes: 'source/pages',
template: 'source/template.html'
},
// this maps to `$app/paths`, e.g.
// import * as paths from '$app/paths';
// console.log(paths.base, paths.static);
paths: {
base: basePath: '/subdirectory',
static: '/static-assets', // *not* relative to `/subdirectory`, because leading `/`
assets: 'svelte-kit-stuff' // *is* relative to `/static-assets`, i.e. `/static-assets/svelte-kit-stuff`
}
}
}; It's annoying that import * as paths from '$app/paths';
console.log(paths.static); rather than import { static } from '$app/paths';
console.log(static); but c'est la vie. Any feedback before i go ahead and implement this? |
Have we considered being able to pass in these paths at runtime in addition to/ instead of reading from config at build time? Specifically the |
I hadn't, no. What's the use case? |
Microfrontends is my main usecase (I'll create an issue for this, explaining what we'd need to support that usecase, it isn't a lot really). But a frontend that had internal routing doesn't know where it will live (the Another use case is is deploy previews for pull requests (although this could be solved in other ways). In the case of static apps you may use a single url for these kinds of deploys. |
Instead of I also somewhat wonder if it should be |
Yeah, I like |
We need to support at least two, maybe three, path configurations:
basePath
that is used for routing, so that a request for/foo/bar
on a site with abasePath
of/foo
is handled by the/bar
route. It defaults to''
staticPath
for static assets, in cases where assets are deployed to somewhere other than the site itself. It defaults to''
and is resolved againstbasePath
, meaning thathttps://example.com/my/things/and/stuff
,/my/things/and/stuff
andmy/things/and/stuff
would all be valid (and would resolve to the same thing in the case where the app was deployed tohttps://example.com
and had an emptybasePath
).assetPath
for generated assets, which might conceivably need to live somewhere other than alongside regular static assets. This defaults to'_app'
(🐃 ) and is resolved againststaticPath
.All these values would be declared the config file:
Given the problems they caused in Sapper, we should probably try and avoid relying on
<base>
elements (I quite like the idea of per-page<base>
elements to normalise between/foo
and/foo/
, but they do cause merry havoc with things like SVGurl(...)
properties). In other words, if something needs to usebasePath
, it should presumably be importable from somewhere. I propose$app/env
:Similarly,
staticPath
would be available to JS modules and components:If the stars align, these constants will get folded into the source code.
One thing I haven't thought about is whether CSS should be able to access these values somehow. But I don't feel like solving that problem right now.
Any thoughts?
The text was updated successfully, but these errors were encountered: