Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: update JIT docs #6013

Merged
merged 1 commit into from
Nov 21, 2024
Merged

chore: update JIT docs #6013

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 3 additions & 28 deletions docs/app/references/experiments.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -320,34 +320,9 @@ you will need to add the correct matching glob pattern.
These experiments are available to be specified inside the `component`
configuration object:

| Option | Default | Description |
| ------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `experimentalSingleTabRunMode` | `false` | Run all specs in a single tab, instead of creating a new tab per spec. This can improve run mode performance, but can impact spec isolation and reliability on large test suites. |
| `experimentalJustInTimeCompile` | `false` | Enables Just-In-Time (JIT) compiling for component testing, which will only compile assets related to the spec before the spec is run. Currently supported for Vite and Webpack. |

#### Experimental Just-In-Time Compile

By default, Cypress compiles all specs used by component testing before allowing any spec to run. This works fine for smaller projects most of the time.

However, as a component testing suite grows, the dev server (`vite` or `webpack-dev-server`, depending on your application) also grows with it. This can get to a point where the dev server grows so large that it consumes a large majority of CPU and memory resources, leading to:

- Out Of Memory (OOM) errors.
- `chunk load error`, specific to Webpack where parts of the bundle fail to load.
- long run times while running component tests in CI in `cypress run` mode.
- Unable to efficiently develop tests in `cypress open` mode because the initial and recompiling times for specs and related components are extremely long.
- Inability to leverage [Smart orchestration](/cloud/features/smart-orchestration/overview) effectively to scale resources due to all assets being compiled into the dev server regardless of what specs are run.

The `experimentalJustInTimeCompile` option is designed to remedy this problem. Enabling this option will enable Just-In-Time (JIT) compiling for component testing, which will only compile assets and resources related to the spec before the spec is run. This is applicable in both `open` and `run` modes.

In `open` and `run` modes, the dev server will start up when the Cypress application starts with the component testing type, but will only compile the spec once it is selected or run. When a different spec is run, the different spec is then compiled, omitting the previously run spec from the dev server.

This makes developing your current spec much faster in `open` mode when it comes to initial compiling and recompiling, with a minor tradeoff being to recompile when you switch specs.

This also significantly reduces the memory requirements needed to run your tests in `run` mode, with a tradeoff being that your tests might run slightly slower since the dev server needs to recompile. If time is a factor, [Smart orchestration](/cloud/features/smart-orchestration/overview) can now be effectively used to parallelize your component testing runs on smaller infrastructure since the dev server only compiles what is needed to run the spec.

We are using `experimentalJustInTimeCompile` internally within Cypress for our larger component testing suites and have noticed significant reductions in memory when running `cypress run` mode and have gained significantly faster compile times when leveraging `cypress open` to develop our tests.

If you are using this experiment and would like to leave feedback, please comment on our [github discussion](https://github.com/cypress-io/cypress/discussions/30024).
| Option | Default | Description |
| ------------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `experimentalSingleTabRunMode` | `false` | Run all specs in a single tab, instead of creating a new tab per spec. This can improve run mode performance, but can impact spec isolation and reliability on large test suites. |

## History

Expand Down