In Cypress, which languages can specs be written in, and why is that permanent?

## The runtime decides the language Most browser-test tools sit **outside** the browser. The test process speaks a wire protocol to a driver, the driver speaks to the browser, and because that protocol is language-neutral, a client for it can be written in any language at all. Cypress is not built that way. A Cypress spec is loaded **into the browser** and evaluated there, in the same event loop as the application under test. There is no serialization boundary and no protocol sitting between a command and an element, which is exactly where time-travel debugging and native access to application state come from. It also fixes the language: whatever the browser can execute is the entire set of options, and browsers execute JavaScript. Cypress's own trade-offs guide states it without hedging — the only language it will ever support is the language of the web. That sentence sits under the heading **Permanent trade-offs**, beside the one-browser-at-a-time rule and the single-superdomain rule, and it is deliberately kept apart from a shorter list of *temporary* restrictions the project hopes to address. ## Permanent versus temporary, as the project itself defines them Reading that split correctly is what separates a confident answer from a guess: - **Permanent** — commands run inside the browser, one browser at a time, one superdomain per test, and one language. - **Temporary** — there is no `cy.hover()` command, no native or mobile event support, and iframe switching is limited. A team weighing adoption should price the permanent list as a property of the tool and treat the temporary list as risk that may retire on its own. Waiting for a Java or Python client is waiting for something that was never on a roadmap. ## TypeScript does not add a second language "JavaScript and TypeScript" reads like two languages and is really one. Cypress ships **official type declarations** in its npm package, so `cy` and `Cypress` type-check without a community types package, and TypeScript 5.x, 6.x or 7.x is supported as of Cypress 16. Types are then erased before the spec ever reaches the browser. What TypeScript changes: - Mistakes surface as an editor error rather than as a failing run minutes later. - Editor completion covers every `cy.*` command with its parameters and its documentation. - Specs can import the application's own domain types, so an app-side change propagates into tests. What it does not change: the runtime, the command queue, retry-ability, or the ceiling itself. ## What Cypress 16 changed about accepted files Cypress 16 narrowed the accepted surface rather than widening it. Built-in **CoffeeScript support was removed**: the default `@cypress/webpack-batteries-included-preprocessor` no longer bundles `coffee-loader` or `coffeescript`, and `.coffee` is no longer resolved for spec files, support files, or `cy.fixture()`. A project that must keep it registers Cypress's own `@cypress/webpack-preprocessor` on the `file:preprocessor` node event with its own loader rule, and owns that toolchain from then on. | What Cypress loads | Where the default states it | |---|---| | `.js`, `.jsx`, `.ts`, `.tsx` specs | the default `e2e.specPattern`, `cypress/e2e/**/*.cy.{js,jsx,ts,tsx}` | | JavaScript and TypeScript with no setup | compiled by the bundled preprocessor out of the box | | `.coffee` | nothing — removed in 16, reachable only through your own webpack rule | ## Where non-JavaScript work actually goes The ceiling governs what runs *in the spec*, not what a test can cause to happen. Two commands lead out of the browser: 1. `cy.task()` hands an event name and a JSON-serialisable argument to a handler registered on the `task` node event, which runs in Node — the door to a database seed, a file, or a child process. 2. `cy.request()` makes an HTTP call that Cypress issues from Node rather than from the browser, so it bypasses CORS and never shows up in the browser's network panel — the door to anything that already lives behind an API. Neither makes another language available inside the spec. They move the work to where that language already lives and hand a value back. That is the shape of every honest answer here: the spec stays JavaScript or TypeScript permanently, and the rest of the stack is reached through a door rather than through an import.