feat: support reading Svelte config from vite.config.js/ts#3031
Conversation
We're thinking about getting rid of `svelte.config.js` (or rather, soft-deprecating it): `vite.config.js/ts` is now pretty much the standard for new Svelte apps and generally a better place to put your config. This is an important stepping stone towards that future. `svelte.config.js` was originally introduced for language-tools to read config options, now we can do the same by reading the Vite config. With this PR, `svelte.config.js` is still read first / preferred if both exist, but if non exist but a `vite.config.js/ts` does, we can get the relevant options from it.
🦋 Changeset detectedLatest commit: 0907f4e The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Pete brought up the good point that reading the Svelte config could be moved into its own pkg. |
This allows you to pass the Svelte(Kit) config into the sveltekit Vite
plugin. Example:
```js
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';
import adapter from '@sveltejs/adapter-vercel';
export default defineConfig({
plugins: [
sveltekit({
compilerOptions: {
experimental: {
async: true
}
},
adapter: adapter(),
experimental: {
remoteFunctions: true,
handleRenderingErrors: true
}
})
],
});
```
Note how the `kit` namespace is at the same level as the other top level
entries; this is the only difference to the current `svelte.config.js`
layout.
If you set your options via the plugin, the `svelte.config.js` contents
are ignored, so it's either-or, not a merge.
In SvelteKit 3 we will likely make it a requirement to pass the options
via the Vite plugin instead - one less config file at the cluttered top
level of your project.
Fixes #5485
Because you can tell Vite which config to use this also fixes #13748
Related: sveltejs/language-tools#3031
---------
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: Rich Harris <[email protected]>
…3031) We're thinking about getting rid of `svelte.config.js` (or rather, soft-deprecating it): `vite.config.js/ts` is now pretty much the standard for new Svelte apps and generally a better place to put your config. This is an important stepping stone towards that future. `svelte.config.js` was originally introduced for language-tools to read config options, now we can do the same by reading the Vite config. With this PR, `vite.config.js` is read first / preferred if both exist, but if it does not exist or no options are retrieved through it then `svelte.config.js/ts` is used.
|
Just wanted to point out that this feature caused a major headache for our team. Our top level monorepo vite.config.ts file has extra logic that lets us do special things. This read that file every time when it was previously only run under special top-level conditions (like run the dev servers for all the apps in the monorepo, and proxy connections). We needed a special case so our apps can share a domain to talk between them. By loading this, it stealth ran our mega dev server behind the scenes taking up our resources eventually crashing the box. We've adjusted by renaming the file so your plugin doesnt load it and manually pointing to that file, but FYI you might want to change something here... |
2 participants
We're thinking about getting rid of
svelte.config.js(or rather, soft-deprecating it):vite.config.js/tsis now pretty much the standard for new Svelte apps and generally a better place to put your config.This is an important stepping stone towards that future.
svelte.config.jswas originally introduced for language-tools to read config options, now we can do the same by reading the Vite config.With this PR,
vite.config.jsis read first / preferred if both exist, but if it does not exist or no options are retrieved through it thensvelte.config.js/tsis used.