What does Cypress's component.devServer framework and bundler pair actually do?
answer
- No app to visit, so Cypress builds one
- Two words, one dev server
- Both servers ship in the binary
- It finds your existing bundler config
- Angular and Next.js are webpack-only
basics
~20 sThe framework and bundler pair tells Cypress which dev server to start and how to compile your specs. Cypress boots Vite or webpack on a free port, reuses your project's own bundler config file, and serves the compiled support file and spec.
solid answer
~40 sComponent tests do not visit a running application, so Cypress builds the page itself. `framework` names the UI library, which decides the transforms and presets applied; `bundler` picks which built-in dev server starts — `'vite'` or `'webpack'`, both shipped inside the Cypress binary. At run time Cypress starts that server on a free port, sets `baseUrl` to it, loads the component index HTML, then imports the support file and the spec. Crucially, the pair reuses the build you already have: with no `viteConfig` or `webpackConfig` given, Cypress searches upward from the project root for your `vite.config` or `webpack.config` and merges its own settings on top. React, Vue and Svelte accept either bundler; Angular and Next.js are webpack-only.
go deeper
Know that a Cypress component run needs a devServer block, that it names a framework and a bundler, and that the Launchpad scaffolds it for you during setup.
Explain what the two values select and what Cypress does with them at run time: start a server, set the base URL, load the index page, import the support file and then the spec.
Show that you know the pair reuses your existing bundler config rather than replacing it, and that a bundler or framework major version can break a component run on upgrade.
Have a view on which pair a team standardises on across repositories, and on what a webpack-only framework costs a fleet that has otherwise moved to Vite.
## What the block is for A component run has no application to visit and no server you started yourself, so Cypress has to produce the page under test. `devServer` is therefore a **required** option inside the `component` block — a component run cannot start without it. The object form names two things and Cypress infers the rest: ```js component: { devServer: { framework: 'react', bundler: 'vite' }, } ``` `framework` names the UI library, so Cypress knows which transforms and framework presets to apply. `bundler` names which of the two built-in dev servers to start. Both implementations ship inside the Cypress binary; you do not install `@cypress/vite-dev-server` or `@cypress/webpack-dev-server` yourself. ## What happens when a component run starts 1. Cypress reads `component.devServer` from the config file. 2. It starts the matching dev server — Vite or webpack — on an available port. 3. It sets `baseUrl` to `http://localhost:<port>` for the run. 4. It loads the component index HTML (`cypress/support/component-index.html` unless `indexHtmlFile` says otherwise) and dynamically imports the support file, if one is configured, and then the active spec. 5. Control passes to Cypress, and the spec's mount renders the component into that page. For the rest of the run the dev server has three jobs: compile each spec and the support file with the same transforms your app uses in development (JSX and TSX, single-file components, CSS Modules, path aliases), serve the compiled output over HTTP, and shut down cleanly when the run ends. "The same transforms" is the part that decides whether components look right. A single-file component's `<style>` block, a `.module.css` import, a PostCSS or utility-CSS pipeline and a design-token import are all bundler work, and they only happen under test because the dev server Cypress started does them. Pick the wrong bundler for the project, or point it at a config that lacks the style plugins, and the components mount with markup and no styling — the same symptom as a forgotten import in the support file, arriving from an entirely different direction. ## Which pairs are legal | `framework` | supported `bundler` | note | |---|---|---| | `react` | `vite`, `webpack` | | | `vue` | `vite`, `webpack` | | | `svelte` | `vite`, `webpack` | | | `next` | `webpack` | Cypress applies Next.js-specific webpack presets | | `angular` | `webpack` | accepts an `options.projectConfig` override | A community framework definition — a package named `cypress-ct-*` or `@org/cypress-ct-*` — can also be used as the `framework` value alongside a supported bundler. As of Cypress 16 the version floors moved, and this catches upgrades: the Vite dev server requires Vite 8 or newer (support for Vite 5, 6 and 7 was removed), Angular component testing requires Angular 21 or newer, and Next.js requires 15.0.4 or later on the 15 line, or 16. A suite that was green on the previous major can fail at dev-server start for no reason other than a bundler major version. ## It reuses the build you already have Neither value asks you to restate your build. When `viteConfig` is omitted, Cypress searches upward from the project root for a `vite.config` file — `.ts`, `.js`, `.mjs`, `.cjs`, `.mts` or `.cts` — loads it, and merges its own settings on top: the public path, the spec entry points, file-system allow rules and its own plugins. Webpack works the same way with `webpack.config`, except that for Next.js and Angular a framework preset is applied first. If nothing is found, Cypress stops with an error asking you to add a config file or pass the matching option explicitly. That is why the four-line block the Launchpad scaffolds is all most projects ever need. Your aliases, plugins and CSS pipeline are already described somewhere; this pair points Cypress at them. ## What the pair does not do - **It does not style anything.** Global CSS still has to reach the mount page through `cypress/support/component.js` or the component index HTML. - **It does not read `tsconfig.json` path aliases.** Those are a TypeScript type-checking feature and neither bundler resolves them without a dedicated plugin. - **It does not cover other bundlers.** For anything that is not Vite or webpack, `component.devServer` also accepts a function that starts your own server and returns its `port` and an optional `close` callback. - **It does not make the harness the real page.** The dev server compiles the way your development build does, not the way your production build does. If the pair is missing or the bundler cannot be started, the failure arrives before any test runs and names the config file, which is a useful signal in itself: a component run that dies at startup is a configuration problem, and a component run that starts and then fails every spec identically is usually a compilation or styling problem one layer in.
- What does Cypress do if no vite.config exists and you passed no viteConfig?It stops before running anything and reports that the component `devServer` config is missing a required `viteConfig` property because none could be detected automatically, naming your Cypress config file. The fix is either a discoverable `vite.config` at or above the project root, or an explicit `viteConfig`. Webpack behaves identically with `webpackConfig`.
- When would you use the function form of component.devServer instead of the object form?When the object form cannot express what you need: a bundler that is neither Vite nor webpack, a preview server, or dev-server options the object form does not expose. The function receives the specs, the resolved Cypress config and a `devServerEvents` emitter, and must return a `port` plus an optional `close` callback. It is a rare escape hatch; the object form covers most projects.
saying these in an interview costs you the question
- Thinks Cypress builds the production bundle before a component run
- Says you must install the Vite or webpack dev server package yourself
- Believes the whole bundler config must be restated in the Cypress config
- Claims Angular or Next.js component tests can run on the Vite bundler