How to Move SvelteKit Config into vite.config.js (July 2026)

#node #javascript #ai #webdev

I saw the July 2026 Svelte blog post and it immediately clicked for me: the long‑standing svelte.config.js file can now live inside the Vite configuration. As someone who maintains several SvelteKit apps, that change feels like a real productivity boost, especially when you’re already juggling Vite plugins, environment variables, and custom build steps. In this post I’ll walk through why the shift matters, show the exact code you need to adopt, and discuss the practical trade‑offs before you decide to upgrade.

Why this change matters right now

SvelteKit has always been built on top of Vite, but the two configs lived in separate files:

├─ vite.config.js
├─ svelte.config.js   ← Svelte‑specific settings
└─ src/

That split caused a few friction points:

Duplicate context – Both files expose a defineConfig wrapper, so you end up repeating import { sveltekit } from '@sveltejs/kit/vite' and then merging options manually.
Order‑sensitive plugins – Some Vite plugins need to run before SvelteKit’s own plugin, but the only reliable way to guarantee order was to edit vite.config.js and then remember to keep svelte.config.js in sync.
Tooling confusion – IDEs and type‑checkers sometimes struggle to infer the final shape of the combined config, leading to false‑positive warnings.

The July 2026 release (SvelteKit 2.0) removes the need for a separate svelte.config.js. By exporting a kit key inside vite.config.js, the framework can read its own configuration directly from Vite’s config object. This means a single source of truth for everything that touches the build pipeline.

The old way – a quick refresher

If you’re still on a pre‑July 2026 version, your project likely looks like this:

// svelte.config.js
import adapter from '@sveltejs/adapter-auto';
import preprocess from 'svelte-preprocess';

export default {
  kit: {
    adapter: adapter(),
    // other SvelteKit‑specific options
  },
  preprocess: preprocess()
};

// vite.config.js
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';

export default defineConfig({
  plugins: [sveltekit()],
  // Vite‑only options here
});

Every time you add a Vite plugin that must run before SvelteKit, you have to tinker with the plugins array order, and you still need to keep the two config files in sync for things like alias resolution.

The new approach – everything in `vite.config.js`

Starting with SvelteKit 2.0 (July 2026), you can drop svelte.config.js entirely and embed the kit configuration under the sveltekit key inside Vite’s config. Here’s a minimal example:

// vite.config.js
import { defineConfig } from 'vite';
import { sveltekit } from '@sveltejs/kit/vite';
import adapter from '@sveltejs/adapter-auto';
import preprocess from 'svelte-preprocess';
import eslintPlugin from 'vite-plugin-eslint';

export default defineConfig({
  plugins: [
    // SvelteKit must stay first unless you have a reason to reorder
    sveltekit({
      // <-- SvelteKit‑specific options go here
      kit: {
        adapter: adapter(),
        // any other kit options (paths, prerender, etc.)
      },
      preprocess: preprocess()
    }),
    // Vite‑only plugins follow
    eslintPlugin()
  ],

  // Vite‑level config (aliases, server, etc.) stays as usual
  resolve: {
    alias: {
      $components: '/src/lib/components'
    }
  }
});

A few things to note:

The sveltekit function now accepts an object that mirrors the old svelte.config.js shape (kit, preprocess, etc.).
You still import the same adapters and preprocessors; nothing changes under the hood.
All Vite plugins live in the same plugins array, so ordering is explicit and obvious.

If you already have a svelte.config.js, simply copy its exported object into the sveltekit({ … }) call and delete the file. Vite will pick up the merged configuration automatically.

Step‑by‑step migration checklist

Upgrade to SvelteKit 2.0

   npm i -D @sveltejs/kit@2.0 vite@5.0

(Both packages are released together, so the peer dependency alignment is safe.)

Remove svelte.config.js – Back it up first, just in case.
Add the kit block to vite.config.js – Use the snippet above as a template.

If you have custom Vite plugins that previously referenced svelte.config.js, adjust the import paths accordingly.
Run the dev server – npm run dev. The CLI will now report that it is reading configuration from vite.config.js.
Verify build output – npm run build. The generated build/ folder should be identical to the pre‑upgrade version, assuming you haven’t changed any other options.
Update CI scripts – If your CI pipeline explicitly copies svelte.config.js into a Docker image or caches it, remove that step.

What else is new in July 2026?

While the config merge is the headline, the same release also introduced a few related improvements that make the change feel natural:

Typed Vite config for SvelteKit – The sveltekit helper now returns a fully typed UserConfig object, so TypeScript users get autocomplete for both Vite and SvelteKit options in the same file.
Improved error messages – If you accidentally place kit options outside the sveltekit({ … }) call, the dev server throws a clear “SvelteKit config must be passed to the sveltekit plugin” error.
Better SSR handling – The new config path aligns with Vite’s SSR entry points, making it easier to add custom server middleware without a second config file.

These tweaks are incremental, but they reinforce the idea that SvelteKit is now a first‑class Vite plugin rather than a sibling framework.

My personal take: upgrade or not?

From a day‑to‑day perspective, consolidating the two config files reduces mental overhead. I no longer have to open two files to add a new alias or to tweak a Vite plugin order; everything lives where Vite already expects it. The migration is straightforward—just copy‑paste the old kit object into the sveltekit call—and there are no breaking runtime changes.

The only trade‑off is that you now have a single point of failure: a typo in vite.config.js can break both Vite and SvelteKit simultaneously. That risk is mitigated by