How far should Cypress's component support matrix drive a design system's upgrades?

Adopting Cypress Component Testing quietly couples two release calendars: your framework's and Cypress's. The `component.devServer` matrix is not advisory — an unsupported framework or bundler version has no dev server behind it, so the component run does not start. That makes the matrix a standing constraint on when your design system may upgrade, and when it must. ## What Cypress 16 actually demanded The component-testing half of the 16 release moved three floors at once: - **Vite 5, 6 and 7 support removed.** The Vite dev server requires Vite 8, and any `@vitejs/*` plugin pinned to an older major has to move with it. - **Angular 18, 19 and 20 support removed.** The minimum is Angular 21; Angular 22 is also supported. `cypress/angular-zoneless` merged into `cypress/angular`, zoneless became the default harness, `@angular/platform-browser-dynamic` gave way to `@angular/platform-browser`, and `autoSpyOutputs` and `autoDetectChanges` were removed from the mount API. - **Next.js 14 support removed.** Next.js 15.0.4 or 16 is required. None of those is a test-code change you can grep for. They are dependency-tree changes, which is why a runner upgrade can turn into a framework upgrade that turns into a plugin upgrade. ## The two failure modes, and why neither is free **Track the matrix.** You upgrade the framework whenever the runner demands it. The cost is that a test tool now sets the pace of your production dependency upgrades, and a Cypress release can land a framework migration on the design system's roadmap that nobody planned. **Pin the runner.** You stay on the older Cypress major and upgrade the framework on your own schedule. The cost compounds quietly: you forgo every later fix and performance change, the pinned version's browser support ages out from under you, and each deferred major makes the eventual jump larger and less reversible. | | Track the matrix | Pin the runner | | --- | --- | --- | | Who sets upgrade timing | the runner | the team | | Framework migrations | forced, on the runner's cadence | deferred | | Runner fixes and performance | current | frozen | | Risk shape | many small, scheduled jumps | one large, unscheduled jump | | Reversibility | high | falls over time | ## How to actually decide The useful question is not "should we upgrade?" but "which direction of coupling costs less **for this codebase**?" A few things move the answer: 1. **How much of the suite is component tests.** If component tests are a small share and the rest is end-to-end, the matrix constrains a small part of your coverage and pinning is cheap. If a design system's entire quality signal is component tests, a stalled runner stalls everything. 2. **How close you already are.** A team on Angular 20 and Vite 7 is one deliberate quarter away from Cypress 16. A team on Angular 18 is looking at a multi-major migration triggered by a test tool, which is a different conversation. 3. **Whether the framework upgrade was coming anyway.** If the security and support horizon on your framework major is closing regardless, the runner is not creating work — it is surfacing work you already owed. 4. **How much the new major buys you.** A release full of run-time and flake improvements repays a migration differently from one that only removes deprecated options. ## The position worth defending A defensible answer usually has this shape: - **Track the matrix by default.** Treat a supported-version floor as a normal dependency constraint and keep the framework inside the window. This is the cheap steady state. - **Allow pinning as a dated pause, never as a policy.** A pin needs a named owner, a written reason and a date, exactly as a quarantined test does — otherwise it becomes the permanent state nobody decided on. - **Refuse to let the runner drive a framework migration you would not otherwise do.** If Cypress 16 is asking for an Angular jump that is genuinely wrong this quarter, pin deliberately, and say so, rather than shipping a rushed framework migration to keep a test suite green. - **Know your exit.** Be able to say what happens if you cannot follow the matrix — which components can be covered by a cheaper runner, and what confidence that trades away. ## The thing to say out loud The matrix is a real cost of this tool, and it is a cost that grows with how much of your quality signal rides on component tests. Naming that trade honestly — rather than treating every upgrade as routine housekeeping or every pin as prudence — is the answer an interviewer is looking for.