Which frameworks and bundlers does Cypress 16 support for component tests?

Cypress Component Testing does not render your component through a generic adapter. Every UI framework gets its own **mount library**, shipped inside the `cypress` package itself, and every pairing of framework with bundler is a combination Cypress explicitly builds, tests and version-pins. The list is short, it is versioned, and it moves at every major release. So "does Cypress support my stack?" is really two questions: is my framework on the list at all, and is the version I run inside the supported range? ## The Cypress 16 matrix | Framework | UI library version | Bundler | | --- | --- | --- | | React with Vite | React 18-19 | Vite 8 | | React with Webpack | React 18-19 | Webpack 5 | | Next.js 15-16 | React 18-19 | Webpack 5 | | Vue with Vite | Vue 3 | Vite 8 | | Vue with Webpack | Vue 3 | Webpack 5 | | Angular | Angular 21-22 | Webpack 5 | | Svelte with Vite (alpha) | Svelte 5 | Vite 8 | | Svelte with Webpack (alpha) | Svelte 5 | Webpack 5 | Three things in that grid are easy to skim past: - **There are exactly two bundlers.** `component.devServer.bundler` accepts `'vite'` or `'webpack'` and nothing else. Cypress ships a Vite dev server and a Webpack dev server inside the binary; there is no Rollup, esbuild, Parcel or Rspack option to select. - **Not every framework offers both.** `framework: 'angular'` and `framework: 'next'` are Webpack-only. React, Vue and Svelte accept either bundler. - **Svelte is alpha.** Cypress grades each integration `alpha`, `beta`, `full` or `community`. React, Vue, Angular and Next.js are `full`; Svelte is `alpha`, which means its mount API can still change between releases. ## What you import, and what it is called The `framework` string in your config and the module you import are deliberately different names: - `framework: 'react'` and `framework: 'next'` both mount through `cypress/react`. - `framework: 'vue'` mounts through `cypress/vue`. - `framework: 'angular'` mounts through `cypress/angular`. - `framework: 'svelte'` mounts through `cypress/svelte`. None of those modules is a separate npm install. They ride inside the `cypress` package, as do the two dev servers, which is why a component project's `package.json` usually lists only `cypress` plus your own framework and bundler. What you do install is the framework itself at a supported version — that is the half Cypress cannot supply. ## Off the list: community and unsupported Two integrations exist as community plugins rather than Cypress-shipped values: Qwik and Lit, both on Vite. They are maintained outside the Cypress repository, so they follow their own release cadence and are not covered by the matrix above. Everything else — Solid, Ember, Lit without that plugin, a hand-rolled web-component library — has no Cypress mount library at all. That is a real constraint on a design system. If your rating widget, data grid and toast are published as framework-agnostic web components, there is no first-party `cypress/*` mount for them; you mount them by rendering the custom element into the page yourself and driving it with ordinary Cypress commands, which works but gives you none of the framework-aware conveniences. ## Why the ranges are narrow, and why they move A mount library is not a thin wrapper. It has to create the framework's root, apply props, drive its change-detection or reconciliation model, and tear the tree down between tests — all against internal APIs that shift between framework majors. Cypress therefore supports a window rather than a floor, and each major release moves the window: 1. Cypress 16 removed Angular 18, 19 and 20; the minimum is now Angular 21, and Angular 22 is supported. 2. Cypress 16 removed Vite 5, 6 and 7 for the Vite dev server; the minimum is Vite 8. 3. Cypress 16 removed Next.js 14; Next.js 15.0.4 or 16 is required. The practical consequence is that "we use Cypress for component tests" is a statement about your framework and bundler versions too. Before you promise a team component coverage, check the matrix against the versions actually in the repository — not against the version you remember, and not against a blog post written for an earlier Cypress major. ## Checking your own project The Cypress Launchpad detects your framework and bundler on first run and lists the dependencies it needs, flagging any that are missing or below the supported range. That wizard is the fastest honest answer to "will this work here": if it reports a version below the floor, the answer is that you upgrade the framework first and add component tests second. Reading the matrix yourself is the same check done ahead of time, which is what an interviewer is usually probing for.