Describe the problem

Tools like Vitest, Cypress, and Storybook want to support SvelteKit. These projects need to bundle components that users write in their SvelteKit apps and need a programmatic API to kick off static bundling or serving the app's dev server. To ensure that the code that's being tested and rendered behaves like it will in production, it's critical to use the user's resolved build configuration instead of making them "eject" and re-define all of the compilation options.

Describe the proposed solution

Meta build-tools like CRACO, CRA, Vue CLI, Next.js, and Nuxt.js all provide ways to access the underlying, "compiled" Webpack configurations used to build and bundle the application's source code. These APIs allow 3rd party libraries like Vitest and Cypress to ingest the user's build configuration and then compile their code in a different context than that of the SvelteKit (or Nuxt, etc) framework.

Getting the Config and Merging it in w/ Vite

Static API

import { getResolvedConfig } from '@sveltejs/kit'

Merging w/ vite

import { mergeConfig, createServer } from 'vite'
import { getResolvedConfig } from '@sveltejs/kit'

const viteConfigOverrides = {
  plugins: [
    Cypress(), // Mount all of the components as pages and add routing
    // or Vitest's mocking plugin, enabling ESM mocks
    // Mocks()
  ]
}

const finalConfig = mergeConfig(getResovledConfig(), viteConfigOverrides)
const server = await createServer(finalConfig) // or otherwise compile + ingest the build configuration

Alternatives considered

You could also re-export/otherwise wrap Vite's createServer and mergeConfig methods. This would make dependency management less of a pain, but I'm not asking for it because I think it's possible to meet the needs for Cy and Vitest without this API.

Dev Server API

import { createServer } from '@sveltejs/kit' // passes through to Vite

Importance

i cannot use SvelteKit without it

Additional Information

This is critical for Cypress to release official Svelte support for Component Testing Svelte apps. We could hardcode build configurations for users, but we don't feel comfortable doing that because they will diverge from the user's production setup and may allow for prod-only bugs to be released.