kit
kit copied to clipboard
allow passing inline options to `kit()` in vite config
Describe the problem
It is common for vite plugins to offer config options via first parameter to the initializer function. With svelte-kit you currently have to define all options in svelte.config.js, even those for vite-plugin-svelte that are very vite specific.
To allow for a more logical grouping (vite related options in vite.config.js, svelte related options in svelte.config.js) it would be great if this was possible for kit as well.
Describe the proposed solution
export default defineConfig({
plugins:[kit({
...kit_config,
vitePluginSvelte: {... vite plugin svelte options}
})]
})
the kit config gets merged with the values from svelte.config.js and vitePluginSvelte is passed to the initializer function of v-p-s.
Alternatives considered
keep it as is.
Importance
nice to have
Additional Information
with the next release, vite-plugin-svelte is going to change the location for it's options in svelte.config.js to vitePlugin
. https://github.com/sveltejs/vite-plugin-svelte/pull/389
to be able to avoid setting kit options in svelte.config.js
we need to come up with a way how vite-plugin-svelte can get the value for kit.browser.hydrate
as it currently reads that and sets compilerOptions accordingly.
svelte-inspector uses outDir to find the default inject script
Is there some usecase or motivation for this?
I have a few reservations:
- it would split the config across two files:
svelte.config.js
andvite.config.js
. It makes it harder to understand a project's configuration compared to now where it's all insvelte.config.js
- it may create trouble using tools like Vitest or Storybook. E.g. Storybook will not use the svelte plugin defined in
vite.config.js
directly but will read the options insvelte.config.js
to create its own instance. If you start setting options elsewhere it's going to break it and I'm not sure what the fix is - the function creates multiple plugins. We'd have to implement this in a way that would allow configuring multiple of them - maybe we'd only need to allow users to configure one for now, but it would at least be extensible. I like that it's an implementation detail hidden from users. but if we let them configure the plugins we might have to open that up a bit
- we might want to pass other options in the future such as which plugins to enable or include (or disable / not include). if we include options now it somewhat ties our hands in terms of future API. if we leave the function as taking no options for the time being then we can add any sort of options object we want in the future
i opened this primarily to align with general vite plugin usage where options are allowed to be passed inline. And as kit hides vite-plugin-svelte from users, they won't be able to use it's inline options otherwise.
Another reason was to avoid the duplicate svelte config read by using configFile: false
and passing in merged inline options.
But that can also be resolved with using https://github.com/sveltejs/vite-plugin-svelte/blob/main/packages/vite-plugin-svelte/src/index.ts#L238 :thinking:
I also need this because I generate a new build directory for adapter node and this build directory path has to be written and read from a metafile now. It would be more user friendly to do everything all at once through vite (or InlineConfig options passed to a call of its build and createServer functions).