Ryan Manuel
4931cf06ff
* chore: bootstrap AI agent context files (AGENTS.md + CLAUDE.md)
Adds a three-tier set of AI context files across the monorepo:
- Root AGENTS.md / CLAUDE.md — project overview, workspaces, common
commands, architecture map, code conventions, and CI/CD summary
- Workspace-level pairs for cli/, packages/, npm/, tooling/,
system-tests/, and scripts/
- Package-level pairs for all 33 packages/, 15 npm/, 3 tooling/
packages, and the cli workspace (117 files total)
CLAUDE.md files are thin wrappers (@AGENTS.md import + workflow rules)
so Claude Code picks them up walking upward from cwd. AGENTS.md files
carry the substantive content and are also read natively by Codex CLI
and Cursor.
Command conventions applied throughout:
- No watch / file-watcher commands (agents run once and read results)
- No bare full-suite test runs for large packages; always target a
specific file (<path-to-spec>) or glob ("<glob-pattern>")
- No cypress:open (interactive mode); use cypress:run with --spec
- Test runner syntax varies by package: vitest (test --),
mocha (test-unit/test-integration --), jest (--testPathPattern),
Cypress CT (cypress:run:ct -- --spec)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* gitignore
* clarify AI internal docs and contribution guidelines
* update TOC
* tweak nvm wording
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Server
The server is the heart of the Cypress application. All of this code represents the node process running behind the browser application. This node process is responsible for:
- Proxying every byte coming in and out of the browser
- Performing and normalizing automation tasks for each browser
- Coordinating and synchronizing state with the launchpad and driver packages
- Performing node specific tasks on behalf of the driver
- Instantiating and orchestrating nearly every other layer and package
- Spinning up various static file and http servers
- Communicating with our external API's
- Recording videos of run
- Managing mocha reporters
- Managing 3rd party plugins
The driver and the server are the two most complex packages of Cypress.
Developing
To run the Cypress server:
## boots the entire Cypress application
yarn start
Since the server controls nearly every aspect of Cypress, after making changes you'll need to manually restart Cypress.
Since this is slow, it's better to drive your development with tests.
Building
Note: you should not ever need to build the .js files manually. @packages/ts provides require-time transpilation when in development.
yarn workspace @packages/server build-prod
yarn test-unitexecutes unit tests intest/unityarn test-integrationexecutes integration tests intest/integrationyarn test-performanceexecutes performance tests intest/performance
You can also use the test-watch command to rerun a test file whenever there is a change:
yarn test-watch /test/path/to/spec.js
Running individual unit tests
yarn test <path/to/test>
yarn test test/unit/api_spec.js
## or
yarn test-unit api_spec ## shorthand, uses globbing to find spec
Running individual integration tests
yarn test <path/to/test>
yarn test test/integration/cli_spec.js
## or
yarn test-integration cli_spec ## shorthand, uses globbing to find spec
Running e2e/system tests
With the addition of Component Testing,
e2etests have been renamed tosystem-testsand moved to thesystem-testsdirectory.
Updating snapshots
Prepend SNAPSHOT_UPDATE=1 to any test command. See snap-shot-it instructions for more info.
SNAPSHOT_UPDATE=1 yarn test test/unit/api_spec.js
SNAPSHOT_UPDATE=1 yarn test test/integration/cli_spec.js
V8 Snapshots
In order to improve start up time, Cypress uses electron mksnapshot for generating v8 snapshots for both development and production.
Cypress code is automatically set up to run using snapshots. If you want to run Cypress in development without the v8 snapshot (for debugging purposes or to see if there's a problem with the snapshot or the code itself) you can set the environment variable DISABLE_SNAPSHOT_REQUIRE to 1 or true.