Skip to content

Commit

Permalink
remove jit from experimental section (#6013)
Browse files Browse the repository at this point in the history
  • Loading branch information
AtofStryker authored Nov 21, 2024
1 parent 98fdf6d commit e741d6c
Showing 1 changed file with 3 additions and 28 deletions.
31 changes: 3 additions & 28 deletions docs/app/references/experiments.mdx
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

0 comments on commit e741d6c

Please sign in to comment.