Cypress Dependencies: Complete Guide to the Monorepo's External Packages

Cypress uses a Yarn 1 workspace structure where all external dependencies are declared as devDependencies in the root package.json, while individual workspace packages manage their own runtime dependencies.

The Cypress testing framework is organized as a monorepo containing dozens of interconnected packages—from the CLI entry point to the browser driver, Electron app, and component-testing adapters. Understanding how Cypress handles dependencies is essential for contributors, maintainers, and advanced users who want to extend or debug the tool.

How Cypress Manages Dependencies

The root package.json in cypress-io/cypress contains no dependencies field. Instead, it declares roughly 95 devDependencies used across the entire workspace. These packages are hoisted by Yarn 1 and made available to all sub-packages.

Individual workspace packages—located in packages/ and npm/ directories—declare their own runtime dependencies in separate package.json files. This separation keeps the root manifest clean while allowing fine-grained control per component.

Root devDependencies by Category

Build and Binary Packaging

Cypress distributes an Electron-based desktop application. The root package.json includes:

• electron (37.6.0) — Core runtime for the Cypress desktop app
• electron-builder (^25.1.8) — Packages and builds installers
• @electron/fuses (1.8.0) — Configures Electron security features
• @electron/notarize (^2.5.0) — macOS code signing and notarization

These tools execute during CI/CD to produce the downloadable binaries from cypress.io.

Testing Infrastructure

Cypress uses multiple test frameworks to validate its own behavior:

• mocha (3.5.3) — Primary test runner for internal test suites
• vitest (^3.2.4) — Modern unit testing with @vitest/coverage-v8
• chai (4.5.0), chai-as-promised (7.1.2) — Assertion libraries
• sinon (7.3.2), sinon-chai (3.7.0) — Mocking and spying
• playwright-webkit (1.61.0) — WebKit browser testing

Notably, Cypress tests itself using @cypress/request and @cypress/request-promise—forked HTTP client libraries maintained under the same organization.

Linting and Code Quality

"eslint": "^8.56.0",
"eslint-plugin-cypress": "3.6.0",
"eslint-plugin-react": "7.37.5",
"eslint-plugin-vue": "7.18.0",
"husky": "7.0.2",
"lint-staged": "^16"

The eslint-plugin-cypress package provides custom rules for Cypress-specific patterns. husky and lint-staged enforce pre-commit checks.

GraphQL Tooling

Cypress Cloud uses GraphQL for its API layer. The monorepo includes extensive code generation:

"@graphql-codegen/cli": "2.2.0",
"@graphql-codegen/typescript": "2.4.2",
"@graphql-codegen/typescript-operations": "2.2.3",
"@graphql-codegen/typescript-resolvers": "^2.6.4",
"@graphql-tools/delegate": "8.2.1",
"@graphql-tools/utils": "8.2.3"

These generate TypeScript types from the Cloud schema, keeping frontend and backend in sync.

AWS and Release Automation

• @aws-sdk/client-s3 (3.485.0) — Uploads binaries to S3
• @aws-sdk/credential-providers (3.53.0) — AWS authentication
• semantic-release (22.0.12), semantic-release-monorepo (8.0.2) — Automated versioning and publishing
• lerna (8.1.9) — Workspace orchestration and changelogs

Development Utilities

Common tools include lodash (^4.17.21), chalk (2.4.2), debug (^4.3.4), cross-env (7.0.3), rimraf (6.1.1), glob (7.1.6), tar (7.5.21), and yaml (2.8.0). ts-node (^10.9.2) enables direct TypeScript execution without pre-compilation.

Workspace-Level Dependencies

While the root manages build tools, actual runtime dependencies live in workspace packages. Key examples:

Workspace	Purpose	Dependency Example
@packages/driver	Browser automation	lodash, bluebird, debug
@packages/server	HTTP proxy and API	express, socket.io, get-port
@packages/electron	Desktop shell	electron (peer dependency)
@packages/proxy	Network interception	http-proxy, net-debugger
cli	NPM-published entry point	commander, listr2, execa

Yarn hoists compatible versions to the root node_modules, but each package declares its exact requirements independently.

Working with Cypress Dependencies

Installing the Full Development Environment

# Clone and install all devDependencies and workspace dependencies

git clone https://github.com/cypress-io/cypress.git
cd cypress
yarn install

This command processes package.json from the root and every workspace, creating a unified node_modules structure.

Adding a New Root Dependency

# Add a development tool available to all workspaces

yarn add --dev @types/new-library@^1.0.0

Update the appropriate workspace package.json if the dependency is needed at runtime in published code.

Adding a Workspace-Specific Dependency

# Navigate to specific workspace first

cd packages/server
yarn add express@^4.18.0

This modifies packages/server/package.json without affecting the root manifest.

Key Dependency Files in the Repository

File Path	Description
[package.json](https://github.com/cypress-io/cypress/blob/develop/package.json)	Root devDependencies for build, test, and release
[cli/package.json](https://github.com/cypress-io/cypress/blob/develop/cli/package.json)	Published cypress NPM package dependencies
[packages/driver/package.json](https://github.com/cypress-io/cypress/blob/develop/packages/driver/package.json)	Browser driver runtime requirements
[packages/server/package.json](https://github.com/cypress-io/cypress/blob/develop/packages/server/package.json)	Server-side runtime dependencies
[packages/electron/package.json](https://github.com/cypress-io/cypress/blob/develop/packages/electron/package.json)	Electron wrapper dependencies
[npm/react/package.json](https://github.com/cypress-io/cypress/blob/develop/npm/react/package.json)	React component testing adapter
[npm/vue/package.json](https://github.com/cypress-io/cypress/blob/develop/npm/vue/package.json)	Vue component testing adapter

Summary

• Cypress dependencies are split between root devDependencies (build tools) and workspace dependencies (runtime code)
• The root package.json declares approximately 95 devDependencies using Yarn 1 workspaces
• Key categories include Electron packaging, testing frameworks, GraphQL codegen, AWS tooling, and release automation
• Runtime dependencies are isolated to individual packages in packages/ and npm/ directories
• Contributing to Cypress requires understanding this separation to add dependencies correctly

Frequently Asked Questions

What package manager does Cypress use?

Cypress uses Yarn 1 with workspaces. The root package.json defines workspace globs, and Yarn hoists compatible dependencies to reduce duplication. The repository includes yarn.lock for deterministic installs.

Why doesn't the root package.json have a dependencies field?

Runtime code in Cypress ships as compiled Electron binaries, not traditional NPM packages. The CLI package (cli/) is the only runtime-published artifact, and it declares its own production dependencies. All other code bundles its requirements during the build process.

How do I find which package provides a specific dependency?

Use yarn why <package> from the repository root. This traces which workspace declares the dependency and whether Yarn hoisted it. For workspace-specific resolution, check the relevant package.json in packages/ subdirectories.

Are Cypress dependencies kept up to date automatically?

Partially. semantic-release and renovate (if configured) handle version bumps, but major upgrades—especially Electron—require manual testing due to binary compatibility requirements. The repository uses yarn-deduplicate (3.1.0) to minimize lockfile bloat.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}