Expose resolved viteConfig for 3rd party libraries

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.

[JessicaSachs]

Ahhh. I’m surprised the changes are invasive. This seems like a common problem for tools like Storybook, Cypress, and Vitest.

Our goal is to avoid users having to touch anything on their side. Our current API with all other frameworks in Cypress 10 is to use a single string in a cypress.config.js file.

e.g.

export default defineConfig({
  component: {
    framework: 'svelte'
  }
})

… and that’s it.

I think based on what I’m hearing, you’re suggesting two things:

1. Use a svelte config file as an entry point (I’d probably ship our own which would pull in the user’s at runtime). I don’t mind this!

// node_modules/@cypress/sveltekit-dev-server/svelte.config.js

const userConfig = await findUp('svelte.config.js')
export default {
  // ...userConfig (do deep merging here)
  viteConfig: {
    plugins: [ Cypress() ],
    rollupConfig: {
      /* spec files here */
    },
    optimizeDeps: {
      entries: [ /* spec files here */ ]
    }
  }
}

1. But then you’re suggesting to start it how? Via the CLI? Via a module API? I’m unclear on this part.

// node_modules/@cypress/sveltekit-dev-server/index.js

import { startDev } from 'sveltekit'
const configFilePath = resolve('./svelte.config.js')

const server = startDev({ configFile: configFilePath })
// I need server.close from here so I can cleanly tear down the process,
// but if there's no module API I guess I can figure it out another way.

It sounds like in the worst case I can get comfortable executing from the CLI and tearing down the process from the outside-in.

[benmccann]

Closing as solved by https://github.com/sveltejs/kit/pull/5094. Feedback welcome in https://github.com/sveltejs/kit/issues/5184