kit icon indicating copy to clipboard operation
kit copied to clipboard

allow passing inline options to `kit()` in vite config

Open dominikg opened this issue 1 year ago • 3 comments

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

dominikg avatar Jul 12 '22 21:07 dominikg

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

dominikg avatar Jul 13 '22 05:07 dominikg

Is there some usecase or motivation for this?

I have a few reservations:

  • it would split the config across two files: svelte.config.js and vite.config.js. It makes it harder to understand a project's configuration compared to now where it's all in svelte.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 in svelte.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

benmccann avatar Nov 20 '22 15:11 benmccann

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:

dominikg avatar Nov 20 '22 16:11 dominikg

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).

wvhulle avatar Feb 07 '23 09:02 wvhulle