diff --git a/CHANGELOG.md b/CHANGELOG.md
index 3229dcf4e156..51e9ae404ccb 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,7 @@
## main
+## 30.0.0
+
### Features
- `[*]` Renamed `globalsCleanupMode` to `globalsCleanup` and `--waitNextEventLoopTurnForUnhandledRejectionEvents` to `--waitForUnhandledRejections`
diff --git a/docs/UpgradingToJest30.md b/docs/UpgradingToJest30.md
index fa23363e32ce..f51c7488e863 100644
--- a/docs/UpgradingToJest30.md
+++ b/docs/UpgradingToJest30.md
@@ -77,7 +77,7 @@ If your project contains files with these extensions that are **not** intended t
:::
-### `--testPathPattern` Renamed to `--testPathPatterns`
+### `--testPathPattern` was renamed to `--testPathPatterns`
If you filter tests by path, note that the CLI flag has changed: The `--testPathPattern` flag is now `--testPathPatterns`. You can pass multiple patterns by separating them with spaces or by repeating the flag. For example:
diff --git a/website/archivedVersions.json b/website/archivedVersions.json
index c6b91cd516a4..bf8183219c8d 100644
--- a/website/archivedVersions.json
+++ b/website/archivedVersions.json
@@ -1,4 +1,7 @@
{
+ "29.6": "https://jest-archive-august-2023.netlify.app/docs/29.6/getting-started/",
+ "29.5": "https://jest-archive-august-2023.netlify.app/docs/29.5/getting-started/",
+ "29.4": "https://jest-archive-august-2023.netlify.app/docs/29.4/getting-started/",
"29.3": "https://jest-archive-august-2023.netlify.app/docs/29.3/getting-started/",
"29.2": "https://jest-archive-august-2023.netlify.app/docs/29.2/getting-started/",
"29.1": "https://jest-archive-august-2023.netlify.app/docs/29.1/getting-started/",
diff --git a/website/blog/2025-06-04-jest-30.md b/website/blog/2025-06-04-jest-30.md
new file mode 100644
index 000000000000..461426edff4d
--- /dev/null
+++ b/website/blog/2025-06-04-jest-30.md
@@ -0,0 +1,190 @@
+---
+title: 'Jest 30: Faster, Leaner, Better'
+authors: [MillerSvt, cpojer]
+---
+
+Today we are happy to announce the release of Jest 30. This release features a substantial number of changes, fixes, and improvements. While it is one of the largest major releases of Jest ever, we admit that three years for a major release is too long. In the future, we are aiming to make more frequent major releases to keep Jest great for the next decade.
+
+If you want to skip all the news and just get going, run `npm install jest@^30.0.0` and follow the migration guide: [Upgrading from Jest 29 to 30](https://jestjs.io/docs/upgrading-to-jest30).
+
+## What’s New?
+
+Jest 30 is noticeably faster, uses less memory, and comes with tons of new features. First, let’s take a look at the breaking changes:
+
+## Breaking Changes
+
+- Jest 30 drops support for Node 14, 16, 19, and 21.
+- `jest-environment-jsdom` was upgraded from jsdom 21 to 26.
+- The minimum compatible TypeScript version is now 5.4.
+- Various `expect` aliases were removed. [`eslint-plugin-jest` has an autofixer](https://github.com/jest-community/eslint-plugin-jest/blob/HEAD/docs/rules/no-alias-methods.md) which you can run to automatically upgrade your codebase.
+- Non-enumerable object properties are now excluded from object matchers such as `toEqual` by default.
+- Jest now supports `.mts` and `.cts` files by default.
+- `--testPathPattern` was renamed to `--testPathPatterns`.
+- Jest now properly handles promises that are first rejected and then later caught to avoid false positive test failures.
+- We made various improvements to Jest’s printing of snapshots which might require you to update snapshots. Google deprecated `goo.gl` links which we were using in snapshots. We don’t like it either, but you’ll have to update all your snapshots.
+- Jest itself is now bundled into a single file per package. This improves performance, but might break if you built tools that reach into Jest's internals.
+
+These are just some of the highlights. The full list of breaking changes can be found in the [CHANGELOG](https://github.com/jestjs/jest/blame/main/CHANGELOG.md) and the [Jest 30 migration guide](https://jestjs.io/docs/upgrading-to-jest30).
+
+## Performance & Memory Improvements
+
+Jest 30 delivers real-world performance gains thanks to many optimizations, especially related to module resolution, memory usage, and test isolation. By relying on the new [unrs-resolver](https://github.com/unrs/unrs-resolver), module resolution in Jest became more feature-rich, standards-compliant, and faster. Thanks to [@JounQin](https://github.com/JounQin) for the migration. Depending on your project, you may see significantly faster test runs and reduced memory consumption. For example, one large TypeScript app with a client and server observed 37% faster test runs and 77% lower memory usage in one part of their codebase:
+
+| | Jest 29 | Jest 30 |
+| ---------------- | ------------------- | ---------------------- |
+| **Server tests** | ~1350s / 7.8 GB max | **~850s / 1.8 GB max** |
+| **Client tests** | ~49s / 1.0 GB max | **~44s / 0.8 GB max** |
+
+Jest is fast, but due to Jest's test isolation, slow user code often exacerbates performance issues and leads to slow test runs. When tests leave behind open handles like unclosed timers or connections to other services, it can cause Jest to hang or slow down. Jest 30 has gotten better at detecting and reporting these issues, which helps you identify and fix slow or problematic tests more easily. For example, tests at [Happo](https://happo.io/) were sped up by 50% from 14 minutes down to 9 minutes by cleaning up open handles and upgrading to Jest 30.
+
+If you are using files that consolidate the exports of multiple modules into a single file (i.e. "barrel files"), we recommend using tools such as [`babel-jest-boost`](https://github.com/gtsop/babel-jest-boost), [`babel-plugin-transform-barrels`](https://github.com/FogelAI/babel-plugin-transform-barrels) or [`no-barrel-file`](https://github.com/Nergie/no-barrel-file) to avoid loading large swaths of application code for each test file. This can lead to performance improvements of up to 100x.
+
+### Globals cleanup between test files
+
+Jest achieves test isolation between files by running each test in a separate [VM context](https://nodejs.org/api/vm.html#vm-executing-javascript), giving each file a fresh global environment. However, if your code does not clean up globals after each test file, it can lead to memory leaks across Jest and slow down your test runs. Jest 30 introduces a new feature that notifies you about globals that are not correctly cleaned up after a test run.
+
+In the future, Jest will automatically clean up globals after each test run. If you don't get any warnings about uncleaned globals with Jest 30, you can already set the globals cleanup mode to "on" now to enable this feature fully, and benefit from major memory savings and performance improvements:
+
+```javascript
+export default {
+ testEnvironmentOptions: {
+ globalsCleanup: 'on',
+ },
+};
+```
+
+The default in Jest is `globalsCleanup: 'soft'`. To disable this feature you can set it to `off`. If you need to protect specific global objects from being cleaned up -- for example, shared utilities or caches -- you can mark them as protected using `jest-util`:
+
+```ts
+import {protectProperties} from 'jest-util';
+
+protectProperties(globalThis['my-property']);
+```
+
+Thanks to [@eyalroth](https://github.com/eyalroth) for implementing this feature!
+
+## New Features
+
+### Improved ECMAScript Module & TypeScript Support
+
+Support for `import.meta.*` and `file://` was added [when using native ESM with Jest](https://jestjs.io/docs/ecmascript-modules). In addition, you can now write your Jest config files in TypeScript, and `.mts` and `.cts` files are natively supported without requiring extra configuration. If you are using Node’s native TypeScript type stripping feature, we no longer load the TypeScript transformer to strip types, leading to faster test runs.
+
+### Spies and the `using` keyword
+
+You can now use [JavaScript’s new explicit resource management syntax (`using`)](https://v8.dev/features/explicit-resource-management) with Jest spies. If your environment supports it, writing `using jest.spyOn(obj, 'method')` will automatically restore the spy when the block ends, so you don’t have to manually clean up.
+
+```typescript
+test('logs a warning', () => {
+ using spy = jest.spyOn(console, 'warn');
+ doSomeThingWarnWorthy();
+ expect(spy).toHaveBeenCalled();
+});
+```
+
+[Documentation](/docs/jest-object#spied-methods-and-the-using-keyword)
+
+### `expect.arrayOf`
+
+Jest 30 introduces a new [asymmetric matcher](https://jestjs.io/docs/expect#asymmetric-matchers), `expect.arrayOf`, which lets you validate every element of an array against a condition or type. For instance, you can expect an array of numbers ensuring all items are numbers:
+
+```javascript
+expect(someArray).toEqual(expect.arrayOf(expect.any(Number)));
+```
+
+[Documentation](/docs/expect#expectarrayofvalue)
+
+### New `test.each` placeholder: `%$`
+
+If you use data-driven tests with `test.each`, you can now include a special placeholder `%$` in your test titles to inject the **number of the test case**. For example:
+
+```javascript
+test.each(cases)('Case %$ works as expected', () => {});
+```
+
+will replace `%$` with the test’s sequence number.
+
+[Documentation](/docs/api#testeachtablename-fn-timeout)
+
+### `jest.advanceTimersToNextFrame()`
+
+[`@sinonjs/fake-timers`](https://github.com/sinonjs/fake-timers) was upgraded to v13, adding `jest.advanceTimersToNextFrame()`. This new function allows you to advance all pending `requestAnimationFrame` callbacks to the next frame boundary, making it easier to test animations or code that relies on `requestAnimationFrame` without having to guess millisecond durations.
+
+[Documentation](/docs/jest-object#jestadvancetimerstonextframe)
+
+### Configurable test retries
+
+Jest 30 enhances `jest.retryTimes()` with new options that give you control over how retries are handled. You can specify a delay or immediately retry a failed test instead of waiting until the entire test suite finishes:
+
+```js
+// Retry failed tests up to 3 times, waiting 1 second between attempts:
+jest.retryTimes(3, {waitBeforeRetry: 1000});
+
+// Immediately retry without waiting for other tests to finish:
+jest.retryTimes(3, {retryImmediately: true});
+```
+
+[Documentation](/docs/jest-object#jestretrytimesnumretries-options)
+
+### `jest.unstable_unmockModule()`
+
+Jest 30 adds new experimental `jest.unstable_unmockModule()` API for finer control when unmocking modules (especially when using native ESM).
+
+[Documentation](/docs/ecmascript-modules#module-unmocking-in-esm)
+
+### `jest.onGenerateMock(callback)`
+
+A new `onGenerateMock` method was added. It registers a callback function that is invoked whenever Jest generates a mock for a module. This callback allows you to modify a mock before it is returned to your test environment:
+
+```javascript
+jest.onGenerateMock((modulePath, moduleMock) => {
+ if (modulePath.includes('Database')) {
+ moduleMock.connect = jest.fn().mockImplementation(() => {
+ console.log('Connected to mock DB');
+ });
+ }
+ return moduleMock;
+});
+```
+
+[Documentation](/docs/jest-object#jestongeneratemockcb)
+
+## Other Improvements
+
+### Custom object serialization
+
+Jest’s matcher utilities now support defining a static `SERIALIZABLE_PROPERTIES` on custom objects. This allows you to control which properties of a custom object are included in snapshots and error messages, making the output more focused and relevant.
+
+[Documentation](https://jestjs.io/docs/next/expect#serializable_properties)
+
+### Asynchronous setup support
+
+Test files listed in `setupFilesAfterEnv` can now export an async function or use top-level `await` similar to `setupFiles`.
+
+### And so much more…
+
+Check out the full [CHANGELOG](https://github.com/jestjs/jest/blame/main/CHANGELOG.md) for all changes, improvements and new features.
+
+### Known Issues
+
+[jsdom has made changes to become more spec compliant](https://github.com/jsdom/jsdom/issues/3492). This might break some use cases, most notably mocking `window.location` in tests. Jest now ships with `@jest/environment-jsdom-abstract` to make it easier for you to compose your own custom test environment based on jsdom. If you are just looking to patch `jsdom`, you can apply [this `jsdom` patch to your project](https://gist.github.com/cpojer/e66f9a082021a82230f2595a6027f161). In the future, we may look into providing an alternative to `jsdom` that is better suited for testing.
+
+## What's Next
+
+Jest has been the most popular JavaScript testing framework for a decade. It is used by millions of developers, supporting a wide range of projects from small libraries to the largest codebases in the world. Jest has constantly been improved over time, and as with all long-lasting software projects used in the real world, we accumulated technical debt. We support some features that only few people or companies use, and we have kept breaking changes to a minimum to avoid disrupting users. Some features should be made possible by Jest, but not as part of the core framework. Other features promote testing the wrong things, and should maybe not be part of Jest at all. In terms of Jest's team, a few of us moved on over time which led to slower progress and fewer releases. Here is how we are going to address these issues going forward:
+
+- **Performance / Technical Debt:** Slim Jest down into a leaner, more performant core. Remove features that are not used by the majority of users, and focus on what makes Jest great.
+- **Consistent Release Cycles:** We will aim to be more consistent with our release cycles and deprecation policies.
+- **Be Open:** Build everything in the open, and be transparent about our plans. Provide more opportunities to get involved and increase the number of contributors.
+- **Be Bold:** As the Jest team, we should be more bold. There are a bunch of things that holds Jest back from what it could be. It's time to make moves.
+
+The great news is that Jest has always been well set up to deliver on these principles, ever since we built the framework as a modular system with clear separation of concerns. Now it's time to execute. _More on all that soon!_
+
+## Thanks
+
+This release wouldn’t have been possible without the hard work of our community. Thank you.
+
+[@SimenB](https://github.com/SimenB), [@mrazauskas](https://github.com/mrazauskas), [@Connormiha](https://github.com/Connormiha), [@liuxingbaoyu](https://github.com/liuxingbaoyu), [@k-rajat19](https://github.com/k-rajat19), [@G-Rath](https://github.com/G-Rath), [@charpeni](https://github.com/charpeni), [@dubzzz](https://github.com/dubzzz), [@stekycz](https://github.com/stekycz), [@yinm](https://github.com/yinm), [@lencioni](https://github.com/lencioni), [@phawxby](https://github.com/phawxby), [@lukeapage](https://github.com/lukeapage), [@robhogan](https://github.com/robhogan), [@fisker](https://github.com/fisker), [@k-rajat19](https://github.com/k-rajat19), [@connectdotz](https://github.com/connectdotz), [@alesmenzel](https://github.com/alesmenzel), [@rickhanlonii](https://github.com/rickhanlonii), [@mbelsky](https://github.com/mbelsky), [@brunocabral88](https://github.com/brunocabral88), [@brandon-leapyear](https://github.com/brandon-leapyear), [@nicolo-ribaudo](https://github.com/nicolo-ribaudo), [@dj-stormtrooper](https://github.com/dj-stormtrooper), [@eryue0220](https://github.com/eryue0220)
+
+A special thanks to everyone who made their first contribution to Jest in this release. Thank you for making Jest better for everyone!
+
+[@eyalroth](https://github.com/eyalroth), [@KhaledElmorsy](https://github.com/KhaledElmorsy), [@mohammednumaan](https://github.com/mohammednumaan), [@bensternthal](https://github.com/bensternthal), [@BondarenkoAlex](https://github.com/BondarenkoAlex), [@phryneas](https://github.com/phryneas), [@jayvdb](https://github.com/jayvdb), [@brandonchinn178](https://github.com/brandonchinn178), [@latin-1](https://github.com/latin-1), [@rmartine-ias](https://github.com/rmartine-ias), [@fa93hws](https://github.com/fa93hws), [@Dunqing](https://github.com/Dunqing), [@gustav0d](https://github.com/gustav0d), [@noritaka1166](https://github.com/noritaka1166), [@andreibereczki](https://github.com/andreibereczki), [@Dreamsorcerer](https://github.com/Dreamsorcerer), [@satanTime](https://github.com/satanTime), [@icholy](https://github.com/icholy), [@ecraig12345](https://github.com/ecraig12345), [@cgm-16](https://github.com/cgm-16), [@sebastiancarlos](https://github.com/sebastiancarlos), [@dancer1325](https://github.com/dancer1325), [@loganrosen](https://github.com/loganrosen), [@zakingslayerv22](https://github.com/zakingslayerv22), [@dev-intj](https://github.com/dev-intj), [@tez3998](https://github.com/tez3998), [@anbnyc](https://github.com/anbnyc), [@pengqiseven](https://github.com/pengqiseven), [@thypon](https://github.com/thypon), [@co63oc](https://github.com/co63oc), [@danielrentz](https://github.com/danielrentz), [@jonasongg](https://github.com/jonasongg), [@andrew-the-drawer](https://github.com/andrew-the-drawer), [@phryneas](https://github.com/phryneas), [@hyperupcall](https://github.com/hyperupcall), [@tonyd33](https://github.com/tonyd33), [@madcapnmckay](https://github.com/madcapnmckay), [@dongwa](https://github.com/dongwa), [@gagan-bhullar-tech](https://github.com/gagan-bhullar-tech), [@ikonst](https://github.com/ikonst), [@ZuBB](https://github.com/ZuBB), [@jzaefferer](https://github.com/jzaefferer), [@brandonnorsworthy](https://github.com/brandonnorsworthy), [@henny1105](https://github.com/henny1105), [@DmitryMakhnev](https://github.com/DmitryMakhnev), [@askoufis](https://github.com/askoufis), [@RahulARanger](https://github.com/RahulARanger), [@Jon-Biz](https://github.com/Jon-Biz), [@fynsta](https://github.com/fynsta), [@KonnorRogers](https://github.com/KonnorRogers), [@BondarenkoAlex](https://github.com/BondarenkoAlex), [@mouadhbb](https://github.com/mouadhbb), [@kemuridama](https://github.com/kemuridama), [@Avi-E-Koenig](https://github.com/Avi-E-Koenig), [@davidroeca](https://github.com/davidroeca), [@akwodkiewicz](https://github.com/akwodkiewicz), [@mukul-turing](https://github.com/mukul-turing), [@dnicolson](https://github.com/dnicolson), [@colinacassidy](https://github.com/colinacassidy), [@ofekm97](https://github.com/ofekm97), [@haze](https://github.com/haze), [@Vadimchesh](https://github.com/Vadimchesh), [@peterdenham](https://github.com/peterdenham), [@ShuZhong](https://github.com/ShuZhong), [@manoraj](https://github.com/manoraj), [@nicolo-ribaudo](https://github.com/nicolo-ribaudo), [@georgekaran](https://github.com/georgekaran), [@MathieuFedrigo](https://github.com/MathieuFedrigo), [@hkdobrev](https://github.com/hkdobrev), [@Germandrummer92](https://github.com/Germandrummer92), [@CheadleCheadle](https://github.com/CheadleCheadle), [@notaphplover](https://github.com/notaphplover), [@danbeam](https://github.com/danbeam), [@arescrimson](https://github.com/arescrimson), [@yepitschunked](https://github.com/yepitschunked), [@JimminiKin](https://github.com/JimminiKin), [@DerTimonius](https://github.com/DerTimonius), [@vkml](https://github.com/vkml), [@ginabethrussell](https://github.com/ginabethrussell), [@jeremiah-snee-openx](https://github.com/jeremiah-snee-openx), [@WillianAgostini](https://github.com/WillianAgostini), [@casey-lentz](https://github.com/casey-lentz), [@faizanu94](https://github.com/faizanu94), [@someone635](https://github.com/someone635), [@rafaelrabelos](https://github.com/rafaelrabelos), [@RayBrokeSomething](https://github.com/RayBrokeSomething), [@DaniAcu](https://github.com/DaniAcu), [@mattkubej](https://github.com/mattkubej), [@tr1ckydev](https://github.com/tr1ckydev), [@shresthasurav](https://github.com/shresthasurav), [@the-ress](https://github.com/the-ress), [@Mutesa-Cedric](https://github.com/Mutesa-Cedric), [@nolddor](https://github.com/nolddor), [@alexreardon](https://github.com/alexreardon), [@Peeja](https://github.com/Peeja), [@verycosy](https://github.com/verycosy), [@mknight-atl](https://github.com/mknight-atl), [@maro1993](https://github.com/maro1993), [@Eric-Tyrrell22](https://github.com/Eric-Tyrrell22)
diff --git a/website/blog/authors.yml b/website/blog/authors.yml
index 1a8d9e3678fc..5229432d2b60 100644
--- a/website/blog/authors.yml
+++ b/website/blog/authors.yml
@@ -49,3 +49,9 @@ jeysal:
socials:
github: jeysal
x: _jeysal_
+
+MillerSvt:
+ name: Svyatoslav Zaytsev
+ image_url: https://github.com/MillerSvt.png
+ socials:
+ github: MillerSvt
diff --git a/website/versioned_docs/version-29.4/CLI.md b/website/versioned_docs/version-29.4/CLI.md
deleted file mode 100644
index e095ce1e1f2e..000000000000
--- a/website/versioned_docs/version-29.4/CLI.md
+++ /dev/null
@@ -1,500 +0,0 @@
----
-id: cli
-title: Jest CLI Options
----
-
-The `jest` command line runner has a number of useful options. You can run `jest --help` to view all available options. Many of the options shown below can also be used together to run tests exactly the way you want. Every one of Jest's [Configuration](Configuration.md) options can also be specified through the CLI.
-
-Here is a brief overview:
-
-## Running from the command line
-
-Run all tests (default):
-
-```bash
-jest
-```
-
-Run only the tests that were specified with a pattern or filename:
-
-```bash
-jest my-test #or
-jest path/to/my-test.js
-```
-
-Run tests related to changed files based on hg/git (uncommitted files):
-
-```bash
-jest -o
-```
-
-Run tests related to `path/to/fileA.js` and `path/to/fileB.js`:
-
-```bash
-jest --findRelatedTests path/to/fileA.js path/to/fileB.js
-```
-
-Run tests that match this spec name (match against the name in `describe` or `test`, basically).
-
-```bash
-jest -t name-of-spec
-```
-
-Run watch mode:
-
-```bash
-jest --watch #runs jest -o by default
-jest --watchAll #runs all tests
-```
-
-Watch mode also enables to specify the name or path to a file to focus on a specific set of tests.
-
-## Using with package manager
-
-If you run Jest via your package manager, you can still pass the command line arguments directly as Jest arguments.
-
-Instead of:
-
-```bash
-jest -u -t="ColorPicker"
-```
-
-you can use:
-
-```bash npm2yarn
-npm test -- -u -t="ColorPicker"
-```
-
-## Camelcase & dashed args support
-
-Jest supports both camelcase and dashed arg formats. The following examples will have an equal result:
-
-```bash
-jest --collect-coverage
-jest --collectCoverage
-```
-
-Arguments can also be mixed:
-
-```bash
-jest --update-snapshot --detectOpenHandles
-```
-
-## Options
-
-:::note
-
-CLI options take precedence over values from the [Configuration](Configuration.md).
-
-:::
-
-import TOCInline from '@theme/TOCInline';
-
-
-
----
-
-## Reference
-
-### `jest `
-
-When you run `jest` with an argument, that argument is treated as a regular expression to match against files in your project. It is possible to run test suites by providing a pattern. Only the files that the pattern matches will be picked up and executed. Depending on your terminal, you may need to quote this argument: `jest "my.*(complex)?pattern"`. On Windows, you will need to use `/` as a path separator or escape `\` as `\\`.
-
-### `--bail[=]`
-
-Alias: `-b`. Exit the test suite immediately upon `n` number of failing test suite. Defaults to `1`.
-
-### `--cache`
-
-Whether to use the cache. Defaults to true. Disable the cache using `--no-cache`.
-
-:::caution
-
-The cache should only be disabled if you are experiencing caching related problems. On average, disabling the cache makes Jest at least two times slower.
-
-:::
-
-If you want to inspect the cache, use `--showConfig` and look at the `cacheDirectory` value. If you need to clear the cache, use `--clearCache`.
-
-### `--changedFilesWithAncestor`
-
-Runs tests related to the current changes and the changes made in the last commit. Behaves similarly to `--onlyChanged`.
-
-### `--changedSince`
-
-Runs tests related to the changes since the provided branch or commit hash. If the current branch has diverged from the given branch, then only changes made locally will be tested. Behaves similarly to `--onlyChanged`.
-
-### `--ci`
-
-When this option is provided, Jest will assume it is running in a CI environment. This changes the behavior when a new snapshot is encountered. Instead of the regular behavior of storing a new snapshot automatically, it will fail the test and require Jest to be run with `--updateSnapshot`.
-
-### `--clearCache`
-
-Deletes the Jest cache directory and then exits without running tests. Will delete `cacheDirectory` if the option is passed, or Jest's default cache directory. The default cache directory can be found by calling `jest --showConfig`.
-
-:::caution
-
-Clearing the cache will reduce performance.
-
-:::
-
-### `--clearMocks`
-
-Automatically clear mock calls, instances, contexts and results before every test. Equivalent to calling [`jest.clearAllMocks()`](JestObjectAPI.md#jestclearallmocks) before each test. This does not remove any mock implementation that may have been provided.
-
-### `--collectCoverageFrom=`
-
-A glob pattern relative to `rootDir` matching the files that coverage info needs to be collected from.
-
-### `--colors`
-
-Forces test results output highlighting even if stdout is not a TTY.
-
-:::note
-
-Alternatively you can set the environment variable `FORCE_COLOR=true` to forcefully enable or `FORCE_COLOR=false` to disable colorized output. The use of `FORCE_COLOR` overrides all other color support checks.
-
-:::
-
-### `--config=`
-
-Alias: `-c`. The path to a Jest config file specifying how to find and execute tests. If no `rootDir` is set in the config, the directory containing the config file is assumed to be the `rootDir` for the project. This can also be a JSON-encoded value which Jest will use as configuration.
-
-### `--coverage[=]`
-
-Alias: `--collectCoverage`. Indicates that test coverage information should be collected and reported in the output. Optionally pass `` to override option set in configuration.
-
-### `--coverageDirectory=`
-
-The directory where Jest should output its coverage files.
-
-### `--coverageProvider=`
-
-Indicates which provider should be used to instrument code for coverage. Allowed values are `babel` (default) or `v8`.
-
-### `--debug`
-
-Print debugging info about your Jest config.
-
-### `--detectOpenHandles`
-
-Attempt to collect and print open handles preventing Jest from exiting cleanly. Use this in cases where you need to use `--forceExit` in order for Jest to exit to potentially track down the reason. This implies `--runInBand`, making tests run serially. Implemented using [`async_hooks`](https://nodejs.org/api/async_hooks.html). This option has a significant performance penalty and should only be used for debugging.
-
-### `--env=`
-
-The test environment used for all tests. This can point to any file or node module. Examples: `jsdom`, `node` or `path/to/my-environment.js`.
-
-### `--errorOnDeprecated`
-
-Make calling deprecated APIs throw helpful error messages. Useful for easing the upgrade process.
-
-### `--expand`
-
-Alias: `-e`. Use this flag to show full diffs and errors instead of a patch.
-
-### `--filter=`
-
-Path to a module exporting a filtering function. This asynchronous function receives a list of test paths which can be manipulated to exclude tests from running by returning an object with shape `{ filtered: Array<{ test: string }> }`. Especially useful when used in conjunction with a testing infrastructure to filter known broken tests, e.g.
-
-```js title="my-filter.js"
-module.exports = testPaths => {
- const allowedPaths = testPaths
- .filter(filteringFunction)
- .map(test => ({test})); // [{ test: "path1.spec.js" }, { test: "path2.spec.js" }, etc]
-
- return {
- filtered: allowedPaths,
- };
-};
-```
-
-### `--findRelatedTests `
-
-Find and run the tests that cover a space separated list of source files that were passed in as arguments. Useful for pre-commit hook integration to run the minimal amount of tests necessary. Can be used together with `--coverage` to include a test coverage for the source files, no duplicate `--collectCoverageFrom` arguments needed.
-
-### `--forceExit`
-
-Force Jest to exit after all tests have completed running. This is useful when resources set up by test code cannot be adequately cleaned up.
-
-:::caution
-
-This feature is an escape-hatch. If Jest doesn't exit at the end of a test run, it means external resources are still being held on to or timers are still pending in your code. It is advised to tear down external resources after each test to make sure Jest can shut down cleanly. You can use `--detectOpenHandles` to help track it down.
-
-:::
-
-### `--help`
-
-Show the help information, similar to this page.
-
-### `--ignoreProjects ... `
-
-Ignore the tests of the specified projects. Jest uses the attribute `displayName` in the configuration to identify each project. If you use this option, you should provide a `displayName` to all your projects.
-
-### `--init`
-
-Generate a basic configuration file. Based on your project, Jest will ask you a few questions that will help to generate a `jest.config.js` file with a short description for each option.
-
-### `--injectGlobals`
-
-Insert Jest's globals (`expect`, `test`, `describe`, `beforeEach` etc.) into the global environment. If you set this to `false`, you should import from `@jest/globals`, e.g.
-
-```ts
-import {expect, jest, test} from '@jest/globals';
-
-jest.useFakeTimers();
-
-test('some test', () => {
- expect(Date.now()).toBe(0);
-});
-```
-
-:::note
-
-This option is only supported using the default `jest-circus` test runner.
-
-:::
-
-### `--json`
-
-Prints the test results in JSON. This mode will send all other test output and user messages to stderr.
-
-### `--lastCommit`
-
-Run all tests affected by file changes in the last commit made. Behaves similarly to `--onlyChanged`.
-
-### `--listTests`
-
-Lists all test files that Jest will run given the arguments, and exits.
-
-### `--logHeapUsage`
-
-Logs the heap usage after every test. Useful to debug memory leaks. Use together with `--runInBand` and `--expose-gc` in node.
-
-### `--maxConcurrency=`
-
-Prevents Jest from executing more than the specified amount of tests at the same time. Only affects tests that use `test.concurrent`.
-
-### `--maxWorkers=|`
-
-Alias: `-w`. Specifies the maximum number of workers the worker-pool will spawn for running tests. In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. In watch mode, this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt. It may be useful to adjust this in resource limited environments like CIs but the defaults should be adequate for most use-cases.
-
-For environments with variable CPUs available, you can use percentage based configuration: `--maxWorkers=50%`
-
-### `--noStackTrace`
-
-Disables stack trace in test results output.
-
-### `--notify`
-
-Activates notifications for test results. Good for when you don't want your consciousness to be able to focus on anything except JavaScript testing.
-
-### `--onlyChanged`
-
-Alias: `-o`. Attempts to identify which tests to run based on which files have changed in the current repository. Only works if you're running tests in a git/hg repository at the moment and requires a static dependency graph (ie. no dynamic requires).
-
-### `--onlyFailures`
-
-Alias: `-f`. Run tests that failed in the previous execution.
-
-### `--outputFile=`
-
-Write test results to a file when the `--json` option is also specified. The returned JSON structure is documented in [testResultsProcessor](Configuration.md#testresultsprocessor-string).
-
-### `--passWithNoTests`
-
-Allows the test suite to pass when no files are found.
-
-### `--projects ... `
-
-Run tests from one or more projects, found in the specified paths; also takes path globs. This option is the CLI equivalent of the [`projects`](configuration#projects-arraystring--projectconfig) configuration option.
-
-:::note
-
-If configuration files are found in the specified paths, _all_ projects specified within those configuration files will be run.
-
-:::
-
-### `--reporters`
-
-Run tests with specified reporters. [Reporter options](configuration#reporters-arraymodulename--modulename-options) are not available via CLI. Example with multiple reporters:
-
-`jest --reporters="default" --reporters="jest-junit"`
-
-### `--resetMocks`
-
-Automatically reset mock state before every test. Equivalent to calling [`jest.resetAllMocks()`](JestObjectAPI.md#jestresetallmocks) before each test. This will lead to any mocks having their fake implementations removed but does not restore their initial implementation.
-
-### `--restoreMocks`
-
-Automatically restore mock state and implementation before every test. Equivalent to calling [`jest.restoreAllMocks()`](JestObjectAPI.md#jestrestoreallmocks) before each test. This will lead to any mocks having their fake implementations removed and restores their initial implementation.
-
-### `--roots`
-
-A list of paths to directories that Jest should use to search for files in.
-
-### `--runInBand`
-
-Alias: `-i`. Run all tests serially in the current process, rather than creating a worker pool of child processes that run tests. This can be useful for debugging.
-
-### `--runTestsByPath`
-
-Run only the tests that were specified with their exact paths.
-
-:::tip
-
-The default regex matching works fine on small runs, but becomes slow if provided with multiple patterns and/or against a lot of tests. This option replaces the regex matching logic and by that optimizes the time it takes Jest to filter specific test files.
-
-:::
-
-### `--seed=`
-
-Sets a seed value that can be retrieved in a test file via [`jest.getSeed()`](JestObjectAPI.md#jestgetseed). The seed value must be between `-0x80000000` and `0x7fffffff` inclusive (`-2147483648` (`-(2 ** 31)`) and `2147483647` (`2 ** 31 - 1`) in decimal).
-
-```bash
-jest --seed=1324
-```
-
-:::tip
-
-If this option is not specified Jest will randomly generate the value. You can use the [`--showSeed`](#--showseed) flag to print the seed in the test report summary.
-
-Jest uses the seed internally for shuffling the order in which test suites are run. If the [`--randomize`](#--randomize) option is used, the seed is also used for shuffling the order of tests within each `describe` block. When dealing with flaky tests, rerunning with the same seed might help reproduce the failure.
-
-:::
-
-### `--selectProjects ... `
-
-Run the tests of the specified projects. Jest uses the attribute `displayName` in the configuration to identify each project. If you use this option, you should provide a `displayName` to all your projects.
-
-### `--setupFilesAfterEnv ... `
-
-A list of paths to modules that run some code to configure or to set up the testing framework before each test. Beware that files imported by the setup scripts will not be mocked during testing.
-
-### `--shard`
-
-The test suite shard to execute in a format of `(?\d+)/(?\d+)`.
-
-`shardIndex` describes which shard to select while `shardCount` controls the number of shards the suite should be split into.
-
-`shardIndex` and `shardCount` have to be 1-based, positive numbers, and `shardIndex` has to be lower than or equal to `shardCount`.
-
-When `shard` is specified the configured [`testSequencer`](Configuration.md#testsequencer-string) has to implement a `shard` method.
-
-For example, to split the suite into three shards, each running one third of the tests:
-
-```
-jest --shard=1/3
-jest --shard=2/3
-jest --shard=3/3
-```
-
-### `--showConfig`
-
-Print your Jest config and then exits.
-
-### `--showSeed`
-
-Prints the seed value in the test report summary. See [`--seed=`](#--seednum) for the details.
-
-Can also be set in configuration. See [`showSeed`](Configuration.md#showseed-boolean).
-
-### `--silent`
-
-Prevent tests from printing messages through the console.
-
-### `--testEnvironmentOptions=`
-
-A JSON string with options that will be passed to the `testEnvironment`. The relevant options depend on the environment.
-
-### `--testLocationInResults`
-
-Adds a `location` field to test results. Useful if you want to report the location of a test in a reporter.
-
-:::note
-
-In the resulting object `column` is 0-indexed while `line` is not.
-
-```json
-{
- "column": 4,
- "line": 5
-}
-```
-
-:::
-
-### `--testMatch glob1 ... globN`
-
-The glob patterns Jest uses to detect test files. Please refer to the [`testMatch` configuration](Configuration.md#testmatch-arraystring) for details.
-
-### `--testNamePattern=`
-
-Alias: `-t`. Run only tests with a name that matches the regex. For example, suppose you want to run only tests related to authorization which will have names like `'GET /api/posts with auth'`, then you can use `jest -t=auth`.
-
-:::tip
-
-The regex is matched against the full name, which is a combination of the test name and all its surrounding describe blocks.
-
-:::
-
-### `--testPathIgnorePatterns=|[array]`
-
-A single or array of regexp pattern strings that are tested against all tests paths before executing the test. Contrary to `--testPathPattern`, it will only run those tests with a path that does not match with the provided regexp expressions.
-
-To pass as an array use escaped parentheses and space delimited regexps such as `\(/node_modules/ /tests/e2e/\)`. Alternatively, you can omit parentheses by combining regexps into a single regexp like `/node_modules/|/tests/e2e/`. These two examples are equivalent.
-
-### `--testPathPattern=`
-
-A regexp pattern string that is matched against all tests paths before executing the test. On Windows, you will need to use `/` as a path separator or escape `\` as `\\`.
-
-### `--testRunner=`
-
-Lets you specify a custom test runner.
-
-### `--testSequencer=`
-
-Lets you specify a custom test sequencer. Please refer to the [`testSequencer` configuration](Configuration.md#testsequencer-string) for details.
-
-### `--testTimeout=`
-
-Default timeout of a test in milliseconds. Default value: 5000.
-
-### `--updateSnapshot`
-
-Alias: `-u`. Use this flag to re-record every snapshot that fails during this test run. Can be used together with a test suite pattern or with `--testNamePattern` to re-record snapshots.
-
-### `--useStderr`
-
-Divert all output to stderr.
-
-### `--verbose`
-
-Display individual test results with the test suite hierarchy.
-
-### `--version`
-
-Alias: `-v`. Print the version and exit.
-
-### `--watch`
-
-Watch files for changes and rerun tests related to changed files. If you want to re-run all tests when a file has changed, use the `--watchAll` option instead.
-
-:::tip
-
-Use `--no-watch` (or `--watch=false`) to explicitly disable the watch mode if it was enabled using `--watch`. In most CI environments, this is automatically handled for you.
-
-:::
-
-### `--watchAll`
-
-Watch files for changes and rerun all tests when something changes. If you want to re-run only the tests that depend on the changed files, use the `--watch` option.
-
-:::tip
-
-Use `--no-watchAll` (or `--watchAll=false`) to explicitly disable the watch mode if it was enabled using `--watchAll`. In most CI environments, this is automatically handled for you.
-
-:::
-
-### `--watchman`
-
-Whether to use [`watchman`](https://facebook.github.io/watchman/) for file crawling. Defaults to `true`. Disable using `--no-watchman`.
diff --git a/website/versioned_docs/version-29.4/CodeTransformation.md b/website/versioned_docs/version-29.4/CodeTransformation.md
deleted file mode 100644
index 14d96a16f649..000000000000
--- a/website/versioned_docs/version-29.4/CodeTransformation.md
+++ /dev/null
@@ -1,196 +0,0 @@
----
-id: code-transformation
-title: Code Transformation
----
-
-Jest runs the code in your project as JavaScript, but if you use some syntax not supported by Node out of the box (such as JSX, TypeScript, Vue templates) then you'll need to transform that code into plain JavaScript, similar to what you would do when building for browsers.
-
-Jest supports this via the [`transform`](Configuration.md#transform-objectstring-pathtotransformer--pathtotransformer-object) configuration option.
-
-A transformer is a module that provides a method for transforming source files. For example, if you wanted to be able to use a new language feature in your modules or tests that aren't yet supported by Node, you might plug in a code preprocessor that would transpile a future version of JavaScript to a current one.
-
-Jest will cache the result of a transformation and attempt to invalidate that result based on a number of factors, such as the source of the file being transformed and changing configuration.
-
-## Defaults
-
-Jest ships with one transformer out of the box – [`babel-jest`](https://github.com/jestjs/jest/tree/main/packages/babel-jest#setup). It will load your project's Babel configuration and transform any file matching the `/\.[jt]sx?$/` RegExp (in other words, any `.js`, `.jsx`, `.ts` or `.tsx` file). In addition, `babel-jest` will inject the Babel plugin necessary for mock hoisting talked about in [ES Module mocking](ManualMocks.md#using-with-es-module-imports).
-
-:::tip
-
-Remember to include the default `babel-jest` transformer explicitly, if you wish to use it alongside with additional code preprocessors:
-
-```json
-"transform": {
- "\\.[jt]sx?$": "babel-jest",
- "\\.css$": "some-css-transformer",
-}
-```
-
-:::
-
-## Writing custom transformers
-
-You can write your own transformer. The API of a transformer is as follows:
-
-```ts
-interface TransformOptions {
- supportsDynamicImport: boolean;
- supportsExportNamespaceFrom: boolean;
- /**
- * The value is:
- * - `false` if Jest runs without Node ESM flag `--experimental-vm-modules`
- * - `true` if the file extension is defined in [extensionsToTreatAsEsm](Configuration.md#extensionstotreatasesm-arraystring)
- * and Jest runs with Node ESM flag `--experimental-vm-modules`
- *
- * See more at https://jestjs.io/docs/next/ecmascript-modules
- */
- supportsStaticESM: boolean;
- supportsTopLevelAwait: boolean;
- instrument: boolean;
- /** Cached file system which is used by `jest-runtime` to improve performance. */
- cacheFS: Map;
- /** Jest configuration of currently running project. */
- config: ProjectConfig;
- /** Stringified version of the `config` - useful in cache busting. */
- configString: string;
- /** Transformer configuration passed through `transform` option by the user. */
- transformerConfig: TransformerConfig;
-}
-
-type TransformedSource = {
- code: string;
- map?: RawSourceMap | string | null;
-};
-
-interface SyncTransformer {
- canInstrument?: boolean;
-
- getCacheKey?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => string;
-
- getCacheKeyAsync?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => Promise;
-
- process: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => TransformedSource;
-
- processAsync?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => Promise;
-}
-
-interface AsyncTransformer {
- canInstrument?: boolean;
-
- getCacheKey?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => string;
-
- getCacheKeyAsync?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => Promise;
-
- process?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => TransformedSource;
-
- processAsync: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => Promise;
-}
-
-type Transformer =
- | SyncTransformer
- | AsyncTransformer;
-
-type TransformerCreator<
- X extends Transformer,
- TransformerConfig = unknown,
-> = (transformerConfig?: TransformerConfig) => X;
-
-type TransformerFactory = {
- createTransformer: TransformerCreator;
-};
-```
-
-:::note
-
-The definitions above were trimmed down for brevity. Full code can be found in [Jest repo on GitHub](https://github.com/jestjs/jest/blob/main/packages/jest-transform/src/types.ts) (remember to choose the right tag/commit for your version of Jest).
-
-:::
-
-There are a couple of ways you can import code into Jest - using Common JS (`require`) or ECMAScript Modules (`import` - which exists in static and dynamic versions). Jest passes files through code transformation on demand (for instance when a `require` or `import` is evaluated). This process, also known as "transpilation", might happen _synchronously_ (in the case of `require`), or _asynchronously_ (in the case of `import` or `import()`, the latter of which also works from Common JS modules). For this reason, the interface exposes both pairs of methods for asynchronous and synchronous processes: `process{Async}` and `getCacheKey{Async}`. The latter is called to figure out if we need to call `process{Async}` at all.
-
-Asynchronous transpilation can fall back to the synchronous `process` call if `processAsync` is unimplemented, but synchronous transpilation cannot use the asynchronous `processAsync` call. If your codebase is ESM only, implementing the async variants are sufficient. Otherwise, if any code is loaded through `require` (including `createRequire` from within ESM), then you need to implement the synchronous `process` variant.
-
-Be aware that `node_modules` is not transpiled with default config, the `transformIgnorePatterns` setting must be modified in order to do so.
-
-Semi-related to this are the supports flags we pass (see `CallerTransformOptions` above), but those should be used within the transform to figure out if it should return ESM or CJS, and has no direct bearing on sync vs async
-
-Though not required, we _highly recommend_ implementing `getCacheKey` as well, so we do not waste resources transpiling when we could have read its previous result from disk. You can use [`@jest/create-cache-key-function`](https://www.npmjs.com/package/@jest/create-cache-key-function) to help implement it.
-
-Instead of having your custom transformer implement the `Transformer` interface directly, you can choose to export `createTransformer`, a factory function to dynamically create transformers. This is to allow having a transformer config in your jest config.
-
-:::note
-
-[ECMAScript module](ECMAScriptModules.md) support is indicated by the passed in `supports*` options. Specifically `supportsDynamicImport: true` means the transformer can return `import()` expressions, which is supported by both ESM and CJS. If `supportsStaticESM: true` it means top level `import` statements are supported and the code will be interpreted as ESM and not CJS. See [Node's docs](https://nodejs.org/api/esm.html#esm_differences_between_es_modules_and_commonjs) for details on the differences.
-
-:::
-
-:::tip
-
-Make sure `process{Async}` method returns source map alongside with transformed code, so it is possible to report line information accurately in code coverage and test errors. Inline source maps also work but are slower.
-
-During the development of a transformer it can be useful to run Jest with `--no-cache` to frequently [delete cache](Troubleshooting.md#caching-issues).
-
-:::
-
-### Examples
-
-### TypeScript with type checking
-
-While `babel-jest` by default will transpile TypeScript files, Babel will not verify the types. If you want that you can use [`ts-jest`](https://github.com/kulshekhar/ts-jest).
-
-#### Transforming images to their path
-
-Importing images is a way to include them in your browser bundle, but they are not valid JavaScript. One way of handling it in Jest is to replace the imported value with its filename.
-
-```js title="fileTransformer.js"
-const path = require('path');
-
-module.exports = {
- process(sourceText, sourcePath, options) {
- return {
- code: `module.exports = ${JSON.stringify(path.basename(sourcePath))};`,
- };
- },
-};
-```
-
-```js title="jest.config.js"
-module.exports = {
- transform: {
- '\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':
- '/fileTransformer.js',
- },
-};
-```
diff --git a/website/versioned_docs/version-29.4/Configuration.md b/website/versioned_docs/version-29.4/Configuration.md
deleted file mode 100644
index ca1f8438e7fc..000000000000
--- a/website/versioned_docs/version-29.4/Configuration.md
+++ /dev/null
@@ -1,2444 +0,0 @@
----
-id: configuration
-title: Configuring Jest
----
-
-The Jest philosophy is to work great by default, but sometimes you just need more configuration power.
-
-It is recommended to define the configuration in a dedicated JavaScript, TypeScript or JSON file. The file will be discovered automatically, if it is named `jest.config.js|ts|mjs|cjs|json`. You can use [`--config`](CLI.md#--configpath) flag to pass an explicit path to the file.
-
-:::note
-
-Keep in mind that the resulting configuration object must always be JSON-serializable.
-
-:::
-
-The configuration file should simply export an object:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- verbose: true,
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- verbose: true,
-};
-
-export default config;
-```
-
-Or a function returning an object:
-
-```js tab
-/** @returns {Promise} */
-module.exports = async () => {
- return {
- verbose: true,
- };
-};
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-export default async (): Promise => {
- return {
- verbose: true,
- };
-};
-```
-
-:::tip
-
-To read TypeScript configuration files Jest requires [`ts-node`](https://npmjs.com/package/ts-node). Make sure it is installed in your project.
-
-:::
-
-The configuration also can be stored in a JSON file as a plain object:
-
-```json title="jest.config.json"
-{
- "bail": 1,
- "verbose": true
-}
-```
-
-Alternatively Jest's configuration can be defined through the `"jest"` key in the `package.json` of your project:
-
-```json title="package.json"
-{
- "name": "my-project",
- "jest": {
- "verbose": true
- }
-}
-```
-
-## Options
-
-:::info
-
-You can retrieve Jest's defaults from `jest-config` to extend them if needed:
-
-```js tab
-const {defaults} = require('jest-config');
-
-/** @type {import('jest').Config} */
-const config = {
- moduleFileExtensions: [...defaults.moduleFileExtensions, 'mts', 'cts'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-import {defaults} from 'jest-config';
-
-const config: Config = {
- moduleFileExtensions: [...defaults.moduleFileExtensions, 'mts'],
-};
-
-export default config;
-```
-
-:::
-
-import TOCInline from '@theme/TOCInline';
-
-
-
----
-
-## Reference
-
-### `automock` \[boolean]
-
-Default: `false`
-
-This option tells Jest that all imported modules in your tests should be mocked automatically. All modules used in your tests will have a replacement implementation, keeping the API surface.
-
-Example:
-
-```js title="utils.js"
-export default {
- authorize: () => 'token',
- isAuthorized: secret => secret === 'wizard',
-};
-```
-
-```js title="__tests__/automock.test.js"
-import utils from '../utils';
-
-test('if utils mocked automatically', () => {
- // Public methods of `utils` are now mock functions
- expect(utils.authorize.mock).toBeTruthy();
- expect(utils.isAuthorized.mock).toBeTruthy();
-
- // You can provide them with your own implementation
- // or pass the expected return value
- utils.authorize.mockReturnValue('mocked_token');
- utils.isAuthorized.mockReturnValue(true);
-
- expect(utils.authorize()).toBe('mocked_token');
- expect(utils.isAuthorized('not_wizard')).toBeTruthy();
-});
-```
-
-:::note
-
-Node modules are automatically mocked when you have a manual mock in place (e.g.: `__mocks__/lodash.js`). More info [here](ManualMocks.md#mocking-node-modules).
-
-Node.js core modules, like `fs`, are not mocked by default. They can be mocked explicitly, like `jest.mock('fs')`.
-
-:::
-
-### `bail` \[number | boolean]
-
-Default: `0`
-
-By default, Jest runs all tests and produces all errors into the console upon completion. The bail config option can be used here to have Jest stop running tests after `n` failures. Setting bail to `true` is the same as setting bail to `1`.
-
-### `cacheDirectory` \[string]
-
-Default: `"/tmp/"`
-
-The directory where Jest should store its cached dependency information.
-
-Jest attempts to scan your dependency tree once (up-front) and cache it in order to ease some of the filesystem churn that needs to happen while running tests. This config option lets you customize where Jest stores that cache data on disk.
-
-### `clearMocks` \[boolean]
-
-Default: `false`
-
-Automatically clear mock calls, instances, contexts and results before every test. Equivalent to calling [`jest.clearAllMocks()`](JestObjectAPI.md#jestclearallmocks) before each test. This does not remove any mock implementation that may have been provided.
-
-### `collectCoverage` \[boolean]
-
-Default: `false`
-
-Indicates whether the coverage information should be collected while executing the test. Because this retrofits all executed files with coverage collection statements, it may significantly slow down your tests.
-
-Jest ships with two coverage providers: `babel` (default) and `v8`. See the [`coverageProvider`](#coverageprovider-string) option for more details.
-
-:::info
-
-The `babel` and `v8` coverage providers use `/* istanbul ignore next */` and `/* c8 ignore next */` comments to exclude lines from coverage reports, respectively. For more information, you can view the [`istanbuljs` documentation](https://github.com/istanbuljs/nyc#parsing-hints-ignoring-lines) and the [`c8` documentation](https://github.com/bcoe/c8#ignoring-uncovered-lines-functions-and-blocks).
-
-:::
-
-### `collectCoverageFrom` \[array]
-
-Default: `undefined`
-
-An array of [glob patterns](https://github.com/micromatch/micromatch) indicating a set of files for which coverage information should be collected. If a file matches the specified glob pattern, coverage information will be collected for it even if no tests exist for this file and it's never required in the test suite.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- collectCoverageFrom: [
- '**/*.{js,jsx}',
- '!**/node_modules/**',
- '!**/vendor/**',
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- collectCoverageFrom: [
- '**/*.{js,jsx}',
- '!**/node_modules/**',
- '!**/vendor/**',
- ],
-};
-
-export default config;
-```
-
-This will collect coverage information for all the files inside the project's `rootDir`, except the ones that match `**/node_modules/**` or `**/vendor/**`.
-
-:::tip
-
-Each glob pattern is applied in the order they are specified in the config. For example `["!**/__tests__/**", "**/*.js"]` will not exclude `__tests__` because the negation is overwritten with the second pattern. In order to make the negated glob work in this example it has to come after `**/*.js`.
-
-:::
-
-:::note
-
-This option requires `collectCoverage` to be set to `true` or Jest to be invoked with `--coverage`.
-
-:::
-
-
- Help:
-
-If you are seeing coverage output such as...
-
-```
-=============================== Coverage summary ===============================
-Statements : Unknown% ( 0/0 )
-Branches : Unknown% ( 0/0 )
-Functions : Unknown% ( 0/0 )
-Lines : Unknown% ( 0/0 )
-================================================================================
-Jest: Coverage data for global was not found.
-```
-
-Most likely your glob patterns are not matching any files. Refer to the [micromatch](https://github.com/micromatch/micromatch) documentation to ensure your globs are compatible.
-
-
-
-### `coverageDirectory` \[string]
-
-Default: `undefined`
-
-The directory where Jest should output its coverage files.
-
-### `coveragePathIgnorePatterns` \[array<string>]
-
-Default: `["/node_modules/"]`
-
-An array of regexp pattern strings that are matched against all file paths before executing the test. If the file path matches any of the patterns, coverage information will be skipped.
-
-These pattern strings match against the full path. Use the `` string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: `["/build/", "/node_modules/"]`.
-
-### `coverageProvider` \[string]
-
-Indicates which provider should be used to instrument code for coverage. Allowed values are `babel` (default) or `v8`.
-
-### `coverageReporters` \[array<string | \[string, options]>]
-
-Default: `["clover", "json", "lcov", "text"]`
-
-A list of reporter names that Jest uses when writing coverage reports. Any [istanbul reporter](https://github.com/istanbuljs/istanbuljs/tree/master/packages/istanbul-reports/lib) can be used.
-
-:::tip
-
-Setting this option overwrites the default values. Add `"text"` or `"text-summary"` to see a coverage summary in the console output.
-
-:::
-
-Additional options can be passed using the tuple form. For example, you may hide coverage report lines for all fully-covered files:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- coverageReporters: ['clover', 'json', 'lcov', ['text', {skipFull: true}]],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- coverageReporters: ['clover', 'json', 'lcov', ['text', {skipFull: true}]],
-};
-
-export default config;
-```
-
-For more information about the options object shape refer to `CoverageReporterWithOptions` type in the [type definitions](https://github.com/jestjs/jest/tree/main/packages/jest-types/src/Config.ts).
-
-### `coverageThreshold` \[object]
-
-Default: `undefined`
-
-This will be used to configure minimum threshold enforcement for coverage results. Thresholds can be specified as `global`, as a [glob](https://github.com/isaacs/node-glob#glob-primer), and as a directory or file path. If thresholds aren't met, jest will fail. Thresholds specified as a positive number are taken to be the minimum percentage required. Thresholds specified as a negative number represent the maximum number of uncovered entities allowed.
-
-For example, with the following configuration jest will fail if there is less than 80% branch, line, and function coverage, or if there are more than 10 uncovered statements:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- coverageThreshold: {
- global: {
- branches: 80,
- functions: 80,
- lines: 80,
- statements: -10,
- },
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- coverageThreshold: {
- global: {
- branches: 80,
- functions: 80,
- lines: 80,
- statements: -10,
- },
- },
-};
-
-export default config;
-```
-
-If globs or paths are specified alongside `global`, coverage data for matching paths will be subtracted from overall coverage and thresholds will be applied independently. Thresholds for globs are applied to all files matching the glob. If the file specified by path is not found, an error is returned.
-
-For example, with the following configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- coverageThreshold: {
- global: {
- branches: 50,
- functions: 50,
- lines: 50,
- statements: 50,
- },
- './src/components/': {
- branches: 40,
- statements: 40,
- },
- './src/reducers/**/*.js': {
- statements: 90,
- },
- './src/api/very-important-module.js': {
- branches: 100,
- functions: 100,
- lines: 100,
- statements: 100,
- },
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- coverageThreshold: {
- global: {
- branches: 50,
- functions: 50,
- lines: 50,
- statements: 50,
- },
- './src/components/': {
- branches: 40,
- statements: 40,
- },
- './src/reducers/**/*.js': {
- statements: 90,
- },
- './src/api/very-important-module.js': {
- branches: 100,
- functions: 100,
- lines: 100,
- statements: 100,
- },
- },
-};
-
-export default config;
-```
-
-Jest will fail if:
-
-- The `./src/components` directory has less than 40% branch or statement coverage.
-- One of the files matching the `./src/reducers/**/*.js` glob has less than 90% statement coverage.
-- The `./src/api/very-important-module.js` file has less than 100% coverage.
-- Every remaining file combined has less than 50% coverage (`global`).
-
-### `dependencyExtractor` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom dependency extractor. It must be a node module that exports an object with an `extract` function. E.g.:
-
-```javascript
-const crypto = require('crypto');
-const fs = require('fs');
-
-module.exports = {
- extract(code, filePath, defaultExtract) {
- const deps = defaultExtract(code, filePath);
- // Scan the file and add dependencies in `deps` (which is a `Set`)
- return deps;
- },
- getCacheKey() {
- return crypto
- .createHash('md5')
- .update(fs.readFileSync(__filename))
- .digest('hex');
- },
-};
-```
-
-The `extract` function should return an iterable (`Array`, `Set`, etc.) with the dependencies found in the code.
-
-That module can also contain a `getCacheKey` function to generate a cache key to determine if the logic has changed and any cached artifacts relying on it should be discarded.
-
-### `displayName` \[string, object]
-
-default: `undefined`
-
-Allows for a label to be printed alongside a test while it is running. This becomes more useful in multi-project repositories where there can be many jest configuration files. This visually tells which project a test belongs to.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- displayName: 'CLIENT',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- displayName: 'CLIENT',
-};
-
-export default config;
-```
-
-Alternatively, an object with the properties `name` and `color` can be passed. This allows for a custom configuration of the background color of the displayName. `displayName` defaults to white when its value is a string. Jest uses [`chalk`](https://github.com/chalk/chalk) to provide the color. As such, all of the valid options for colors supported by `chalk` are also supported by Jest.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- displayName: {
- name: 'CLIENT',
- color: 'blue',
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- displayName: {
- name: 'CLIENT',
- color: 'blue',
- },
-};
-
-export default config;
-```
-
-### `errorOnDeprecated` \[boolean]
-
-Default: `false`
-
-Make calling deprecated APIs throw helpful error messages. Useful for easing the upgrade process.
-
-### `extensionsToTreatAsEsm` \[array<string>]
-
-Default: `[]`
-
-Jest will run `.mjs` and `.js` files with nearest `package.json`'s `type` field set to `module` as ECMAScript Modules. If you have any other files that should run with native ESM, you need to specify their file extension here.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- extensionsToTreatAsEsm: ['.ts'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- extensionsToTreatAsEsm: ['.ts'],
-};
-
-export default config;
-```
-
-:::caution
-
-Jest's ESM support is still experimental, see [its docs for more details](ECMAScriptModules.md).
-
-:::
-
-### `fakeTimers` \[object]
-
-Default: `{}`
-
-The fake timers may be useful when a piece of code sets a long timeout that we don't want to wait for in a test. For additional details see [Fake Timers guide](TimerMocks.md) and [API documentation](JestObjectAPI.md#fake-timers).
-
-This option provides the default configuration of fake timers for all tests. Calling `jest.useFakeTimers()` in a test file will use these options or will override them if a configuration object is passed. For example, you can tell Jest to keep the original implementation of `process.nextTick()` and adjust the limit of recursive timers that will be run:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- fakeTimers: {
- doNotFake: ['nextTick'],
- timerLimit: 1000,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- fakeTimers: {
- doNotFake: ['nextTick'],
- timerLimit: 1000,
- },
-};
-
-export default config;
-```
-
-```js title="fakeTime.test.js"
-// install fake timers for this file using the options from Jest configuration
-jest.useFakeTimers();
-
-test('increase the limit of recursive timers for this and following tests', () => {
- jest.useFakeTimers({timerLimit: 5000});
- // ...
-});
-```
-
-:::tip
-
-Instead of including `jest.useFakeTimers()` in each test file, you can enable fake timers globally for all tests in your Jest configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- fakeTimers: {
- enableGlobally: true,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- fakeTimers: {
- enableGlobally: true,
- },
-};
-
-export default config;
-```
-
-:::
-
-Configuration options:
-
-```ts
-type FakeableAPI =
- | 'Date'
- | 'hrtime'
- | 'nextTick'
- | 'performance'
- | 'queueMicrotask'
- | 'requestAnimationFrame'
- | 'cancelAnimationFrame'
- | 'requestIdleCallback'
- | 'cancelIdleCallback'
- | 'setImmediate'
- | 'clearImmediate'
- | 'setInterval'
- | 'clearInterval'
- | 'setTimeout'
- | 'clearTimeout';
-
-type ModernFakeTimersConfig = {
- /**
- * If set to `true` all timers will be advanced automatically by 20 milliseconds
- * every 20 milliseconds. A custom time delta may be provided by passing a number.
- * The default is `false`.
- */
- advanceTimers?: boolean | number;
- /**
- * List of names of APIs that should not be faked. The default is `[]`, meaning
- * all APIs are faked.
- */
- doNotFake?: Array;
- /** Whether fake timers should be enabled for all test files. The default is `false`. */
- enableGlobally?: boolean;
- /**
- * Use the old fake timers implementation instead of one backed by `@sinonjs/fake-timers`.
- * The default is `false`.
- */
- legacyFakeTimers?: boolean;
- /** Sets current system time to be used by fake timers, in milliseconds. The default is `Date.now()`. */
- now?: number;
- /** Maximum number of recursive timers that will be run. The default is `100_000` timers. */
- timerLimit?: number;
-};
-```
-
-:::info Legacy Fake Timers
-
-For some reason you might have to use legacy implementation of fake timers. Here is how to enable it globally (additional options are not supported):
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- fakeTimers: {
- enableGlobally: true,
- legacyFakeTimers: true,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- fakeTimers: {
- enableGlobally: true,
- legacyFakeTimers: true,
- },
-};
-
-export default config;
-```
-
-:::
-
-### `forceCoverageMatch` \[array<string>]
-
-Default: `['']`
-
-Test files are normally ignored from collecting code coverage. With this option, you can overwrite this behavior and include otherwise ignored files in code coverage.
-
-For example, if you have tests in source files named with `.t.js` extension as following:
-
-```javascript title="sum.t.js"
-export function sum(a, b) {
- return a + b;
-}
-
-if (process.env.NODE_ENV === 'test') {
- test('sum', () => {
- expect(sum(1, 2)).toBe(3);
- });
-}
-```
-
-You can collect coverage from those files with setting `forceCoverageMatch`.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- forceCoverageMatch: ['**/*.t.js'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- forceCoverageMatch: ['**/*.t.js'],
-};
-
-export default config;
-```
-
-### `globals` \[object]
-
-Default: `{}`
-
-A set of global variables that need to be available in all test environments.
-
-For example, the following would create a global `__DEV__` variable set to `true` in all test environments:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- globals: {
- __DEV__: true,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- globals: {
- __DEV__: true,
- },
-};
-
-export default config;
-```
-
-:::note
-
-If you specify a global reference value (like an object or array) here, and some code mutates that value in the midst of running a test, that mutation will _not_ be persisted across test runs for other test files. In addition, the `globals` object must be json-serializable, so it can't be used to specify global functions. For that, you should use `setupFiles`.
-
-:::
-
-### `globalSetup` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom global setup module, which must export a function (it can be sync or async). The function will be triggered once before all test suites and it will receive two arguments: Jest's [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422) and [`projectConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L424-L481).
-
-:::info
-
-A global setup module configured in a project (using multi-project runner) will be triggered only when you run at least one test from this project.
-
-Any global variables that are defined through `globalSetup` can only be read in `globalTeardown`. You cannot retrieve globals defined here in your test suites.
-
-While code transformation is applied to the linked setup-file, Jest will **not** transform any code in `node_modules`. This is due to the need to load the actual transformers (e.g. `babel` or `typescript`) to perform transformation.
-
-:::
-
-```js title="setup.js"
-module.exports = async function (globalConfig, projectConfig) {
- console.log(globalConfig.testPathPattern);
- console.log(projectConfig.cache);
-
- // Set reference to mongod in order to close the server during teardown.
- globalThis.__MONGOD__ = mongod;
-};
-```
-
-```js title="teardown.js"
-module.exports = async function (globalConfig, projectConfig) {
- console.log(globalConfig.testPathPattern);
- console.log(projectConfig.cache);
-
- await globalThis.__MONGOD__.stop();
-};
-```
-
-### `globalTeardown` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom global teardown module which must export a function (it can be sync or async). The function will be triggered once after all test suites and it will receive two arguments: Jest's [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422) and [`projectConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L424-L481).
-
-:::info
-
-A global teardown module configured in a project (using multi-project runner) will be triggered only when you run at least one test from this project.
-
-The same caveat concerning transformation of `node_modules` as for `globalSetup` applies to `globalTeardown`.
-
-:::
-
-### `haste` \[object]
-
-Default: `undefined`
-
-This will be used to configure the behavior of `jest-haste-map`, Jest's internal file crawler/cache system. The following options are supported:
-
-```ts
-type HasteConfig = {
- /** Whether to hash files using SHA-1. */
- computeSha1?: boolean;
- /** The platform to use as the default, e.g. 'ios'. */
- defaultPlatform?: string | null;
- /** Force use of Node's `fs` APIs rather than shelling out to `find` */
- forceNodeFilesystemAPI?: boolean;
- /**
- * Whether to follow symlinks when crawling for files.
- * This options cannot be used in projects which use watchman.
- * Projects with `watchman` set to true will error if this option is set to true.
- */
- enableSymlinks?: boolean;
- /** Path to a custom implementation of Haste. */
- hasteImplModulePath?: string;
- /** All platforms to target, e.g ['ios', 'android']. */
- platforms?: Array;
- /** Whether to throw an error on module collision. */
- throwOnModuleCollision?: boolean;
- /** Custom HasteMap module */
- hasteMapModulePath?: string;
- /** Whether to retain all files, allowing e.g. search for tests in `node_modules`. */
- retainAllFiles?: boolean;
-};
-```
-
-### `injectGlobals` \[boolean]
-
-Default: `true`
-
-Insert Jest's globals (`expect`, `test`, `describe`, `beforeEach` etc.) into the global environment. If you set this to `false`, you should import from `@jest/globals`, e.g.
-
-```ts
-import {expect, jest, test} from '@jest/globals';
-
-jest.useFakeTimers();
-
-test('some test', () => {
- expect(Date.now()).toBe(0);
-});
-```
-
-:::note
-
-This option is only supported using the default `jest-circus` test runner.
-
-:::
-
-### `maxConcurrency` \[number]
-
-Default: `5`
-
-A number limiting the number of tests that are allowed to run at the same time when using `test.concurrent`. Any test above this limit will be queued and executed once a slot is released.
-
-### `maxWorkers` \[number | string]
-
-Specifies the maximum number of workers the worker-pool will spawn for running tests. In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. In watch mode, this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt. It may be useful to adjust this in resource limited environments like CIs but the defaults should be adequate for most use-cases.
-
-For environments with variable CPUs available, you can use percentage based configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- maxWorkers: '50%',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- maxWorkers: '50%',
-};
-
-export default config;
-```
-
-### `moduleDirectories` \[array<string>]
-
-Default: `["node_modules"]`
-
-An array of directory names to be searched recursively up from the requiring module's location. Setting this option will _override_ the default, if you wish to still search `node_modules` for packages include it along with any other options:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- moduleDirectories: ['node_modules', 'bower_components'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- moduleDirectories: ['node_modules', 'bower_components'],
-};
-
-export default config;
-```
-
-:::caution
-
-It is discouraged to use `'.'` as one of the `moduleDirectories`, because this prevents scoped packages such as `@emotion/react` from accessing packages with the same subdirectory name (`react`). See [this issue](https://github.com/jestjs/jest/issues/10498) for more details. In most cases, it is preferable to use the [moduleNameMapper](#modulenamemapper-objectstring-string--arraystring) configuration instead.
-
-:::
-
-### `moduleFileExtensions` \[array<string>]
-
-Default: `["js", "mjs", "cjs", "jsx", "ts", "tsx", "json", "node"]`
-
-An array of file extensions your modules use. If you require modules without specifying a file extension, these are the extensions Jest will look for, in left-to-right order.
-
-We recommend placing the extensions most commonly used in your project on the left, so if you are using TypeScript, you may want to consider moving "ts" and/or "tsx" to the beginning of the array.
-
-### `moduleNameMapper` \[object<string, string | array<string>>]
-
-Default: `null`
-
-A map from regular expressions to module names or to arrays of module names that allow to stub out resources, like images or styles with a single module.
-
-Modules that are mapped to an alias are unmocked by default, regardless of whether automocking is enabled or not.
-
-Use `` string token to refer to [`rootDir`](#rootdir-string) value if you want to use file paths.
-
-Additionally, you can substitute captured regex groups using numbered backreferences.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- moduleNameMapper: {
- '^image![a-zA-Z0-9$_-]+$': 'GlobalImageStub',
- '^[./a-zA-Z0-9$_-]+\\.png$': '/RelativeImageStub.js',
- 'module_name_(.*)': '/substituted_module_$1.js',
- 'assets/(.*)': [
- '/images/$1',
- '/photos/$1',
- '/recipes/$1',
- ],
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- moduleNameMapper: {
- '^image![a-zA-Z0-9$_-]+$': 'GlobalImageStub',
- '^[./a-zA-Z0-9$_-]+\\.png$': '/RelativeImageStub.js',
- 'module_name_(.*)': '/substituted_module_$1.js',
- 'assets/(.*)': [
- '/images/$1',
- '/photos/$1',
- '/recipes/$1',
- ],
- },
-};
-
-export default config;
-```
-
-The order in which the mappings are defined matters. Patterns are checked one by one until one fits. The most specific rule should be listed first. This is true for arrays of module names as well.
-
-:::info
-
-If you provide module names without boundaries `^$` it may cause hard to spot errors. E.g. `relay` will replace all modules which contain `relay` as a substring in its name: `relay`, `react-relay` and `graphql-relay` will all be pointed to your stub.
-
-:::
-
-### `modulePathIgnorePatterns` \[array<string>]
-
-Default: `[]`
-
-An array of regexp pattern strings that are matched against all module paths before those paths are to be considered 'visible' to the module loader. If a given module's path matches any of the patterns, it will not be `require()`-able in the test environment.
-
-These pattern strings match against the full path. Use the `` string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- modulePathIgnorePatterns: ['/build/'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- modulePathIgnorePatterns: ['/build/'],
-};
-
-export default config;
-```
-
-### `modulePaths` \[array<string>]
-
-Default: `[]`
-
-An alternative API to setting the `NODE_PATH` env variable, `modulePaths` is an array of absolute paths to additional locations to search when resolving modules. Use the `` string token to include the path to your project's root directory.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- modulePaths: ['/app/'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- modulePaths: ['/app/'],
-};
-
-export default config;
-```
-
-### `notify` \[boolean]
-
-Default: `false`
-
-Activates native OS notifications for test results. To display the notifications Jest needs [`node-notifier`](https://github.com/mikaelbr/node-notifier) package, which must be installed additionally:
-
-```bash npm2yarn
-npm install --save-dev node-notifier
-```
-
-:::tip
-
-On macOS, remember to allow notifications from `terminal-notifier` under System Preferences > Notifications & Focus.
-
-On Windows, `node-notifier` creates a new start menu entry on the first use and not display the notification. Notifications will be properly displayed on subsequent runs.
-
-:::
-
-### `notifyMode` \[string]
-
-Default: `failure-change`
-
-Specifies notification mode. Requires `notify: true`.
-
-#### Modes
-
-- `always`: always send a notification.
-- `failure`: send a notification when tests fail.
-- `success`: send a notification when tests pass.
-- `change`: send a notification when the status changed.
-- `success-change`: send a notification when tests pass or once when it fails.
-- `failure-change`: send a notification when tests fail or once when it passes.
-
-### `preset` \[string]
-
-Default: `undefined`
-
-A preset that is used as a base for Jest's configuration. A preset should point to an npm module that has a `jest-preset.json`, `jest-preset.js`, `jest-preset.cjs` or `jest-preset.mjs` file at the root.
-
-For example, this preset `foo-bar/jest-preset.js` will be configured as follows:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- preset: 'foo-bar',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- preset: 'foo-bar',
-};
-
-export default config;
-```
-
-Presets may also be relative to filesystem paths:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- preset: './node_modules/foo-bar/jest-preset.js',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- preset: './node_modules/foo-bar/jest-preset.js',
-};
-
-export default config;
-```
-
-:::info
-
-If you also have specified [`rootDir`](#rootdir-string), the resolution of this file will be relative to that root directory.
-
-:::
-
-### `prettierPath` \[string]
-
-Default: `'prettier'`
-
-Sets the path to the [`prettier`](https://prettier.io/) node module used to update inline snapshots.
-
-### `projects` \[array<string | ProjectConfig>]
-
-Default: `undefined`
-
-When the `projects` configuration is provided with an array of paths or glob patterns, Jest will run tests in all of the specified projects at the same time. This is great for monorepos or when working on multiple projects at the same time.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- projects: ['', '/examples/*'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- projects: ['', '/examples/*'],
-};
-
-export default config;
-```
-
-This example configuration will run Jest in the root directory as well as in every folder in the examples directory. You can have an unlimited amount of projects running in the same Jest instance.
-
-The projects feature can also be used to run multiple configurations or multiple [runners](#runner-string). For this purpose, you can pass an array of configuration objects. For example, to run both tests and ESLint (via [jest-runner-eslint](https://github.com/jest-community/jest-runner-eslint)) in the same invocation of Jest:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- projects: [
- {
- displayName: 'test',
- },
- {
- displayName: 'lint',
- runner: 'jest-runner-eslint',
- testMatch: ['/**/*.js'],
- },
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- projects: [
- {
- displayName: 'test',
- },
- {
- displayName: 'lint',
- runner: 'jest-runner-eslint',
- testMatch: ['/**/*.js'],
- },
- ],
-};
-
-export default config;
-```
-
-:::tip
-
-When using multi-project runner, it's recommended to add a `displayName` for each project. This will show the `displayName` of a project next to its tests.
-
-:::
-
-:::note
-
-With the `projects` option enabled, Jest will copy the root-level configuration options to each individual child configuration during the test run, resolving its values in the child's context. This means that string tokens like `` will point to the _child's root directory_ even if they are defined in the root-level configuration.
-
-:::
-
-### `reporters` \[array<moduleName | \[moduleName, options]>]
-
-Default: `undefined`
-
-Use this configuration option to add reporters to Jest. It must be a list of reporter names, additional options can be passed to a reporter using the tuple form:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: [
- 'default',
- ['/custom-reporter.js', {banana: 'yes', pineapple: 'no'}],
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: [
- 'default',
- ['/custom-reporter.js', {banana: 'yes', pineapple: 'no'}],
- ],
-};
-
-export default config;
-```
-
-#### Default Reporter
-
-If custom reporters are specified, the default Jest reporter will be overridden. If you wish to keep it, `'default'` must be passed as a reporters name:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: [
- 'default',
- ['jest-junit', {outputDirectory: 'reports', outputName: 'report.xml'}],
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: [
- 'default',
- ['jest-junit', {outputDirectory: 'reports', outputName: 'report.xml'}],
- ],
-};
-
-export default config;
-```
-
-#### GitHub Actions Reporter
-
-If included in the list, the built-in GitHub Actions Reporter will annotate changed files with test failure messages and (if used with `'silent: false'`) print logs with github group features for easy navigation. Note that `'default'` should not be used in this case as `'github-actions'` will handle that already, so remember to also include `'summary'`. If you wish to use it only for annotations simply leave only the reporter without options as the default value of `'silent'` is `'true'`:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: [['github-actions', {silent: false}], 'summary'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: [['github-actions', {silent: false}], 'summary'],
-};
-
-export default config;
-```
-
-#### Summary Reporter
-
-Summary reporter prints out summary of all tests. It is a part of default reporter, hence it will be enabled if `'default'` is included in the list. For instance, you might want to use it as stand-alone reporter instead of the default one, or together with [Silent Reporter](https://github.com/rickhanlonii/jest-silent-reporter):
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: ['jest-silent-reporter', 'summary'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: ['jest-silent-reporter', 'summary'],
-};
-
-export default config;
-```
-
-#### Custom Reporters
-
-:::tip
-
-Hungry for reporters? Take a look at long list of [awesome reporters](https://github.com/jest-community/awesome-jest/blob/main/README.md#reporters) from Awesome Jest.
-
-:::
-
-Custom reporter module must export a class that takes [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422), `reporterOptions` and `reporterContext` as constructor arguments:
-
-```js title="custom-reporter.js"
-class CustomReporter {
- constructor(globalConfig, reporterOptions, reporterContext) {
- this._globalConfig = globalConfig;
- this._options = reporterOptions;
- this._context = reporterContext;
- }
-
- onRunComplete(testContexts, results) {
- console.log('Custom reporter output:');
- console.log('global config:', this._globalConfig);
- console.log('options for this reporter from Jest config:', this._options);
- console.log('reporter context passed from test scheduler:', this._context);
- }
-
- // Optionally, reporters can force Jest to exit with non zero code by returning
- // an `Error` from `getLastError()` method.
- getLastError() {
- if (this._shouldFail) {
- return new Error('Custom error reported!');
- }
- }
-}
-
-module.exports = CustomReporter;
-```
-
-:::note
-
-For the full list of hooks and argument types see the `Reporter` interface in [packages/jest-reporters/src/types.ts](https://github.com/jestjs/jest/blob/main/packages/jest-reporters/src/types.ts).
-
-:::
-
-### `resetMocks` \[boolean]
-
-Default: `false`
-
-Automatically reset mock state before every test. Equivalent to calling [`jest.resetAllMocks()`](JestObjectAPI.md#jestresetallmocks) before each test. This will lead to any mocks having their fake implementations removed but does not restore their initial implementation.
-
-### `resetModules` \[boolean]
-
-Default: `false`
-
-By default, each test file gets its own independent module registry. Enabling `resetModules` goes a step further and resets the module registry before running each individual test. This is useful to isolate modules for every test so that the local module state doesn't conflict between tests. This can be done programmatically using [`jest.resetModules()`](JestObjectAPI.md#jestresetmodules).
-
-### `resolver` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom resolver. This resolver must be a module that exports _either_:
-
-1. a function expecting a string as the first argument for the path to resolve and an options object as the second argument. The function should either return a path to the module that should be resolved or throw an error if the module can't be found. _or_
-2. an object containing `async` and/or `sync` properties. The `sync` property should be a function with the shape explained above, and the `async` property should also be a function that accepts the same arguments, but returns a promise which resolves with the path to the module or rejects with an error.
-
-The options object provided to resolvers has the shape:
-
-```ts
-type ResolverOptions = {
- /** Directory to begin resolving from. */
- basedir: string;
- /** List of export conditions. */
- conditions?: Array;
- /** Instance of default resolver. */
- defaultResolver: (path: string, options: ResolverOptions) => string;
- /** List of file extensions to search in order. */
- extensions?: Array;
- /** List of directory names to be looked up for modules recursively. */
- moduleDirectory?: Array;
- /** List of `require.paths` to use if nothing is found in `node_modules`. */
- paths?: Array;
- /** Allows transforming parsed `package.json` contents. */
- packageFilter?: (pkg: PackageJSON, file: string, dir: string) => PackageJSON;
- /** Allows transforms a path within a package. */
- pathFilter?: (pkg: PackageJSON, path: string, relativePath: string) => string;
- /** Current root directory. */
- rootDir?: string;
-};
-```
-
-:::tip
-
-The `defaultResolver` passed as an option is the Jest default resolver which might be useful when you write your custom one. It takes the same arguments as your custom synchronous one, e.g. `(path, options)` and returns a string or throws.
-
-:::
-
-For example, if you want to respect Browserify's [`"browser"` field](https://github.com/browserify/browserify-handbook/blob/master/readme.markdown#browser-field), you can use the following resolver:
-
-```js title="resolver.js"
-const browserResolve = require('browser-resolve');
-
-module.exports = browserResolve.sync;
-```
-
-And add it to Jest configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- resolver: '/resolver.js',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- resolver: '/resolver.js',
-};
-
-export default config;
-```
-
-By combining `defaultResolver` and `packageFilter` we can implement a `package.json` "pre-processor" that allows us to change how the default resolver will resolve modules. For example, imagine we want to use the field `"module"` if it is present, otherwise fallback to `"main"`:
-
-```js
-module.exports = (path, options) => {
- // Call the defaultResolver, so we leverage its cache, error handling, etc.
- return options.defaultResolver(path, {
- ...options,
- // Use packageFilter to process parsed `package.json` before the resolution (see https://www.npmjs.com/package/resolve#resolveid-opts-cb)
- packageFilter: pkg => {
- return {
- ...pkg,
- // Alter the value of `main` before resolving the package
- main: pkg.module || pkg.main,
- };
- },
- });
-};
-```
-
-### `restoreMocks` \[boolean]
-
-Default: `false`
-
-Automatically restore mock state and implementation before every test. Equivalent to calling [`jest.restoreAllMocks()`](JestObjectAPI.md#jestrestoreallmocks) before each test. This will lead to any mocks having their fake implementations removed and restores their initial implementation.
-
-### `rootDir` \[string]
-
-Default: The root of the directory containing your Jest [config file](#) _or_ the `package.json` _or_ the [`pwd`](http://en.wikipedia.org/wiki/Pwd) if no `package.json` is found
-
-The root directory that Jest should scan for tests and modules within. If you put your Jest config inside your `package.json` and want the root directory to be the root of your repo, the value for this config param will default to the directory of the `package.json`.
-
-Oftentimes, you'll want to set this to `'src'` or `'lib'`, corresponding to where in your repository the code is stored.
-
-:::tip
-
-Using `''` as a string token in any other path-based configuration settings will refer back to this value. For example, if you want a [`setupFiles`](#setupfiles-array) entry to point at the `some-setup.js` file at the root of the project, set its value to: `'/some-setup.js'`.
-
-:::
-
-### `roots` \[array<string>]
-
-Default: `[""]`
-
-A list of paths to directories that Jest should use to search for files in.
-
-There are times where you only want Jest to search in a single sub-directory (such as cases where you have a `src/` directory in your repo), but prevent it from accessing the rest of the repo.
-
-:::info
-
-While `rootDir` is mostly used as a token to be re-used in other configuration options, `roots` is used by the internals of Jest to locate **test files and source files**. This applies also when searching for manual mocks for modules from `node_modules` (`__mocks__` will need to live in one of the `roots`).
-
-By default, `roots` has a single entry `` but there are cases where you may want to have multiple roots within one project, for example `roots: ["/src/", "/tests/"]`.
-
-:::
-
-### `runner` \[string]
-
-Default: `"jest-runner"`
-
-This option allows you to use a custom runner instead of Jest's default test runner. Examples of runners include:
-
-- [`jest-runner-eslint`](https://github.com/jest-community/jest-runner-eslint)
-- [`jest-runner-mocha`](https://github.com/rogeliog/jest-runner-mocha)
-- [`jest-runner-tsc`](https://github.com/azz/jest-runner-tsc)
-- [`jest-runner-prettier`](https://github.com/keplersj/jest-runner-prettier)
-
-:::info
-
-The `runner` property value can omit the `jest-runner-` prefix of the package name.
-
-:::
-
-To write a test-runner, export a class with which accepts [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422) in the constructor, and has a `runTests` method with the signature:
-
-```ts
-async function runTests(
- tests: Array,
- watcher: TestWatcher,
- onStart: OnTestStart,
- onResult: OnTestSuccess,
- onFailure: OnTestFailure,
- options: TestRunnerOptions,
-): Promise;
-```
-
-If you need to restrict your test-runner to only run in serial rather than being executed in parallel your class should have the property `isSerial` to be set as `true`.
-
-### `sandboxInjectedGlobals` \[array<string>]
-
-:::tip
-
-Renamed from `extraGlobals` in Jest 28.
-
-:::
-
-Default: `undefined`
-
-Test files run inside a [vm](https://nodejs.org/api/vm.html), which slows calls to global context properties (e.g. `Math`). With this option you can specify extra properties to be defined inside the vm for faster lookups.
-
-For example, if your tests call `Math` often, you can pass it by setting `sandboxInjectedGlobals`.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- sandboxInjectedGlobals: ['Math'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- sandboxInjectedGlobals: ['Math'],
-};
-
-export default config;
-```
-
-:::note
-
-This option has no effect if you use [native ESM](ECMAScriptModules.md).
-
-:::
-
-### `setupFiles` \[array]
-
-Default: `[]`
-
-A list of paths to modules that run some code to configure or set up the testing environment. Each setupFile will be run once per test file. Since every test runs in its own environment, these scripts will be executed in the testing environment before executing [`setupFilesAfterEnv`](#setupfilesafterenv-array) and before the test code itself.
-
-:::tip
-
-If your setup script is a CJS module, it may export an async function. Jest will call the function and await its result. This might be useful to fetch some data asynchronously. If the file is an ESM module, simply use top-level await to achieve the same result.
-
-:::
-
-### `setupFilesAfterEnv` \[array]
-
-Default: `[]`
-
-A list of paths to modules that run some code to configure or set up the testing framework before each test file in the suite is executed. Since [`setupFiles`](#setupfiles-array) executes before the test framework is installed in the environment, this script file presents you the opportunity of running some code immediately after the test framework has been installed in the environment but before the test code itself.
-
-In other words, `setupFilesAfterEnv` modules are meant for code which is repeating in each test file. Having the test framework installed makes Jest [globals](GlobalAPI.md), [`jest` object](JestObjectAPI.md) and [`expect`](ExpectAPI.md) accessible in the modules. For example, you can add extra matchers from [`jest-extended`](https://github.com/jest-community/jest-extended) library or call [setup and teardown](SetupAndTeardown.md) hooks:
-
-```js title="setup-jest.js"
-const matchers = require('jest-extended');
-expect.extend(matchers);
-
-afterEach(() => {
- jest.useRealTimers();
-});
-```
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- setupFilesAfterEnv: ['/setup-jest.js'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- setupFilesAfterEnv: ['/setup-jest.js'],
-};
-
-export default config;
-```
-
-### `showSeed` \[boolean]
-
-Default: `false`
-
-The equivalent of the [`--showSeed`](CLI.md#--showseed) flag to print the seed in the test report summary.
-
-### `slowTestThreshold` \[number]
-
-Default: `5`
-
-The number of seconds after which a test is considered as slow and reported as such in the results.
-
-### `snapshotFormat` \[object]
-
-Default: `{escapeString: false, printBasicPrototype: false}`
-
-Allows overriding specific snapshot formatting options documented in the [pretty-format readme](https://www.npmjs.com/package/pretty-format#usage-with-options), with the exceptions of `compareKeys` and `plugins`. For example, this config would have the snapshot formatter not print a prefix for "Object" and "Array":
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- snapshotFormat: {
- printBasicPrototype: false,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- snapshotFormat: {
- printBasicPrototype: false,
- },
-};
-
-export default config;
-```
-
-```js title="some.test.js"
-test('does not show prototypes for object and array inline', () => {
- const object = {
- array: [{hello: 'Danger'}],
- };
- expect(object).toMatchInlineSnapshot(`
- {
- "array": [
- {
- "hello": "Danger",
- },
- ],
- }
- `);
-});
-```
-
-### `snapshotResolver` \[string]
-
-Default: `undefined`
-
-The path to a module that can resolve test\<->snapshot path. This config option lets you customize where Jest stores snapshot files on disk.
-
-```js title="custom-resolver.js"
-module.exports = {
- // resolves from test to snapshot path
- resolveSnapshotPath: (testPath, snapshotExtension) =>
- testPath.replace('__tests__', '__snapshots__') + snapshotExtension,
-
- // resolves from snapshot to test path
- resolveTestPath: (snapshotFilePath, snapshotExtension) =>
- snapshotFilePath
- .replace('__snapshots__', '__tests__')
- .slice(0, -snapshotExtension.length),
-
- // Example test path, used for preflight consistency check of the implementation above
- testPathForConsistencyCheck: 'some/__tests__/example.test.js',
-};
-```
-
-### `snapshotSerializers` \[array<string>]
-
-Default: `[]`
-
-A list of paths to snapshot serializer modules Jest should use for snapshot testing.
-
-Jest has default serializers for built-in JavaScript types, HTML elements (Jest 20.0.0+), ImmutableJS (Jest 20.0.0+) and for React elements. See [snapshot test tutorial](TutorialReactNative.md#snapshot-test) for more information.
-
-```js title="custom-serializer.js"
-module.exports = {
- serialize(val, config, indentation, depth, refs, printer) {
- return `Pretty foo: ${printer(val.foo)}`;
- },
-
- test(val) {
- return val && Object.prototype.hasOwnProperty.call(val, 'foo');
- },
-};
-```
-
-`printer` is a function that serializes a value using existing plugins.
-
-Add `custom-serializer` to your Jest configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- snapshotSerializers: ['path/to/custom-serializer.js'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- snapshotSerializers: ['path/to/custom-serializer.js'],
-};
-
-export default config;
-```
-
-Finally tests would look as follows:
-
-```js
-test(() => {
- const bar = {
- foo: {
- x: 1,
- y: 2,
- },
- };
-
- expect(bar).toMatchSnapshot();
-});
-```
-
-Rendered snapshot:
-
-```json
-Pretty foo: Object {
- "x": 1,
- "y": 2,
-}
-```
-
-:::tip
-
-To make a dependency explicit instead of implicit, you can call [`expect.addSnapshotSerializer`](ExpectAPI.md#expectaddsnapshotserializerserializer) to add a module for an individual test file instead of adding its path to `snapshotSerializers` in Jest configuration.
-
-More about serializers API can be found [here](https://github.com/jestjs/jest/tree/main/packages/pretty-format/README.md#serialize).
-
-:::
-
-### `testEnvironment` \[string]
-
-Default: `"node"`
-
-The test environment that will be used for testing. The default environment in Jest is a Node.js environment. If you are building a web app, you can use a browser-like environment through [`jsdom`](https://github.com/jsdom/jsdom) instead.
-
-By adding a `@jest-environment` docblock at the top of the file, you can specify another environment to be used for all tests in that file:
-
-```js
-/**
- * @jest-environment jsdom
- */
-
-test('use jsdom in this test file', () => {
- const element = document.createElement('div');
- expect(element).not.toBeNull();
-});
-```
-
-You can create your own module that will be used for setting up the test environment. The module must export a class with `setup`, `teardown` and `getVmContext` methods. You can also pass variables from this module to your test suites by assigning them to `this.global` object – this will make them available in your test suites as global variables. The constructor is passed [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422) and [`projectConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L424-L481) as its first argument, and [`testEnvironmentContext`](https://github.com/jestjs/jest/blob/491e7cb0f2daa8263caccc72d48bdce7ba759b11/packages/jest-environment/src/index.ts#L13) as its second.
-
-The class may optionally expose an asynchronous `handleTestEvent` method to bind to events fired by [`jest-circus`](https://github.com/jestjs/jest/tree/main/packages/jest-circus). Normally, `jest-circus` test runner would pause until a promise returned from `handleTestEvent` gets fulfilled, **except for the next events**: `start_describe_definition`, `finish_describe_definition`, `add_hook`, `add_test` or `error` (for the up-to-date list you can look at [SyncEvent type in the types definitions](https://github.com/jestjs/jest/tree/main/packages/jest-types/src/Circus.ts)). That is caused by backward compatibility reasons and `process.on('unhandledRejection', callback)` signature, but that usually should not be a problem for most of the use cases.
-
-Any docblock pragmas in test files will be passed to the environment constructor and can be used for per-test configuration. If the pragma does not have a value, it will be present in the object with its value set to an empty string. If the pragma is not present, it will not be present in the object.
-
-To use this class as your custom environment, refer to it by its full path within the project. For example, if your class is stored in `my-custom-environment.js` in some subfolder of your project, then the annotation might look like this:
-
-```js
-/**
- * @jest-environment ./src/test/my-custom-environment
- */
-```
-
-:::info
-
-TestEnvironment is sandboxed. Each test suite will trigger setup/teardown in their own TestEnvironment.
-
-:::
-
-Example:
-
-```js
-// my-custom-environment
-const NodeEnvironment = require('jest-environment-node').TestEnvironment;
-
-class CustomEnvironment extends NodeEnvironment {
- constructor(config, context) {
- super(config, context);
- console.log(config.globalConfig);
- console.log(config.projectConfig);
- this.testPath = context.testPath;
- this.docblockPragmas = context.docblockPragmas;
- }
-
- async setup() {
- await super.setup();
- await someSetupTasks(this.testPath);
- this.global.someGlobalObject = createGlobalObject();
-
- // Will trigger if docblock contains @my-custom-pragma my-pragma-value
- if (this.docblockPragmas['my-custom-pragma'] === 'my-pragma-value') {
- // ...
- }
- }
-
- async teardown() {
- this.global.someGlobalObject = destroyGlobalObject();
- await someTeardownTasks();
- await super.teardown();
- }
-
- getVmContext() {
- return super.getVmContext();
- }
-
- async handleTestEvent(event, state) {
- if (event.name === 'test_start') {
- // ...
- }
- }
-}
-
-module.exports = CustomEnvironment;
-```
-
-```js
-// my-test-suite
-/**
- * @jest-environment ./my-custom-environment
- */
-let someGlobalObject;
-
-beforeAll(() => {
- someGlobalObject = globalThis.someGlobalObject;
-});
-```
-
-### `testEnvironmentOptions` \[Object]
-
-Default: `{}`
-
-Test environment options that will be passed to the `testEnvironment`. The relevant options depend on the environment.
-
-For example, you can override options passed to [`jsdom`](https://github.com/jsdom/jsdom):
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- testEnvironment: 'jsdom',
- testEnvironmentOptions: {
- html: '',
- url: 'https://jestjs.io/',
- userAgent: 'Agent/007',
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- testEnvironment: 'jsdom',
- testEnvironmentOptions: {
- html: '',
- url: 'https://jestjs.io/',
- userAgent: 'Agent/007',
- },
-};
-
-export default config;
-```
-
-Both `jest-environment-jsdom` and `jest-environment-node` allow specifying `customExportConditions`, which allow you to control which versions of a library are loaded from `exports` in `package.json`. `jest-environment-jsdom` defaults to `['browser']`. `jest-environment-node` defaults to `['node', 'node-addons']`.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- testEnvironment: 'jsdom',
- testEnvironmentOptions: {
- customExportConditions: ['react-native'],
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- testEnvironment: 'jsdom',
- testEnvironmentOptions: {
- customExportConditions: ['react-native'],
- },
-};
-
-export default config;
-```
-
-These options can also be passed in a docblock, similar to `testEnvironment`. The string with options must be parseable by `JSON.parse`:
-
-```js
-/**
- * @jest-environment jsdom
- * @jest-environment-options {"url": "https://jestjs.io/"}
- */
-
-test('use jsdom and set the URL in this test file', () => {
- expect(window.location.href).toBe('https://jestjs.io/');
-});
-```
-
-### `testFailureExitCode` \[number]
-
-Default: `1`
-
-The exit code Jest returns on test failure.
-
-:::info
-
-This does not change the exit code in the case of Jest errors (e.g. invalid configuration).
-
-:::
-
-### `testMatch` \[array<string>]
-
-(default: `[ "**/__tests__/**/*.[jt]s?(x)", "**/?(*.)+(spec|test).[jt]s?(x)" ]`)
-
-The glob patterns Jest uses to detect test files. By default it looks for `.js`, `.jsx`, `.ts` and `.tsx` files inside of `__tests__` folders, as well as any files with a suffix of `.test` or `.spec` (e.g. `Component.test.js` or `Component.spec.js`). It will also find files called `test.js` or `spec.js`.
-
-See the [micromatch](https://github.com/micromatch/micromatch) package for details of the patterns you can specify.
-
-See also [`testRegex` [string | array<string>]](#testregex-string--arraystring), but note that you cannot specify both options.
-
-:::tip
-
-Each glob pattern is applied in the order they are specified in the config. For example `["!**/__fixtures__/**", "**/__tests__/**/*.js"]` will not exclude `__fixtures__` because the negation is overwritten with the second pattern. In order to make the negated glob work in this example it has to come after `**/__tests__/**/*.js`.
-
-:::
-
-### `testPathIgnorePatterns` \[array<string>]
-
-Default: `["/node_modules/"]`
-
-An array of regexp pattern strings that are matched against all test paths before executing the test. If the test path matches any of the patterns, it will be skipped.
-
-These pattern strings match against the full path. Use the `` string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: `["/build/", "/node_modules/"]`.
-
-### `testRegex` \[string | array<string>]
-
-Default: `(/__tests__/.*|(\\.|/)(test|spec))\\.[jt]sx?$`
-
-The pattern or patterns Jest uses to detect test files. By default it looks for `.js`, `.jsx`, `.ts` and `.tsx` files inside of `__tests__` folders, as well as any files with a suffix of `.test` or `.spec` (e.g. `Component.test.js` or `Component.spec.js`). It will also find files called `test.js` or `spec.js`. See also [`testMatch` [array<string>]](#testmatch-arraystring), but note that you cannot specify both options.
-
-The following is a visualization of the default regex:
-
-```bash
-├── __tests__
-│ └── component.spec.js # test
-│ └── anything # test
-├── package.json # not test
-├── foo.test.js # test
-├── bar.spec.jsx # test
-└── component.js # not test
-```
-
-:::info
-
-`testRegex` will try to detect test files using the **absolute file path**, therefore, having a folder with a name that matches it will run all the files as tests.
-
-:::
-
-### `testResultsProcessor` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom results processor. This processor must be a node module that exports a function expecting an object with the following structure as the first argument and return it:
-
-```json
-{
- "success": boolean,
- "startTime": epoch,
- "numTotalTestSuites": number,
- "numPassedTestSuites": number,
- "numFailedTestSuites": number,
- "numRuntimeErrorTestSuites": number,
- "numTotalTests": number,
- "numPassedTests": number,
- "numFailedTests": number,
- "numPendingTests": number,
- "numTodoTests": number,
- "openHandles": Array,
- "testResults": [{
- "numFailingTests": number,
- "numPassingTests": number,
- "numPendingTests": number,
- "testResults": [{
- "title": string (message in it block),
- "status": "failed" | "pending" | "passed",
- "ancestorTitles": [string (message in describe blocks)],
- "failureMessages": [string],
- "numPassingAsserts": number,
- "location": {
- "column": number,
- "line": number
- },
- "duration": number | null
- },
- ...
- ],
- "perfStats": {
- "start": epoch,
- "end": epoch
- },
- "testFilePath": absolute path to test file,
- "coverage": {}
- },
- "testExecError:" (exists if there was a top-level failure) {
- "message": string
- "stack": string
- }
- ...
- ]
-}
-```
-
-`testResultsProcessor` and `reporters` are very similar to each other. One difference is that a test result processor only gets called after all tests finished. Whereas a reporter has the ability to receive test results after individual tests and/or test suites are finished.
-
-### `testRunner` \[string]
-
-Default: `jest-circus/runner`
-
-This option allows the use of a custom test runner. The default is `jest-circus`. A custom test runner can be provided by specifying a path to a test runner implementation.
-
-The test runner module must export a function with the following signature:
-
-```ts
-function testRunner(
- globalConfig: GlobalConfig,
- config: ProjectConfig,
- environment: Environment,
- runtime: Runtime,
- testPath: string,
-): Promise;
-```
-
-An example of such function can be found in our default [jasmine2 test runner package](https://github.com/jestjs/jest/blob/main/packages/jest-jasmine2/src/index.ts).
-
-### `testSequencer` \[string]
-
-Default: `@jest/test-sequencer`
-
-This option allows you to use a custom sequencer instead of Jest's default.
-
-:::tip
-
-Both `sort` and `shard` may optionally return a `Promise`.
-
-:::
-
-For example, you may sort test paths alphabetically:
-
-```js title="custom-sequencer.js"
-const Sequencer = require('@jest/test-sequencer').default;
-
-class CustomSequencer extends Sequencer {
- /**
- * Select tests for shard requested via --shard=shardIndex/shardCount
- * Sharding is applied before sorting
- */
- shard(tests, {shardIndex, shardCount}) {
- const shardSize = Math.ceil(tests.length / shardCount);
- const shardStart = shardSize * (shardIndex - 1);
- const shardEnd = shardSize * shardIndex;
-
- return [...tests]
- .sort((a, b) => (a.path > b.path ? 1 : -1))
- .slice(shardStart, shardEnd);
- }
-
- /**
- * Sort test to determine order of execution
- * Sorting is applied after sharding
- */
- sort(tests) {
- // Test structure information
- // https://github.com/jestjs/jest/blob/6b8b1404a1d9254e7d5d90a8934087a9c9899dab/packages/jest-runner/src/types.ts#L17-L21
- const copyTests = [...tests];
- return copyTests.sort((testA, testB) => (testA.path > testB.path ? 1 : -1));
- }
-}
-
-module.exports = CustomSequencer;
-```
-
-Add `custom-sequencer` to your Jest configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- testSequencer: 'path/to/custom-sequencer.js',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- testSequencer: 'path/to/custom-sequencer.js',
-};
-
-export default config;
-```
-
-### `testTimeout` \[number]
-
-Default: `5000`
-
-Default timeout of a test in milliseconds.
-
-### `transform` \[object<string, pathToTransformer | \[pathToTransformer, object]>]
-
-Default: `{"\\.[jt]sx?$": "babel-jest"}`
-
-A map from regular expressions to paths to transformers. Optionally, a tuple with configuration options can be passed as second argument: `{filePattern: ['path-to-transformer', {options}]}`. For example, here is how you can configure `babel-jest` for non-default behavior: `{'\\.js$': ['babel-jest', {rootMode: 'upward'}]}`.
-
-Jest runs the code of your project as JavaScript, hence a transformer is needed if you use some syntax not supported by Node out of the box (such as JSX, TypeScript, Vue templates). By default, Jest will use [`babel-jest`](https://github.com/jestjs/jest/tree/main/packages/babel-jest#setup) transformer, which will load your project's Babel configuration and transform any file matching the `/\.[jt]sx?$/` RegExp (in other words, any `.js`, `.jsx`, `.ts` or `.tsx` file). In addition, `babel-jest` will inject the Babel plugin necessary for mock hoisting talked about in [ES Module mocking](ManualMocks.md#using-with-es-module-imports).
-
-See the [Code Transformation](CodeTransformation.md) section for more details and instructions on building your own transformer.
-
-:::tip
-
-Keep in mind that a transformer only runs once per file unless the file has changed.
-
-Remember to include the default `babel-jest` transformer explicitly, if you wish to use it alongside with additional code preprocessors:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- transform: {
- '\\.[jt]sx?$': 'babel-jest',
- '\\.css$': 'some-css-transformer',
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- transform: {
- '\\.[jt]sx?$': 'babel-jest',
- '\\.css$': 'some-css-transformer',
- },
-};
-
-export default config;
-```
-
-:::
-
-### `transformIgnorePatterns` \[array<string>]
-
-Default: `["/node_modules/", "\\.pnp\\.[^\\\/]+$"]`
-
-An array of regexp pattern strings that are matched against all source file paths before transformation. If the file path matches **any** of the patterns, it will not be transformed.
-
-Providing regexp patterns that overlap with each other may result in files not being transformed that you expected to be transformed. For example:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- transformIgnorePatterns: ['/node_modules/(?!(foo|bar)/)', '/bar/'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- transformIgnorePatterns: ['/node_modules/(?!(foo|bar)/)', '/bar/'],
-};
-
-export default config;
-```
-
-The first pattern will match (and therefore not transform) files inside `/node_modules` except for those in `/node_modules/foo/` and `/node_modules/bar/`. The second pattern will match (and therefore not transform) files inside any path with `/bar/` in it. With the two together, files in `/node_modules/bar/` will not be transformed because it does match the second pattern, even though it was excluded by the first.
-
-Sometimes it happens (especially in React Native or TypeScript projects) that 3rd party modules are published as untranspiled code. Since all files inside `node_modules` are not transformed by default, Jest will not understand the code in these modules, resulting in syntax errors. To overcome this, you may use `transformIgnorePatterns` to allow transpiling such modules. You'll find a good example of this use case in [React Native Guide](/docs/tutorial-react-native#transformignorepatterns-customization).
-
-These pattern strings match against the full path. Use the `` string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- transformIgnorePatterns: [
- '/bower_components/',
- '/node_modules/',
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- transformIgnorePatterns: [
- '/bower_components/',
- '/node_modules/',
- ],
-};
-
-export default config;
-```
-
-:::tip
-
-If you use `pnpm` and need to convert some packages under `node_modules`, you need to note that the packages in this folder (e.g. `node_modules/package-a/`) have been symlinked to the path under `.pnpm` (e.g. `node_modules/.pnpm/package-a@x.x.x/node_modules/package-a/`), so using `/node_modules/(?!(package-a|@scope/pkg-b)/)` directly will not be recognized, while is to use:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- transformIgnorePatterns: [
- '/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)',
- /* if config file is under '~/packages/lib-a/' */
- `${path.join(
- __dirname,
- '../..',
- )}/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)`,
- /* or using relative pattern to match the second 'node_modules/' in 'node_modules/.pnpm/@scope+pkg-b@x.x.x/node_modules/@scope/pkg-b/' */
- 'node_modules/(?!.pnpm|package-a|@scope/pkg-b)',
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- transformIgnorePatterns: [
- '/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)',
- /* if config file is under '~/packages/lib-a/' */
- `${path.join(
- __dirname,
- '../..',
- )}/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)`,
- /* or using relative path to match the second 'node_modules/' in 'node_modules/.pnpm/@scope+pkg-b@x.x.x/node_modules/@scope/pkg-b/' */
- 'node_modules/(?!.pnpm|package-a|@scope/pkg-b)',
- ],
-};
-
-export default config;
-```
-
-It should be noted that the folder name of pnpm under `.pnpm` is the package name plus `@` and version number, so writing `/` will not be recognized, but using `@` can.
-
-:::
-
-### `unmockedModulePathPatterns` \[array<string>]
-
-Default: `[]`
-
-An array of regexp pattern strings that are matched against all modules before the module loader will automatically return a mock for them. If a module's path matches any of the patterns in this list, it will not be automatically mocked by the module loader.
-
-This is useful for some commonly used 'utility' modules that are almost always used as implementation details almost all the time (like `underscore`, `lodash`, etc). It's generally a best practice to keep this list as small as possible and always use explicit `jest.mock()`/`jest.unmock()` calls in individual tests. Explicit per-test setup is far easier for other readers of the test to reason about the environment the test will run in.
-
-It is possible to override this setting in individual tests by explicitly calling `jest.mock()` at the top of the test file.
-
-### `verbose` \[boolean]
-
-Default: `false` or `true` if there is only one test file to run
-
-Indicates whether each individual test should be reported during the run. All errors will also still be shown on the bottom after execution.
-
-### `watchPathIgnorePatterns` \[array<string>]
-
-Default: `[]`
-
-An array of RegExp patterns that are matched against all source file paths before re-running tests in watch mode. If the file path matches any of the patterns, when it is updated, it will not trigger a re-run of tests.
-
-These patterns match against the full path. Use the `` string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: `["/node_modules/"]`.
-
-Even if nothing is specified here, the watcher will ignore changes to the version control folders (.git, .hg, .sl). Other hidden files and directories, i.e. those that begin with a dot (`.`), are watched by default. Remember to escape the dot when you add them to `watchPathIgnorePatterns` as it is a special RegExp character.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- watchPathIgnorePatterns: ['/\\.tmp/', '/bar/'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- watchPathIgnorePatterns: ['/\\.tmp/', '/bar/'],
-};
-
-export default config;
-```
-
-### `watchPlugins` \[array<string | \[string, Object]>]
-
-Default: `[]`
-
-This option allows you to use custom watch plugins. Read more about watch plugins [here](watch-plugins).
-
-Examples of watch plugins include:
-
-- [`jest-watch-master`](https://github.com/rickhanlonii/jest-watch-master)
-- [`jest-watch-select-projects`](https://github.com/rogeliog/jest-watch-select-projects)
-- [`jest-watch-suspend`](https://github.com/unional/jest-watch-suspend)
-- [`jest-watch-typeahead`](https://github.com/jest-community/jest-watch-typeahead)
-- [`jest-watch-yarn-workspaces`](https://github.com/cameronhunter/jest-watch-directories/tree/master/packages/jest-watch-yarn-workspaces)
-
-:::info
-
-The values in the `watchPlugins` property value can omit the `jest-watch-` prefix of the package name.
-
-:::
-
-### `watchman` \[boolean]
-
-Default: `true`
-
-Whether to use [`watchman`](https://facebook.github.io/watchman/) for file crawling.
-
-### `workerIdleMemoryLimit` \[number|string]
-
-Default: `undefined`
-
-Specifies the memory limit for workers before they are recycled and is primarily a work-around for [this issue](https://github.com/jestjs/jest/issues/11956);
-
-After the worker has executed a test the memory usage of it is checked. If it exceeds the value specified the worker is killed and restarted. The limit can be specified in a number of different ways and whatever the result is `Math.floor` is used to turn it into an integer value:
-
-- `<= 1` - The value is assumed to be a percentage of system memory. So 0.5 sets the memory limit of the worker to half of the total system memory
-- `\> 1` - Assumed to be a fixed byte value. Because of the previous rule if you wanted a value of 1 byte (I don't know why) you could use `1.1`.
-- With units
- - `50%` - As above, a percentage of total system memory
- - `100KB`, `65MB`, etc - With units to denote a fixed memory limit.
- - `K` / `KB` - Kilobytes (x1000)
- - `KiB` - Kibibytes (x1024)
- - `M` / `MB` - Megabytes
- - `MiB` - Mebibytes
- - `G` / `GB` - Gigabytes
- - `GiB` - Gibibytes
-
-:::caution
-
-Percentage based memory limit [does not work on Linux CircleCI workers](https://github.com/jestjs/jest/issues/11956#issuecomment-1212925677) due to incorrect system memory being reported.
-
-:::
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- workerIdleMemoryLimit: 0.2,
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- workerIdleMemoryLimit: 0.2,
-};
-
-export default config;
-```
-
-### `//` \[string]
-
-This option allows comments in `package.json`. Include the comment text as the value of this key:
-
-```json title="package.json"
-{
- "name": "my-project",
- "jest": {
- "//": "Comment goes here",
- "verbose": true
- }
-}
-```
diff --git a/website/versioned_docs/version-29.4/ECMAScriptModules.md b/website/versioned_docs/version-29.4/ECMAScriptModules.md
deleted file mode 100644
index 5495913aaaef..000000000000
--- a/website/versioned_docs/version-29.4/ECMAScriptModules.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-id: ecmascript-modules
-title: ECMAScript Modules
----
-
-:::caution
-
-Jest ships with **experimental** support for ECMAScript Modules (ESM).
-
-The implementation may have bugs and lack features. For the latest status check out the [issue](https://github.com/jestjs/jest/issues/9430) and the [label](https://github.com/jestjs/jest/labels/ES%20Modules) on the issue tracker.
-
-Also note that the APIs Jest uses to implement ESM support are still [considered experimental by Node](https://nodejs.org/api/vm.html#vm_class_vm_module) (as of version `18.8.0`).
-
-:::
-
-With the warnings out of the way, this is how you activate ESM support in your tests.
-
-1. Ensure you either disable [code transforms](Configuration.md#transform-objectstring-pathtotransformer--pathtotransformer-object) by passing `transform: {}` or otherwise configure your transformer to emit ESM rather than the default CommonJS (CJS).
-1. Execute `node` with `--experimental-vm-modules`, e.g. `node --experimental-vm-modules node_modules/jest/bin/jest.js` or `NODE_OPTIONS="$NODE_OPTIONS --experimental-vm-modules" npx jest` etc.
-
- On Windows, you can use [`cross-env`](https://github.com/kentcdodds/cross-env) to be able to set environment variables.
-
- If you use Yarn, you can use `yarn node --experimental-vm-modules $(yarn bin jest)`. This command will also work if you use [Yarn Plug'n'Play](https://yarnpkg.com/features/pnp).
-
- If your codebase includes ESM imports from `*.wasm` files, you do _not_ need to pass `--experimental-wasm-modules` to `node`. Current implementation of WebAssembly imports in Jest relies on experimental VM modules, however, this may change in the future.
-
-1. Beyond that, we attempt to follow `node`'s logic for activating "ESM mode" (such as looking at `type` in `package.json` or `.mjs` files), see [their docs](https://nodejs.org/api/esm.html#esm_enabling) for details.
-1. If you want to treat other file extensions (such as `.jsx` or `.ts`) as ESM, please use the [`extensionsToTreatAsEsm` option](Configuration.md#extensionstotreatasesm-arraystring).
-
-## Differences between ESM and CommonJS
-
-Most of the differences are explained in [Node's documentation](https://nodejs.org/api/esm.html#esm_differences_between_es_modules_and_commonjs), but in addition to the things mentioned there, Jest injects a special variable into all executed files - the [`jest` object](JestObjectAPI.md). To access this object in ESM, you need to import it from the `@jest/globals` module or use `import.meta`.
-
-```js
-import {jest} from '@jest/globals';
-
-jest.useFakeTimers();
-
-// etc.
-
-// alternatively
-import.meta.jest.useFakeTimers();
-
-// jest === import.meta.jest => true
-```
-
-## Module mocking in ESM
-
-Since ESM evaluates static `import` statements before looking at the code, the hoisting of `jest.mock` calls that happens in CJS won't work for ESM. To mock modules in ESM, you need to use `require` or dynamic `import()` after `jest.mock` calls to load the mocked modules - the same applies to modules which load the mocked modules.
-
-ESM mocking is supported through `jest.unstable_mockModule`. As the name suggests, this API is still work in progress, please follow [this issue](https://github.com/jestjs/jest/issues/10025) for updates.
-
-The usage of `jest.unstable_mockModule` is essentially the same as `jest.mock` with two differences: the factory function is required and it can be sync or async:
-
-```js
-import {jest} from '@jest/globals';
-
-jest.unstable_mockModule('node:child_process', () => ({
- execSync: jest.fn(),
- // etc.
-}));
-
-const {execSync} = await import('node:child_process');
-
-// etc.
-```
-
-For mocking CJS modules, you should continue to use `jest.mock`. See the example below:
-
-```js title="main.cjs"
-const {BrowserWindow, app} = require('electron');
-
-// etc.
-
-module.exports = {example};
-```
-
-```js title="main.test.cjs"
-import {createRequire} from 'node:module';
-import {jest} from '@jest/globals';
-
-const require = createRequire(import.meta.url);
-
-jest.mock('electron', () => ({
- app: {
- on: jest.fn(),
- whenReady: jest.fn(() => Promise.resolve()),
- },
- BrowserWindow: jest.fn().mockImplementation(() => ({
- // partial mocks.
- })),
-}));
-
-const {BrowserWindow} = require('electron');
-const exported = require('./main.cjs');
-
-// alternatively
-const {BrowserWindow} = (await import('electron')).default;
-const exported = await import('./main.cjs');
-
-// etc.
-```
diff --git a/website/versioned_docs/version-29.4/GlobalAPI.md b/website/versioned_docs/version-29.4/GlobalAPI.md
deleted file mode 100644
index 0772b528f0d0..000000000000
--- a/website/versioned_docs/version-29.4/GlobalAPI.md
+++ /dev/null
@@ -1,1081 +0,0 @@
----
-id: api
-title: Globals
----
-
-In your test files, Jest puts each of these methods and objects into the global environment. You don't have to require or import anything to use them. However, if you prefer explicit imports, you can do `import {describe, expect, test} from '@jest/globals'`.
-
-import TypeScriptExamplesNote from './_TypeScriptExamplesNote.md';
-
-
-
-## Methods
-
-import TOCInline from '@theme/TOCInline';
-
-
-
----
-
-## Reference
-
-### `afterAll(fn, timeout)`
-
-Runs a function after all the tests in this file have completed. If the function returns a promise or is a generator, Jest waits for that promise to resolve before continuing.
-
-Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
-
-This is often useful if you want to clean up some global setup state that is shared across tests.
-
-For example:
-
-```js
-const globalDatabase = makeGlobalDatabase();
-
-function cleanUpDatabase(db) {
- db.cleanUp();
-}
-
-afterAll(() => {
- cleanUpDatabase(globalDatabase);
-});
-
-test('can find things', () => {
- return globalDatabase.find('thing', {}, results => {
- expect(results.length).toBeGreaterThan(0);
- });
-});
-
-test('can insert a thing', () => {
- return globalDatabase.insert('thing', makeThing(), response => {
- expect(response.success).toBeTruthy();
- });
-});
-```
-
-Here the `afterAll` ensures that `cleanUpDatabase` is called after all tests run.
-
-If `afterAll` is inside a `describe` block, it runs at the end of the describe block.
-
-If you want to run some cleanup after every test instead of after all tests, use `afterEach` instead.
-
-### `afterEach(fn, timeout)`
-
-Runs a function after each one of the tests in this file completes. If the function returns a promise or is a generator, Jest waits for that promise to resolve before continuing.
-
-Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
-
-This is often useful if you want to clean up some temporary state that is created by each test.
-
-For example:
-
-```js
-const globalDatabase = makeGlobalDatabase();
-
-function cleanUpDatabase(db) {
- db.cleanUp();
-}
-
-afterEach(() => {
- cleanUpDatabase(globalDatabase);
-});
-
-test('can find things', () => {
- return globalDatabase.find('thing', {}, results => {
- expect(results.length).toBeGreaterThan(0);
- });
-});
-
-test('can insert a thing', () => {
- return globalDatabase.insert('thing', makeThing(), response => {
- expect(response.success).toBeTruthy();
- });
-});
-```
-
-Here the `afterEach` ensures that `cleanUpDatabase` is called after each test runs.
-
-If `afterEach` is inside a `describe` block, it only runs after the tests that are inside this describe block.
-
-If you want to run some cleanup just once, after all of the tests run, use `afterAll` instead.
-
-### `beforeAll(fn, timeout)`
-
-Runs a function before any of the tests in this file run. If the function returns a promise or is a generator, Jest waits for that promise to resolve before running tests.
-
-Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
-
-This is often useful if you want to set up some global state that will be used by many tests.
-
-For example:
-
-```js
-const globalDatabase = makeGlobalDatabase();
-
-beforeAll(() => {
- // Clears the database and adds some testing data.
- // Jest will wait for this promise to resolve before running tests.
- return globalDatabase.clear().then(() => {
- return globalDatabase.insert({testData: 'foo'});
- });
-});
-
-// Since we only set up the database once in this example, it's important
-// that our tests don't modify it.
-test('can find things', () => {
- return globalDatabase.find('thing', {}, results => {
- expect(results.length).toBeGreaterThan(0);
- });
-});
-```
-
-Here the `beforeAll` ensures that the database is set up before tests run. If setup was synchronous, you could do this without `beforeAll`. The key is that Jest will wait for a promise to resolve, so you can have asynchronous setup as well.
-
-If `beforeAll` is inside a `describe` block, it runs at the beginning of the describe block.
-
-If you want to run something before every test instead of before any test runs, use `beforeEach` instead.
-
-### `beforeEach(fn, timeout)`
-
-Runs a function before each of the tests in this file runs. If the function returns a promise or is a generator, Jest waits for that promise to resolve before running the test.
-
-Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
-
-This is often useful if you want to reset some global state that will be used by many tests.
-
-For example:
-
-```js
-const globalDatabase = makeGlobalDatabase();
-
-beforeEach(() => {
- // Clears the database and adds some testing data.
- // Jest will wait for this promise to resolve before running tests.
- return globalDatabase.clear().then(() => {
- return globalDatabase.insert({testData: 'foo'});
- });
-});
-
-test('can find things', () => {
- return globalDatabase.find('thing', {}, results => {
- expect(results.length).toBeGreaterThan(0);
- });
-});
-
-test('can insert a thing', () => {
- return globalDatabase.insert('thing', makeThing(), response => {
- expect(response.success).toBeTruthy();
- });
-});
-```
-
-Here the `beforeEach` ensures that the database is reset for each test.
-
-If `beforeEach` is inside a `describe` block, it runs for each test in the describe block.
-
-If you only need to run some setup code once, before any tests run, use `beforeAll` instead.
-
-### `describe(name, fn)`
-
-`describe(name, fn)` creates a block that groups together several related tests. For example, if you have a `myBeverage` object that is supposed to be delicious but not sour, you could test it with:
-
-```js
-const myBeverage = {
- delicious: true,
- sour: false,
-};
-
-describe('my beverage', () => {
- test('is delicious', () => {
- expect(myBeverage.delicious).toBeTruthy();
- });
-
- test('is not sour', () => {
- expect(myBeverage.sour).toBeFalsy();
- });
-});
-```
-
-This isn't required - you can write the `test` blocks directly at the top level. But this can be handy if you prefer your tests to be organized into groups.
-
-You can also nest `describe` blocks if you have a hierarchy of tests:
-
-```js
-const binaryStringToNumber = binString => {
- if (!/^[01]+$/.test(binString)) {
- throw new CustomError('Not a binary number.');
- }
-
- return parseInt(binString, 2);
-};
-
-describe('binaryStringToNumber', () => {
- describe('given an invalid binary string', () => {
- test('composed of non-numbers throws CustomError', () => {
- expect(() => binaryStringToNumber('abc')).toThrow(CustomError);
- });
-
- test('with extra whitespace throws CustomError', () => {
- expect(() => binaryStringToNumber(' 100')).toThrow(CustomError);
- });
- });
-
- describe('given a valid binary string', () => {
- test('returns the correct number', () => {
- expect(binaryStringToNumber('100')).toBe(4);
- });
- });
-});
-```
-
-### `describe.each(table)(name, fn, timeout)`
-
-Use `describe.each` if you keep duplicating the same test suites with different data. `describe.each` allows you to write the test suite once and pass data in.
-
-`describe.each` is available with two APIs:
-
-#### 1. `describe.each(table)(name, fn, timeout)`
-
-- `table`: `Array` of Arrays with the arguments that are passed into the `fn` for each row. If you pass in a 1D array of primitives, internally it will be mapped to a table i.e. `[1, 2, 3] -> [[1], [2], [3]]`.
-
-- `name`: `String` the title of the test suite.
- - Generate unique test titles by positionally injecting parameters with [`printf` formatting](https://nodejs.org/api/util.html#util_util_format_format_args):
- - `%p` - [pretty-format](https://www.npmjs.com/package/pretty-format).
- - `%s`- String.
- - `%d`- Number.
- - `%i` - Integer.
- - `%f` - Floating point value.
- - `%j` - JSON.
- - `%o` - Object.
- - `%#` - Index of the test case.
- - `%%` - single percent sign ('%'). This does not consume an argument.
- - Or generate unique test titles by injecting properties of test case object with `$variable`
- - To inject nested object values use you can supply a keyPath i.e. `$variable.path.to.value` (only works for ["own" properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty), e.g. `$variable.constructor.name` wouldn't work)
- - You can use `$#` to inject the index of the test case
- - You cannot use `$variable` with the `printf` formatting except for `%%`
-- `fn`: `Function` the suite of tests to be run, this is the function that will receive the parameters in each row as function arguments.
-- Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait for each row before aborting. The default timeout is 5 seconds.
-
-Example:
-
-```js
-describe.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', (a, b, expected) => {
- test(`returns ${expected}`, () => {
- expect(a + b).toBe(expected);
- });
-
- test(`returned value not be greater than ${expected}`, () => {
- expect(a + b).not.toBeGreaterThan(expected);
- });
-
- test(`returned value not be less than ${expected}`, () => {
- expect(a + b).not.toBeLessThan(expected);
- });
-});
-```
-
-```js
-describe.each([
- {a: 1, b: 1, expected: 2},
- {a: 1, b: 2, expected: 3},
- {a: 2, b: 1, expected: 3},
-])('.add($a, $b)', ({a, b, expected}) => {
- test(`returns ${expected}`, () => {
- expect(a + b).toBe(expected);
- });
-
- test(`returned value not be greater than ${expected}`, () => {
- expect(a + b).not.toBeGreaterThan(expected);
- });
-
- test(`returned value not be less than ${expected}`, () => {
- expect(a + b).not.toBeLessThan(expected);
- });
-});
-```
-
-#### 2. ``describe.each`table`(name, fn, timeout)``
-
-- `table`: `Tagged Template Literal`
- - First row of variable name column headings separated with `|`
- - One or more subsequent rows of data supplied as template literal expressions using `${value}` syntax.
-- `name`: `String` the title of the test suite, use `$variable` to inject test data into the suite title from the tagged template expressions, and `$#` for the index of the row.
- - To inject nested object values use you can supply a keyPath i.e. `$variable.path.to.value` (only works for ["own" properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty), e.g. `$variable.constructor.name` wouldn't work)
-- `fn`: `Function` the suite of tests to be run, this is the function that will receive the test data object.
-- Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait for each row before aborting. The default timeout is 5 seconds.
-
-Example:
-
-```js
-describe.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('$a + $b', ({a, b, expected}) => {
- test(`returns ${expected}`, () => {
- expect(a + b).toBe(expected);
- });
-
- test(`returned value not be greater than ${expected}`, () => {
- expect(a + b).not.toBeGreaterThan(expected);
- });
-
- test(`returned value not be less than ${expected}`, () => {
- expect(a + b).not.toBeLessThan(expected);
- });
-});
-```
-
-### `describe.only(name, fn)`
-
-Also under the alias: `fdescribe(name, fn)`
-
-You can use `describe.only` if you want to run only one describe block:
-
-```js
-describe.only('my beverage', () => {
- test('is delicious', () => {
- expect(myBeverage.delicious).toBeTruthy();
- });
-
- test('is not sour', () => {
- expect(myBeverage.sour).toBeFalsy();
- });
-});
-
-describe('my other beverage', () => {
- // ... will be skipped
-});
-```
-
-### `describe.only.each(table)(name, fn)`
-
-Also under the aliases: `fdescribe.each(table)(name, fn)` and ``fdescribe.each`table`(name, fn)``
-
-Use `describe.only.each` if you want to only run specific tests suites of data driven tests.
-
-`describe.only.each` is available with two APIs:
-
-#### `describe.only.each(table)(name, fn)`
-
-```js
-describe.only.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', (a, b, expected) => {
- test(`returns ${expected}`, () => {
- expect(a + b).toBe(expected);
- });
-});
-
-test('will not be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-#### ``describe.only.each`table`(name, fn)``
-
-```js
-describe.only.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('returns $expected when $a is added to $b', ({a, b, expected}) => {
- test('passes', () => {
- expect(a + b).toBe(expected);
- });
-});
-
-test('will not be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-### `describe.skip(name, fn)`
-
-Also under the alias: `xdescribe(name, fn)`
-
-You can use `describe.skip` if you do not want to run the tests of a particular `describe` block:
-
-```js
-describe('my beverage', () => {
- test('is delicious', () => {
- expect(myBeverage.delicious).toBeTruthy();
- });
-
- test('is not sour', () => {
- expect(myBeverage.sour).toBeFalsy();
- });
-});
-
-describe.skip('my other beverage', () => {
- // ... will be skipped
-});
-```
-
-Using `describe.skip` is often a cleaner alternative to temporarily commenting out a chunk of tests. Beware that the `describe` block will still run. If you have some setup that also should be skipped, do it in a `beforeAll` or `beforeEach` block.
-
-### `describe.skip.each(table)(name, fn)`
-
-Also under the aliases: `xdescribe.each(table)(name, fn)` and ``xdescribe.each`table`(name, fn)``
-
-Use `describe.skip.each` if you want to stop running a suite of data driven tests.
-
-`describe.skip.each` is available with two APIs:
-
-#### `describe.skip.each(table)(name, fn)`
-
-```js
-describe.skip.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', (a, b, expected) => {
- test(`returns ${expected}`, () => {
- expect(a + b).toBe(expected); // will not be run
- });
-});
-
-test('will be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-#### ``describe.skip.each`table`(name, fn)``
-
-```js
-describe.skip.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('returns $expected when $a is added to $b', ({a, b, expected}) => {
- test('will not be run', () => {
- expect(a + b).toBe(expected); // will not be run
- });
-});
-
-test('will be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-### `test(name, fn, timeout)`
-
-Also under the alias: `it(name, fn, timeout)`
-
-All you need in a test file is the `test` method which runs a test. For example, let's say there's a function `inchesOfRain()` that should be zero. Your whole test could be:
-
-```js
-test('did not rain', () => {
- expect(inchesOfRain()).toBe(0);
-});
-```
-
-The first argument is the test name; the second argument is a function that contains the expectations to test. The third argument (optional) is `timeout` (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
-
-If a **promise is returned** from `test`, Jest will wait for the promise to resolve before letting the test complete. For example, let's say `fetchBeverageList()` returns a promise that is supposed to resolve to a list that has `lemon` in it. You can test this with:
-
-```js
-test('has lemon in it', () => {
- return fetchBeverageList().then(list => {
- expect(list).toContain('lemon');
- });
-});
-```
-
-Even though the call to `test` will return right away, the test doesn't complete until the promise resolves. For more details, see [Testing Asynchronous Code](TestingAsyncCode.md) page.
-
-:::tip
-
-Jest will also wait if you **provide an argument to the test function**, usually called `done`. This could be handy when you want to test [callbacks](TestingAsyncCode.md#callbacks).
-
-:::
-
-### `test.concurrent(name, fn, timeout)`
-
-Also under the alias: `it.concurrent(name, fn, timeout)`
-
-:::caution
-
-`test.concurrent` is considered experimental - see [here](https://github.com/jestjs/jest/labels/Area%3A%20Concurrent) for details on missing features and other issues.
-
-:::
-
-Use `test.concurrent` if you want the test to run concurrently.
-
-The first argument is the test name; the second argument is an asynchronous function that contains the expectations to test. The third argument (optional) is `timeout` (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
-
-```js
-test.concurrent('addition of 2 numbers', async () => {
- expect(5 + 3).toBe(8);
-});
-
-test.concurrent('subtraction 2 numbers', async () => {
- expect(5 - 3).toBe(2);
-});
-```
-
-:::tip
-
-Use the [`maxConcurrency`](Configuration.md#maxconcurrency-number) configuration option to prevent Jest from executing more than the specified amount of tests at the same time.
-
-:::
-
-### `test.concurrent.each(table)(name, fn, timeout)`
-
-Also under the alias: `it.concurrent.each(table)(name, fn, timeout)`
-
-Use `test.concurrent.each` if you keep duplicating the same test with different data. `test.each` allows you to write the test once and pass data in, the tests are all run asynchronously.
-
-`test.concurrent.each` is available with two APIs:
-
-#### 1. `test.concurrent.each(table)(name, fn, timeout)`
-
-- `table`: `Array` of Arrays with the arguments that are passed into the test `fn` for each row. If you pass in a 1D array of primitives, internally it will be mapped to a table i.e. `[1, 2, 3] -> [[1], [2], [3]]`
-- `name`: `String` the title of the test block.
- - Generate unique test titles by positionally injecting parameters with [`printf` formatting](https://nodejs.org/api/util.html#util_util_format_format_args):
- - `%p` - [pretty-format](https://www.npmjs.com/package/pretty-format).
- - `%s`- String.
- - `%d`- Number.
- - `%i` - Integer.
- - `%f` - Floating point value.
- - `%j` - JSON.
- - `%o` - Object.
- - `%#` - Index of the test case.
- - `%%` - single percent sign ('%'). This does not consume an argument.
-- `fn`: `Function` the test to be run, this is the function that will receive the parameters in each row as function arguments, **this will have to be an asynchronous function**.
-- Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait for each row before aborting. The default timeout is 5 seconds.
-
-Example:
-
-```js
-test.concurrent.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', async (a, b, expected) => {
- expect(a + b).toBe(expected);
-});
-```
-
-#### 2. ``test.concurrent.each`table`(name, fn, timeout)``
-
-- `table`: `Tagged Template Literal`
- - First row of variable name column headings separated with `|`
- - One or more subsequent rows of data supplied as template literal expressions using `${value}` syntax.
-- `name`: `String` the title of the test, use `$variable` to inject test data into the test title from the tagged template expressions.
- - To inject nested object values use you can supply a keyPath i.e. `$variable.path.to.value` (only works for ["own" properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty), e.g. `$variable.constructor.name` wouldn't work)
-- `fn`: `Function` the test to be run, this is the function that will receive the test data object, **this will have to be an asynchronous function**.
-- Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait for each row before aborting. The default timeout is 5 seconds.
-
-Example:
-
-```js
-test.concurrent.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('returns $expected when $a is added to $b', async ({a, b, expected}) => {
- expect(a + b).toBe(expected);
-});
-```
-
-### `test.concurrent.only.each(table)(name, fn)`
-
-Also under the alias: `it.concurrent.only.each(table)(name, fn)`
-
-Use `test.concurrent.only.each` if you want to only run specific tests with different test data concurrently.
-
-`test.concurrent.only.each` is available with two APIs:
-
-#### `test.concurrent.only.each(table)(name, fn)`
-
-```js
-test.concurrent.only.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', async (a, b, expected) => {
- expect(a + b).toBe(expected);
-});
-
-test('will not be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-#### ``test.only.each`table`(name, fn)``
-
-```js
-test.concurrent.only.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('returns $expected when $a is added to $b', async ({a, b, expected}) => {
- expect(a + b).toBe(expected);
-});
-
-test('will not be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-### `test.concurrent.skip.each(table)(name, fn)`
-
-Also under the alias: `it.concurrent.skip.each(table)(name, fn)`
-
-Use `test.concurrent.skip.each` if you want to stop running a collection of asynchronous data driven tests.
-
-`test.concurrent.skip.each` is available with two APIs:
-
-#### `test.concurrent.skip.each(table)(name, fn)`
-
-```js
-test.concurrent.skip.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', async (a, b, expected) => {
- expect(a + b).toBe(expected); // will not be run
-});
-
-test('will be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-#### ``test.concurrent.skip.each`table`(name, fn)``
-
-```js
-test.concurrent.skip.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('returns $expected when $a is added to $b', async ({a, b, expected}) => {
- expect(a + b).toBe(expected); // will not be run
-});
-
-test('will be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-### `test.each(table)(name, fn, timeout)`
-
-Also under the alias: `it.each(table)(name, fn)` and ``it.each`table`(name, fn)``
-
-Use `test.each` if you keep duplicating the same test with different data. `test.each` allows you to write the test once and pass data in.
-
-`test.each` is available with two APIs:
-
-#### 1. `test.each(table)(name, fn, timeout)`
-
-- `table`: `Array` of Arrays with the arguments that are passed into the test `fn` for each row. If you pass in a 1D array of primitives, internally it will be mapped to a table i.e. `[1, 2, 3] -> [[1], [2], [3]]`
-- `name`: `String` the title of the test block.
- - Generate unique test titles by positionally injecting parameters with [`printf` formatting](https://nodejs.org/api/util.html#util_util_format_format_args):
- - `%p` - [pretty-format](https://www.npmjs.com/package/pretty-format).
- - `%s`- String.
- - `%d`- Number.
- - `%i` - Integer.
- - `%f` - Floating point value.
- - `%j` - JSON.
- - `%o` - Object.
- - `%#` - Index of the test case.
- - `%%` - single percent sign ('%'). This does not consume an argument.
- - Or generate unique test titles by injecting properties of test case object with `$variable`
- - To inject nested object values use you can supply a keyPath i.e. `$variable.path.to.value` (only works for ["own" properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty), e.g. `$variable.constructor.name` wouldn't work)
- - You can use `$#` to inject the index of the test case
- - You cannot use `$variable` with the `printf` formatting except for `%%`
-- `fn`: `Function` the test to be run, this is the function that will receive the parameters in each row as function arguments.
-- Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait for each row before aborting. The default timeout is 5 seconds.
-
-Example:
-
-```js
-test.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', (a, b, expected) => {
- expect(a + b).toBe(expected);
-});
-```
-
-```js
-test.each([
- {a: 1, b: 1, expected: 2},
- {a: 1, b: 2, expected: 3},
- {a: 2, b: 1, expected: 3},
-])('.add($a, $b)', ({a, b, expected}) => {
- expect(a + b).toBe(expected);
-});
-```
-
-#### 2. ``test.each`table`(name, fn, timeout)``
-
-- `table`: `Tagged Template Literal`
- - First row of variable name column headings separated with `|`
- - One or more subsequent rows of data supplied as template literal expressions using `${value}` syntax.
-- `name`: `String` the title of the test, use `$variable` to inject test data into the test title from the tagged template expressions.
- - To inject nested object values use you can supply a keyPath i.e. `$variable.path.to.value` (only works for ["own" properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty), e.g. `$variable.constructor.name` wouldn't work)
-- `fn`: `Function` the test to be run, this is the function that will receive the test data object.
-- Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait for each row before aborting. The default timeout is 5 seconds.
-
-Example:
-
-```js
-test.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('returns $expected when $a is added to $b', ({a, b, expected}) => {
- expect(a + b).toBe(expected);
-});
-```
-
-### `test.failing(name, fn, timeout)`
-
-Also under the alias: `it.failing(name, fn, timeout)`
-
-:::note
-
-This is only available with the default [jest-circus](https://github.com/jestjs/jest/tree/main/packages/jest-circus) runner.
-
-:::
-
-Use `test.failing` when you are writing a test and expecting it to fail. These tests will behave the other way normal tests do. If `failing` test will throw any errors then it will pass. If it does not throw it will fail.
-
-:::tip
-
-You can use this type of test i.e. when writing code in a BDD way. In that case the tests will not show up as failing until they pass. Then you can just remove the `failing` modifier to make them pass.
-
-It can also be a nice way to contribute failing tests to a project, even if you don't know how to fix the bug.
-
-:::
-
-Example:
-
-```js
-test.failing('it is not equal', () => {
- expect(5).toBe(6); // this test will pass
-});
-
-test.failing('it is equal', () => {
- expect(10).toBe(10); // this test will fail
-});
-```
-
-### `test.failing.each(name, fn, timeout)`
-
-Also under the alias: `it.failing.each(table)(name, fn)` and ``it.failing.each`table`(name, fn)``
-
-:::note
-
-This is only available with the default [jest-circus](https://github.com/jestjs/jest/tree/main/packages/jest-circus) runner.
-
-:::
-
-You can also run multiple tests at once by adding `each` after `failing`.
-
-Example:
-
-```js
-test.failing.each([
- {a: 1, b: 1, expected: 2},
- {a: 1, b: 2, expected: 3},
- {a: 2, b: 1, expected: 3},
-])('.add($a, $b)', ({a, b, expected}) => {
- expect(a + b).toBe(expected);
-});
-```
-
-### `test.only.failing(name, fn, timeout)`
-
-Also under the aliases: `it.only.failing(name, fn, timeout)`, `fit.failing(name, fn, timeout)`
-
-:::note
-
-This is only available with the default [jest-circus](https://github.com/jestjs/jest/tree/main/packages/jest-circus) runner.
-
-:::
-
-Use `test.only.failing` if you want to only run a specific failing test.
-
-### `test.skip.failing(name, fn, timeout)`
-
-Also under the aliases: `it.skip.failing(name, fn, timeout)`, `xit.failing(name, fn, timeout)`, `xtest.failing(name, fn, timeout)`
-
-:::note
-
-This is only available with the default [jest-circus](https://github.com/jestjs/jest/tree/main/packages/jest-circus) runner.
-
-:::
-
-Use `test.skip.failing` if you want to skip running a specific failing test.
-
-### `test.only(name, fn, timeout)`
-
-Also under the aliases: `it.only(name, fn, timeout)`, and `fit(name, fn, timeout)`
-
-When you are debugging a large test file, you will often only want to run a subset of tests. You can use `.only` to specify which tests are the only ones you want to run in that test file.
-
-Optionally, you can provide a `timeout` (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
-
-For example, let's say you had these tests:
-
-```js
-test.only('it is raining', () => {
- expect(inchesOfRain()).toBeGreaterThan(0);
-});
-
-test('it is not snowing', () => {
- expect(inchesOfSnow()).toBe(0);
-});
-```
-
-Only the "it is raining" test will run in that test file, since it is run with `test.only`.
-
-Usually you wouldn't check code using `test.only` into source control - you would use it for debugging, and remove it once you have fixed the broken tests.
-
-### `test.only.each(table)(name, fn)`
-
-Also under the aliases: `it.only.each(table)(name, fn)`, `fit.each(table)(name, fn)`, ``it.only.each`table`(name, fn)`` and ``fit.each`table`(name, fn)``
-
-Use `test.only.each` if you want to only run specific tests with different test data.
-
-`test.only.each` is available with two APIs:
-
-#### `test.only.each(table)(name, fn)`
-
-```js
-test.only.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', (a, b, expected) => {
- expect(a + b).toBe(expected);
-});
-
-test('will not be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-#### ``test.only.each`table`(name, fn)``
-
-```js
-test.only.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('returns $expected when $a is added to $b', ({a, b, expected}) => {
- expect(a + b).toBe(expected);
-});
-
-test('will not be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-### `test.skip(name, fn)`
-
-Also under the aliases: `it.skip(name, fn)`, `xit(name, fn)`, and `xtest(name, fn)`
-
-When you are maintaining a large codebase, you may sometimes find a test that is temporarily broken for some reason. If you want to skip running this test, but you don't want to delete this code, you can use `test.skip` to specify some tests to skip.
-
-For example, let's say you had these tests:
-
-```js
-test('it is raining', () => {
- expect(inchesOfRain()).toBeGreaterThan(0);
-});
-
-test.skip('it is not snowing', () => {
- expect(inchesOfSnow()).toBe(0);
-});
-```
-
-Only the "it is raining" test will run, since the other test is run with `test.skip`.
-
-You could comment the test out, but it's often a bit nicer to use `test.skip` because it will maintain indentation and syntax highlighting.
-
-### `test.skip.each(table)(name, fn)`
-
-Also under the aliases: `it.skip.each(table)(name, fn)`, `xit.each(table)(name, fn)`, `xtest.each(table)(name, fn)`, ``it.skip.each`table`(name, fn)``, ``xit.each`table`(name, fn)`` and ``xtest.each`table`(name, fn)``
-
-Use `test.skip.each` if you want to stop running a collection of data driven tests.
-
-`test.skip.each` is available with two APIs:
-
-#### `test.skip.each(table)(name, fn)`
-
-```js
-test.skip.each([
- [1, 1, 2],
- [1, 2, 3],
- [2, 1, 3],
-])('.add(%i, %i)', (a, b, expected) => {
- expect(a + b).toBe(expected); // will not be run
-});
-
-test('will be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-#### ``test.skip.each`table`(name, fn)``
-
-```js
-test.skip.each`
- a | b | expected
- ${1} | ${1} | ${2}
- ${1} | ${2} | ${3}
- ${2} | ${1} | ${3}
-`('returns $expected when $a is added to $b', ({a, b, expected}) => {
- expect(a + b).toBe(expected); // will not be run
-});
-
-test('will be run', () => {
- expect(1 / 0).toBe(Infinity);
-});
-```
-
-### `test.todo(name)`
-
-Also under the alias: `it.todo(name)`
-
-Use `test.todo` when you are planning on writing tests. These tests will be highlighted in the summary output at the end so you know how many tests you still need todo.
-
-```js
-const add = (a, b) => a + b;
-
-test.todo('add should be associative');
-```
-
-:::tip
-
-`test.todo` will throw an error if you pass it a test callback function. Use [`test.skip`](#testskipname-fn) instead, if you already implemented the test, but do not want it to run.
-
-:::
-
-## TypeScript Usage
-
-
-
-### `.each`
-
-The `.each` modifier offers few different ways to define a table of the test cases. Some of the APIs have caveats related with the type inference of the arguments which are passed to `describe` or `test` callback functions. Let's take a look at each of them.
-
-:::note
-
-For simplicity `test.each` is picked for the examples, but the type inference is identical in all cases where `.each` modifier can be used: `describe.each`, `test.concurrent.only.each`, `test.skip.each`, etc.
-
-:::
-
-#### Array of objects
-
-The array of objects API is most verbose, but it makes the type inference a painless task. A `table` can be inlined:
-
-```ts
-import {test} from '@jest/globals';
-
-test.each([
- {name: 'a', path: 'path/to/a', count: 1, write: true},
- {name: 'b', path: 'path/to/b', count: 3},
-])('inline table', ({name, path, count, write}) => {
- // arguments are typed as expected, e.g. `write: boolean | undefined`
-});
-```
-
-Or declared separately as a variable:
-
-```ts
-import {test} from '@jest/globals';
-
-const table = [
- {a: 1, b: 2, expected: 'three', extra: true},
- {a: 3, b: 4, expected: 'seven', extra: false},
- {a: 5, b: 6, expected: 'eleven'},
-];
-
-test.each(table)('table as a variable', ({a, b, expected, extra}) => {
- // again everything is typed as expected, e.g. `extra: boolean | undefined`
-});
-```
-
-#### Array of arrays
-
-The array of arrays style will work smoothly with inlined tables:
-
-```ts
-import {test} from '@jest/globals';
-
-test.each([
- [1, 2, 'three', true],
- [3, 4, 'seven', false],
- [5, 6, 'eleven'],
-])('inline table example', (a, b, expected, extra) => {
- // arguments are typed as expected, e.g. `extra: boolean | undefined`
-});
-```
-
-However, if a table is declared as a separate variable, it must be typed as an array of tuples for correct type inference (this is not needed only if all elements of a row are of the same type):
-
-```ts
-import {test} from '@jest/globals';
-
-const table: Array<[number, number, string, boolean?]> = [
- [1, 2, 'three', true],
- [3, 4, 'seven', false],
- [5, 6, 'eleven'],
-];
-
-test.each(table)('table as a variable example', (a, b, expected, extra) => {
- // without the annotation types are incorrect, e.g. `a: number | string | boolean`
-});
-```
-
-#### Template literal
-
-If all values are of the same type, the template literal API will type the arguments correctly:
-
-```ts
-import {test} from '@jest/globals';
-
-test.each`
- a | b | expected
- ${1} | ${2} | ${3}
- ${3} | ${4} | ${7}
- ${5} | ${6} | ${11}
-`('template literal example', ({a, b, expected}) => {
- // all arguments are of type `number`
-});
-```
-
-Otherwise it will require a generic type argument:
-
-```ts
-import {test} from '@jest/globals';
-
-test.each<{a: number; b: number; expected: string; extra?: boolean}>`
- a | b | expected | extra
- ${1} | ${2} | ${'three'} | ${true}
- ${3} | ${4} | ${'seven'} | ${false}
- ${5} | ${6} | ${'eleven'}
-`('template literal example', ({a, b, expected, extra}) => {
- // without the generic argument in this case types would default to `unknown`
-});
-```
diff --git a/website/versioned_docs/version-29.4/JestObjectAPI.md b/website/versioned_docs/version-29.4/JestObjectAPI.md
deleted file mode 100644
index 062988f2600b..000000000000
--- a/website/versioned_docs/version-29.4/JestObjectAPI.md
+++ /dev/null
@@ -1,1054 +0,0 @@
----
-id: jest-object
-title: The Jest Object
----
-
-The `jest` object is automatically in scope within every test file. The methods in the `jest` object help create mocks and let you control Jest's overall behavior. It can also be imported explicitly by via `import {jest} from '@jest/globals'`.
-
-import TypeScriptExamplesNote from './_TypeScriptExamplesNote.md';
-
-
-
-## Methods
-
-import TOCInline from '@theme/TOCInline';
-
-
-
----
-
-## Mock Modules
-
-### `jest.disableAutomock()`
-
-Disables automatic mocking in the module loader.
-
-:::info
-
-Automatic mocking should be enabled via [`automock`](Configuration.md#automock-boolean) configuration option for this method to have any effect. Also see documentation of the configuration option for more details.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- automock: true,
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- automock: true,
-};
-
-export default config;
-```
-
-:::
-
-After `disableAutomock()` is called, all `require()`s will return the real versions of each module (rather than a mocked version).
-
-```js title="utils.js"
-export default {
- authorize: () => {
- return 'token';
- },
-};
-```
-
-```js title="__tests__/disableAutomocking.js"
-import utils from '../utils';
-
-jest.disableAutomock();
-
-test('original implementation', () => {
- // now we have the original implementation,
- // even if we set the automocking in a jest configuration
- expect(utils.authorize()).toBe('token');
-});
-```
-
-This is usually useful when you have a scenario where the number of dependencies you want to mock is far less than the number of dependencies that you don't. For example, if you're writing a test for a module that uses a large number of dependencies that can be reasonably classified as "implementation details" of the module, then you likely do not want to mock them.
-
-Examples of dependencies that might be considered "implementation details" are things ranging from language built-ins (e.g. `Array.prototype` methods) to highly common utility methods (e.g. `underscore`, `lodash`, array utilities, etc) and entire libraries like `React.js`.
-
-Returns the `jest` object for chaining.
-
-:::tip
-
-When using `babel-jest`, calls to `disableAutomock()` will automatically be hoisted to the top of the code block. Use `autoMockOff()` if you want to explicitly avoid this behavior.
-
-:::
-
-### `jest.enableAutomock()`
-
-Enables automatic mocking in the module loader.
-
-:::info
-
-For more details on automatic mocking see documentation of [`automock`](Configuration.md#automock-boolean) configuration option.
-
-:::
-
-Example:
-
-```js title="utils.js"
-export default {
- authorize: () => {
- return 'token';
- },
- isAuthorized: secret => secret === 'wizard',
-};
-```
-
-```js title="__tests__/enableAutomocking.js"
-jest.enableAutomock();
-
-import utils from '../utils';
-
-test('original implementation', () => {
- // now we have the mocked implementation,
- expect(utils.authorize._isMockFunction).toBeTruthy();
- expect(utils.isAuthorized._isMockFunction).toBeTruthy();
-});
-```
-
-Returns the `jest` object for chaining.
-
-:::tip
-
-When using `babel-jest`, calls to `enableAutomock` will automatically be hoisted to the top of the code block. Use `autoMockOn` if you want to explicitly avoid this behavior.
-
-:::
-
-### `jest.createMockFromModule(moduleName)`
-
-Given the name of a module, use the automatic mocking system to generate a mocked version of the module for you.
-
-This is useful when you want to create a [manual mock](ManualMocks.md) that extends the automatic mock's behavior:
-
-```js tab={"span":2} title="utils.js"
-module.exports = {
- authorize: () => {
- return 'token';
- },
- isAuthorized: secret => secret === 'wizard',
-};
-```
-
-```js title="__tests__/createMockFromModule.test.js"
-const utils = jest.createMockFromModule('../utils');
-
-utils.isAuthorized = jest.fn(secret => secret === 'not wizard');
-
-test('implementation created by jest.createMockFromModule', () => {
- expect(jest.isMockFunction(utils.authorize)).toBe(true);
- expect(utils.isAuthorized('not wizard')).toBe(true);
-});
-```
-
-```ts tab={"span":2} title="utils.ts"
-export const utils = {
- authorize: () => {
- return 'token';
- },
- isAuthorized: (secret: string) => secret === 'wizard',
-};
-```
-
-```ts title="__tests__/createMockFromModule.test.ts"
-const {utils} =
- jest.createMockFromModule('../utils');
-
-utils.isAuthorized = jest.fn((secret: string) => secret === 'not wizard');
-
-test('implementation created by jest.createMockFromModule', () => {
- expect(jest.isMockFunction(utils.authorize)).toBe(true);
- expect(utils.isAuthorized('not wizard')).toBe(true);
-});
-```
-
-This is how `createMockFromModule` will mock the following data types:
-
-#### `Function`
-
-Creates a new [mock function](MockFunctionAPI.md). The new function has no formal parameters and when called will return `undefined`. This functionality also applies to `async` functions.
-
-#### `Class`
-
-Creates a new class. The interface of the original class is maintained, all of the class member functions and properties will be mocked.
-
-#### `Object`
-
-Creates a new deeply cloned object. The object keys are maintained and their values are mocked.
-
-#### `Array`
-
-Creates a new empty array, ignoring the original.
-
-#### `Primitives`
-
-Creates a new property with the same primitive value as the original property.
-
-Example:
-
-```js title="example.js"
-module.exports = {
- function: function square(a, b) {
- return a * b;
- },
- asyncFunction: async function asyncSquare(a, b) {
- const result = (await a) * b;
- return result;
- },
- class: new (class Bar {
- constructor() {
- this.array = [1, 2, 3];
- }
- foo() {}
- })(),
- object: {
- baz: 'foo',
- bar: {
- fiz: 1,
- buzz: [1, 2, 3],
- },
- },
- array: [1, 2, 3],
- number: 123,
- string: 'baz',
- boolean: true,
- symbol: Symbol.for('a.b.c'),
-};
-```
-
-```js title="__tests__/example.test.js"
-const example = jest.createMockFromModule('../example');
-
-test('should run example code', () => {
- // creates a new mocked function with no formal arguments.
- expect(example.function.name).toBe('square');
- expect(example.function).toHaveLength(0);
-
- // async functions get the same treatment as standard synchronous functions.
- expect(example.asyncFunction.name).toBe('asyncSquare');
- expect(example.asyncFunction).toHaveLength(0);
-
- // creates a new class with the same interface, member functions and properties are mocked.
- expect(example.class.constructor.name).toBe('Bar');
- expect(example.class.foo.name).toBe('foo');
- expect(example.class.array).toHaveLength(0);
-
- // creates a deeply cloned version of the original object.
- expect(example.object).toEqual({
- baz: 'foo',
- bar: {
- fiz: 1,
- buzz: [],
- },
- });
-
- // creates a new empty array, ignoring the original array.
- expect(example.array).toHaveLength(0);
-
- // creates a new property with the same primitive value as the original property.
- expect(example.number).toBe(123);
- expect(example.string).toBe('baz');
- expect(example.boolean).toBe(true);
- expect(example.symbol).toEqual(Symbol.for('a.b.c'));
-});
-```
-
-### `jest.mock(moduleName, factory, options)`
-
-Mocks a module with an auto-mocked version when it is being required. `factory` and `options` are optional. For example:
-
-```js title="banana.js"
-module.exports = () => 'banana';
-```
-
-```js title="__tests__/test.js"
-jest.mock('../banana');
-
-const banana = require('../banana'); // banana will be explicitly mocked.
-
-banana(); // will return 'undefined' because the function is auto-mocked.
-```
-
-The second argument can be used to specify an explicit module factory that is being run instead of using Jest's automocking feature:
-
-```js tab
-jest.mock('../moduleName', () => {
- return jest.fn(() => 42);
-});
-
-// This runs the function specified as second argument to `jest.mock`.
-const moduleName = require('../moduleName');
-moduleName(); // Will return '42';
-```
-
-```ts tab
-// The optional type argument provides typings for the module factory
-jest.mock('../moduleName', () => {
- return jest.fn(() => 42);
-});
-
-// This runs the function specified as second argument to `jest.mock`.
-const moduleName = require('../moduleName');
-moduleName(); // Will return '42';
-```
-
-When using the `factory` parameter for an ES6 module with a default export, the `__esModule: true` property needs to be specified. This property is normally generated by Babel / TypeScript, but here it needs to be set manually. When importing a default export, it's an instruction to import the property named `default` from the export object:
-
-```js
-import moduleName, {foo} from '../moduleName';
-
-jest.mock('../moduleName', () => {
- return {
- __esModule: true,
- default: jest.fn(() => 42),
- foo: jest.fn(() => 43),
- };
-});
-
-moduleName(); // Will return 42
-foo(); // Will return 43
-```
-
-The third argument can be used to create virtual mocks – mocks of modules that don't exist anywhere in the system:
-
-```js
-jest.mock(
- '../moduleName',
- () => {
- /*
- * Custom implementation of a module that doesn't exist in JS,
- * like a generated module or a native module in react-native.
- */
- },
- {virtual: true},
-);
-```
-
-:::caution
-
-Importing a module in a setup file (as specified by [`setupFilesAfterEnv`](Configuration.md#setupfilesafterenv-array)) will prevent mocking for the module in question, as well as all the modules that it imports.
-
-:::
-
-Modules that are mocked with `jest.mock` are mocked only for the file that calls `jest.mock`. Another file that imports the module will get the original implementation even if it runs after the test file that mocks the module.
-
-Returns the `jest` object for chaining.
-
-:::tip
-
-Writing tests in TypeScript? Use the [`jest.Mocked`](MockFunctionAPI.md#jestmockedsource) utility type or the [`jest.mocked()`](MockFunctionAPI.md#jestmockedsource-options) helper method to have your mocked modules typed.
-
-:::
-
-### `jest.Mocked`
-
-See [TypeScript Usage](MockFunctionAPI.md#jestmockedsource) chapter of Mock Functions page for documentation.
-
-### `jest.mocked(source, options?)`
-
-See [TypeScript Usage](MockFunctionAPI.md#jestmockedsource-options) chapter of Mock Functions page for documentation.
-
-### `jest.unmock(moduleName)`
-
-Indicates that the module system should never return a mocked version of the specified module from `require()` (e.g. that it should always return the real module).
-
-The most common use of this API is for specifying the module a given test intends to be testing (and thus doesn't want automatically mocked).
-
-Returns the `jest` object for chaining.
-
-### `jest.deepUnmock(moduleName)`
-
-Indicates that the module system should never return a mocked version of the specified module and its dependencies.
-
-Returns the `jest` object for chaining.
-
-### `jest.doMock(moduleName, factory, options)`
-
-When using `babel-jest`, calls to `mock` will automatically be hoisted to the top of the code block. Use this method if you want to explicitly avoid this behavior.
-
-One example when this is useful is when you want to mock a module differently within the same file:
-
-```js tab
-beforeEach(() => {
- jest.resetModules();
-});
-
-test('moduleName 1', () => {
- jest.doMock('../moduleName', () => {
- return jest.fn(() => 1);
- });
- const moduleName = require('../moduleName');
- expect(moduleName()).toBe(1);
-});
-
-test('moduleName 2', () => {
- jest.doMock('../moduleName', () => {
- return jest.fn(() => 2);
- });
- const moduleName = require('../moduleName');
- expect(moduleName()).toBe(2);
-});
-```
-
-```ts tab
-beforeEach(() => {
- jest.resetModules();
-});
-
-test('moduleName 1', () => {
- // The optional type argument provides typings for the module factory
- jest.doMock('../moduleName', () => {
- return jest.fn(() => 1);
- });
- const moduleName = require('../moduleName');
- expect(moduleName()).toBe(1);
-});
-
-test('moduleName 2', () => {
- jest.doMock('../moduleName', () => {
- return jest.fn(() => 2);
- });
- const moduleName = require('../moduleName');
- expect(moduleName()).toBe(2);
-});
-```
-
-Using `jest.doMock()` with ES6 imports requires additional steps. Follow these if you don't want to use `require` in your tests:
-
-- We have to specify the `__esModule: true` property (see the [`jest.mock()`](#jestmockmodulename-factory-options) API for more information).
-- Static ES6 module imports are hoisted to the top of the file, so instead we have to import them dynamically using `import()`.
-- Finally, we need an environment which supports dynamic importing. Please see [Using Babel](GettingStarted.md#using-babel) for the initial setup. Then add the plugin [babel-plugin-dynamic-import-node](https://www.npmjs.com/package/babel-plugin-dynamic-import-node), or an equivalent, to your Babel config to enable dynamic importing in Node.
-
-```js
-beforeEach(() => {
- jest.resetModules();
-});
-
-test('moduleName 1', () => {
- jest.doMock('../moduleName', () => {
- return {
- __esModule: true,
- default: 'default1',
- foo: 'foo1',
- };
- });
- return import('../moduleName').then(moduleName => {
- expect(moduleName.default).toBe('default1');
- expect(moduleName.foo).toBe('foo1');
- });
-});
-
-test('moduleName 2', () => {
- jest.doMock('../moduleName', () => {
- return {
- __esModule: true,
- default: 'default2',
- foo: 'foo2',
- };
- });
- return import('../moduleName').then(moduleName => {
- expect(moduleName.default).toBe('default2');
- expect(moduleName.foo).toBe('foo2');
- });
-});
-```
-
-Returns the `jest` object for chaining.
-
-### `jest.dontMock(moduleName)`
-
-When using `babel-jest`, calls to `unmock` will automatically be hoisted to the top of the code block. Use this method if you want to explicitly avoid this behavior.
-
-Returns the `jest` object for chaining.
-
-### `jest.setMock(moduleName, moduleExports)`
-
-Explicitly supplies the mock object that the module system should return for the specified module.
-
-On occasion, there are times where the automatically generated mock the module system would normally provide you isn't adequate enough for your testing needs. Normally under those circumstances you should write a [manual mock](ManualMocks.md) that is more adequate for the module in question. However, on extremely rare occasions, even a manual mock isn't suitable for your purposes and you need to build the mock yourself inside your test.
-
-In these rare scenarios you can use this API to manually fill the slot in the module system's mock-module registry.
-
-Returns the `jest` object for chaining.
-
-:::info
-
-It is recommended to use [`jest.mock()`](#jestmockmodulename-factory-options) instead. The `jest.mock` API's second argument is a module factory instead of the expected exported module object.
-
-:::
-
-### `jest.requireActual(moduleName)`
-
-Returns the actual module instead of a mock, bypassing all checks on whether the module should receive a mock implementation or not.
-
-```js tab
-jest.mock('../myModule', () => {
- // Require the original module to not be mocked...
- const originalModule = jest.requireActual('../myModule');
-
- return {
- __esModule: true, // Use it when dealing with esModules
- ...originalModule,
- getRandom: jest.fn(() => 10),
- };
-});
-
-const getRandom = require('../myModule').getRandom;
-
-getRandom(); // Always returns 10
-```
-
-```ts tab
-jest.mock('../myModule', () => {
- // Require the original module to not be mocked...
- const originalModule =
- jest.requireActual('../myModule');
-
- return {
- __esModule: true, // Use it when dealing with esModules
- ...originalModule,
- getRandom: jest.fn(() => 10),
- };
-});
-
-const getRandom = require('../myModule').getRandom;
-
-getRandom(); // Always returns 10
-```
-
-### `jest.requireMock(moduleName)`
-
-Returns a mock module instead of the actual module, bypassing all checks on whether the module should be required normally or not.
-
-### `jest.resetModules()`
-
-Resets the module registry - the cache of all required modules. This is useful to isolate modules where local state might conflict between tests.
-
-Example:
-
-```js
-const sum1 = require('../sum');
-jest.resetModules();
-const sum2 = require('../sum');
-sum1 === sum2;
-// > false (Both sum modules are separate "instances" of the sum module.)
-```
-
-Example in a test:
-
-```js
-beforeEach(() => {
- jest.resetModules();
-});
-
-test('works', () => {
- const sum = require('../sum');
-});
-
-test('works too', () => {
- const sum = require('../sum');
- // sum is a different copy of the sum module from the previous test.
-});
-```
-
-Returns the `jest` object for chaining.
-
-### `jest.isolateModules(fn)`
-
-`jest.isolateModules(fn)` goes a step further than `jest.resetModules()` and creates a sandbox registry for the modules that are loaded inside the callback function. This is useful to isolate specific modules for every test so that local module state doesn't conflict between tests.
-
-```js
-let myModule;
-jest.isolateModules(() => {
- myModule = require('myModule');
-});
-
-const otherCopyOfMyModule = require('myModule');
-```
-
-### `jest.isolateModulesAsync(fn)`
-
-`jest.isolateModulesAsync()` is the equivalent of `jest.isolateModules()`, but for async callbacks. The caller is expected to `await` the completion of `isolateModulesAsync`.
-
-```js
-let myModule;
-await jest.isolateModulesAsync(async () => {
- myModule = await import('myModule');
- // do async stuff here
-});
-
-const otherCopyOfMyModule = await import('myModule');
-```
-
-## Mock Functions
-
-### `jest.fn(implementation?)`
-
-Returns a new, unused [mock function](MockFunctionAPI.md). Optionally takes a mock implementation.
-
-```js
-const mockFn = jest.fn();
-mockFn();
-expect(mockFn).toHaveBeenCalled();
-
-// With a mock implementation:
-const returnsTrue = jest.fn(() => true);
-console.log(returnsTrue()); // true;
-```
-
-:::tip
-
-See the [Mock Functions](MockFunctionAPI.md#jestfnimplementation) page for details on TypeScript usage.
-
-:::
-
-### `jest.isMockFunction(fn)`
-
-Determines if the given function is a mocked function.
-
-### `jest.replaceProperty(object, propertyKey, value)`
-
-Replace `object[propertyKey]` with a `value`. The property must already exist on the object. The same property might be replaced multiple times. Returns a Jest [replaced property](MockFunctionAPI.md#replaced-properties).
-
-:::note
-
-To mock properties that are defined as getters or setters, use [`jest.spyOn(object, methodName, accessType)`](#jestspyonobject-methodname-accesstype) instead. To mock functions, use [`jest.spyOn(object, methodName)`](#jestspyonobject-methodname) instead.
-
-:::
-
-:::tip
-
-All properties replaced with `jest.replaceProperty` could be restored to the original value by calling [jest.restoreAllMocks](#jestrestoreallmocks) on [afterEach](GlobalAPI.md#aftereachfn-timeout) method.
-
-:::
-
-Example:
-
-```js
-const utils = {
- isLocalhost() {
- return process.env.HOSTNAME === 'localhost';
- },
-};
-
-module.exports = utils;
-```
-
-Example test:
-
-```js
-const utils = require('./utils');
-
-afterEach(() => {
- // restore replaced property
- jest.restoreAllMocks();
-});
-
-test('isLocalhost returns true when HOSTNAME is localhost', () => {
- jest.replaceProperty(process, 'env', {HOSTNAME: 'localhost'});
- expect(utils.isLocalhost()).toBe(true);
-});
-
-test('isLocalhost returns false when HOSTNAME is not localhost', () => {
- jest.replaceProperty(process, 'env', {HOSTNAME: 'not-localhost'});
- expect(utils.isLocalhost()).toBe(false);
-});
-```
-
-### `jest.spyOn(object, methodName)`
-
-Creates a mock function similar to `jest.fn` but also tracks calls to `object[methodName]`. Returns a Jest [mock function](MockFunctionAPI.md).
-
-:::note
-
-By default, `jest.spyOn` also calls the **spied** method. This is different behavior from most other test libraries. If you want to overwrite the original function, you can use `jest.spyOn(object, methodName).mockImplementation(() => customImplementation)` or `object[methodName] = jest.fn(() => customImplementation)`.
-
-:::
-
-:::tip
-
-Since `jest.spyOn` is a mock, you could restore the initial state by calling [`jest.restoreAllMocks`](#jestrestoreallmocks) in the body of the callback passed to the [afterEach](GlobalAPI.md#aftereachfn-timeout) hook.
-
-:::
-
-Example:
-
-```js
-const video = {
- play() {
- return true;
- },
-};
-
-module.exports = video;
-```
-
-Example test:
-
-```js
-const video = require('./video');
-
-afterEach(() => {
- // restore the spy created with spyOn
- jest.restoreAllMocks();
-});
-
-test('plays video', () => {
- const spy = jest.spyOn(video, 'play');
- const isPlaying = video.play();
-
- expect(spy).toHaveBeenCalled();
- expect(isPlaying).toBe(true);
-});
-```
-
-### `jest.spyOn(object, methodName, accessType?)`
-
-Since Jest 22.1.0+, the `jest.spyOn` method takes an optional third argument of `accessType` that can be either `'get'` or `'set'`, which proves to be useful when you want to spy on a getter or a setter, respectively.
-
-Example:
-
-```js
-const video = {
- // it's a getter!
- get play() {
- return true;
- },
-};
-
-module.exports = video;
-
-const audio = {
- _volume: false,
- // it's a setter!
- set volume(value) {
- this._volume = value;
- },
- get volume() {
- return this._volume;
- },
-};
-
-module.exports = audio;
-```
-
-Example test:
-
-```js
-const audio = require('./audio');
-const video = require('./video');
-
-afterEach(() => {
- // restore the spy created with spyOn
- jest.restoreAllMocks();
-});
-
-test('plays video', () => {
- const spy = jest.spyOn(video, 'play', 'get'); // we pass 'get'
- const isPlaying = video.play;
-
- expect(spy).toHaveBeenCalled();
- expect(isPlaying).toBe(true);
-});
-
-test('plays audio', () => {
- const spy = jest.spyOn(audio, 'volume', 'set'); // we pass 'set'
- audio.volume = 100;
-
- expect(spy).toHaveBeenCalled();
- expect(audio.volume).toBe(100);
-});
-```
-
-### `jest.Replaced`
-
-See [TypeScript Usage](MockFunctionAPI.md#replacedpropertyreplacevaluevalue) chapter of Mock Functions page for documentation.
-
-### `jest.Spied`
-
-See [TypeScript Usage](MockFunctionAPI.md#jestspiedsource) chapter of Mock Functions page for documentation.
-
-### `jest.clearAllMocks()`
-
-Clears the `mock.calls`, `mock.instances`, `mock.contexts` and `mock.results` properties of all mocks. Equivalent to calling [`.mockClear()`](MockFunctionAPI.md#mockfnmockclear) on every mocked function.
-
-Returns the `jest` object for chaining.
-
-### `jest.resetAllMocks()`
-
-Resets the state of all mocks. Equivalent to calling [`.mockReset()`](MockFunctionAPI.md#mockfnmockreset) on every mocked function.
-
-Returns the `jest` object for chaining.
-
-### `jest.restoreAllMocks()`
-
-Restores all mocks and replaced properties back to their original value. Equivalent to calling [`.mockRestore()`](MockFunctionAPI.md#mockfnmockrestore) on every mocked function and [`.restore()`](MockFunctionAPI.md#replacedpropertyrestore) on every replaced property. Beware that `jest.restoreAllMocks()` only works for mocks created with [`jest.spyOn()`](#jestspyonobject-methodname) and properties replaced with [`jest.replaceProperty()`](#jestreplacepropertyobject-propertykey-value); other mocks will require you to manually restore them.
-
-## Fake Timers
-
-### `jest.useFakeTimers(fakeTimersConfig?)`
-
-Instructs Jest to use fake versions of the global date, performance, time and timer APIs. Fake timers implementation is backed by [`@sinonjs/fake-timers`](https://github.com/sinonjs/fake-timers).
-
-Fake timers will swap out `Date`, `performance.now()`, `queueMicrotask()`, `setImmediate()`, `clearImmediate()`, `setInterval()`, `clearInterval()`, `setTimeout()`, `clearTimeout()` with an implementation that gets its time from the fake clock.
-
-In Node environment `process.hrtime`, `process.nextTick()` and in JSDOM environment `requestAnimationFrame()`, `cancelAnimationFrame()`, `requestIdleCallback()`, `cancelIdleCallback()` will be replaced as well.
-
-Configuration options:
-
-```ts
-type FakeableAPI =
- | 'Date'
- | 'hrtime'
- | 'nextTick'
- | 'performance'
- | 'queueMicrotask'
- | 'requestAnimationFrame'
- | 'cancelAnimationFrame'
- | 'requestIdleCallback'
- | 'cancelIdleCallback'
- | 'setImmediate'
- | 'clearImmediate'
- | 'setInterval'
- | 'clearInterval'
- | 'setTimeout'
- | 'clearTimeout';
-
-type FakeTimersConfig = {
- /**
- * If set to `true` all timers will be advanced automatically by 20 milliseconds
- * every 20 milliseconds. A custom time delta may be provided by passing a number.
- * The default is `false`.
- */
- advanceTimers?: boolean | number;
- /**
- * List of names of APIs that should not be faked. The default is `[]`, meaning
- * all APIs are faked.
- */
- doNotFake?: Array;
- /**
- * Use the old fake timers implementation instead of one backed by `@sinonjs/fake-timers`.
- * The default is `false`.
- */
- legacyFakeTimers?: boolean;
- /** Sets current system time to be used by fake timers, in milliseconds. The default is `Date.now()`. */
- now?: number | Date;
- /**
- * The maximum number of recursive timers that will be run when calling `jest.runAllTimers()`.
- * The default is `100_000` timers.
- */
- timerLimit?: number;
-};
-```
-
-Calling `jest.useFakeTimers()` will use fake timers for all tests within the file, until original timers are restored with `jest.useRealTimers()`.
-
-You can call `jest.useFakeTimers()` or `jest.useRealTimers()` from anywhere: top level, inside an `test` block, etc. Keep in mind that this is a **global operation** and will affect other tests within the same file. Calling `jest.useFakeTimers()` once again in the same test file would reset the internal state (e.g. timer count) and reinstall fake timers using the provided options:
-
-```js
-test('advance the timers automatically', () => {
- jest.useFakeTimers({advanceTimers: true});
- // ...
-});
-
-test('do not advance the timers and do not fake `performance`', () => {
- jest.useFakeTimers({doNotFake: ['performance']});
- // ...
-});
-
-test('uninstall fake timers for the rest of tests in the file', () => {
- jest.useRealTimers();
- // ...
-});
-```
-
-:::info Legacy Fake Timers
-
-For some reason you might have to use legacy implementation of fake timers. It can be enabled like this (additional options are not supported):
-
-```js
-jest.useFakeTimers({
- legacyFakeTimers: true,
-});
-```
-
-Legacy fake timers will swap out `setImmediate()`, `clearImmediate()`, `setInterval()`, `clearInterval()`, `setTimeout()`, `clearTimeout()` with Jest [mock functions](MockFunctionAPI.md). In Node environment `process.nextTick()` and in JSDOM environment `requestAnimationFrame()`, `cancelAnimationFrame()` will be also replaced.
-
-:::
-
-Returns the `jest` object for chaining.
-
-### `jest.useRealTimers()`
-
-Instructs Jest to restore the original implementations of the global date, performance, time and timer APIs. For example, you may call `jest.useRealTimers()` inside `afterEach` hook to restore timers after each test:
-
-```js
-afterEach(() => {
- jest.useRealTimers();
-});
-
-test('do something with fake timers', () => {
- jest.useFakeTimers();
- // ...
-});
-
-test('do something with real timers', () => {
- // ...
-});
-```
-
-Returns the `jest` object for chaining.
-
-### `jest.runAllTicks()`
-
-Exhausts the **micro**-task queue (usually interfaced in node via `process.nextTick`).
-
-When this API is called, all pending micro-tasks that have been queued via `process.nextTick` will be executed. Additionally, if those micro-tasks themselves schedule new micro-tasks, those will be continually exhausted until there are no more micro-tasks remaining in the queue.
-
-### `jest.runAllTimers()`
-
-Exhausts both the **macro**-task queue (i.e., all tasks queued by `setTimeout()`, `setInterval()`, and `setImmediate()`) and the **micro**-task queue (usually interfaced in node via `process.nextTick`).
-
-When this API is called, all pending macro-tasks and micro-tasks will be executed. If those tasks themselves schedule new tasks, those will be continually exhausted until there are no more tasks remaining in the queue.
-
-This is often useful for synchronously executing setTimeouts during a test in order to synchronously assert about some behavior that would only happen after the `setTimeout()` or `setInterval()` callbacks executed. See the [Timer mocks](TimerMocks.md) doc for more information.
-
-### `jest.runAllImmediates()`
-
-Exhausts all tasks queued by `setImmediate()`.
-
-:::info
-
-This function is only available when using legacy fake timers implementation.
-
-:::
-
-### `jest.advanceTimersByTime(msToRun)`
-
-Executes only the macro task queue (i.e. all tasks queued by `setTimeout()` or `setInterval()` and `setImmediate()`).
-
-When this API is called, all timers are advanced by `msToRun` milliseconds. All pending "macro-tasks" that have been queued via `setTimeout()` or `setInterval()`, and would be executed within this time frame will be executed. Additionally, if those macro-tasks schedule new macro-tasks that would be executed within the same time frame, those will be executed until there are no more macro-tasks remaining in the queue, that should be run within `msToRun` milliseconds.
-
-### `jest.runOnlyPendingTimers()`
-
-Executes only the macro-tasks that are currently pending (i.e., only the tasks that have been queued by `setTimeout()` or `setInterval()` up to this point). If any of the currently pending macro-tasks schedule new macro-tasks, those new tasks will not be executed by this call.
-
-This is useful for scenarios such as one where the module being tested schedules a `setTimeout()` whose callback schedules another `setTimeout()` recursively (meaning the scheduling never stops). In these scenarios, it's useful to be able to run forward in time by a single step at a time.
-
-### `jest.advanceTimersToNextTimer(steps)`
-
-Advances all timers by the needed milliseconds so that only the next timeouts/intervals will run.
-
-Optionally, you can provide `steps`, so it will run `steps` amount of next timeouts/intervals.
-
-### `jest.clearAllTimers()`
-
-Removes any pending timers from the timer system.
-
-This means, if any timers have been scheduled (but have not yet executed), they will be cleared and will never have the opportunity to execute in the future.
-
-### `jest.getTimerCount()`
-
-Returns the number of fake timers still left to run.
-
-### `jest.now()`
-
-Returns the time in ms of the current clock. This is equivalent to `Date.now()` if real timers are in use, or if `Date` is mocked. In other cases (such as legacy timers) it may be useful for implementing custom mocks of `Date.now()`, `performance.now()`, etc.
-
-### `jest.setSystemTime(now?: number | Date)`
-
-Set the current system time used by fake timers. Simulates a user changing the system clock while your program is running. It affects the current time but it does not in itself cause e.g. timers to fire; they will fire exactly as they would have done without the call to `jest.setSystemTime()`.
-
-:::info
-
-This function is not available when using legacy fake timers implementation.
-
-:::
-
-### `jest.getRealSystemTime()`
-
-When mocking time, `Date.now()` will also be mocked. If you for some reason need access to the real current time, you can invoke this function.
-
-:::info
-
-This function is not available when using legacy fake timers implementation.
-
-:::
-
-## Misc
-
-### `jest.getSeed()`
-
-Every time Jest runs a seed value is randomly generated which you could use in a pseudorandom number generator or anywhere else.
-
-:::tip
-
-Use the [`--showSeed`](CLI.md#--showseed) flag to print the seed in the test report summary. To manually set the value of the seed use [`--seed=`](CLI.md#--seednum) CLI argument.
-
-:::
-
-### `jest.isEnvironmentTornDown()`
-
-Returns `true` if test environment has been torn down.
-
-### `jest.retryTimes(numRetries, options?)`
-
-Runs failed tests n-times until they pass or until the max number of retries is exhausted.
-
-```js
-jest.retryTimes(3);
-
-test('will fail', () => {
- expect(true).toBe(false);
-});
-```
-
-If `logErrorsBeforeRetry` option is enabled, error(s) that caused the test to fail will be logged to the console.
-
-```js
-jest.retryTimes(3, {logErrorsBeforeRetry: true});
-
-test('will fail', () => {
- expect(true).toBe(false);
-});
-```
-
-Returns the `jest` object for chaining.
-
-:::caution
-
-`jest.retryTimes()` must be declared at the top level of a test file or in a `describe` block.
-
-:::
-
-:::info
-
-This function is only available with the default [jest-circus](https://github.com/jestjs/jest/tree/main/packages/jest-circus) runner.
-
-:::
-
-### `jest.setTimeout(timeout)`
-
-Set the default timeout interval (in milliseconds) for all tests and before/after hooks in the test file. This only affects the test file from which this function is called. The default timeout interval is 5 seconds if this method is not called.
-
-Example:
-
-```js
-jest.setTimeout(1000); // 1 second
-```
-
-:::tip
-
-To set timeout intervals on different tests in the same file, use the [`timeout` option on each individual test](GlobalAPI.md#testname-fn-timeout).
-
-If you want to set the timeout for all test files, use [`testTimeout`](Configuration.md#testtimeout-number) configuration option.
-
-:::
diff --git a/website/versioned_docs/version-29.4/MockFunctions.md b/website/versioned_docs/version-29.4/MockFunctions.md
deleted file mode 100644
index 0801739e8406..000000000000
--- a/website/versioned_docs/version-29.4/MockFunctions.md
+++ /dev/null
@@ -1,328 +0,0 @@
----
-id: mock-functions
-title: Mock Functions
----
-
-Mock functions allow you to test the links between code by erasing the actual implementation of a function, capturing calls to the function (and the parameters passed in those calls), capturing instances of constructor functions when instantiated with `new`, and allowing test-time configuration of return values.
-
-There are two ways to mock functions: Either by creating a mock function to use in test code, or writing a [`manual mock`](ManualMocks.md) to override a module dependency.
-
-## Using a mock function
-
-Let's imagine we're testing an implementation of a function `forEach`, which invokes a callback for each item in a supplied array.
-
-```js title="forEach.js"
-export function forEach(items, callback) {
- for (const item of items) {
- callback(item);
- }
-}
-```
-
-To test this function, we can use a mock function, and inspect the mock's state to ensure the callback is invoked as expected.
-
-```js title="forEach.test.js"
-const forEach = require('./forEach');
-
-const mockCallback = jest.fn(x => 42 + x);
-
-test('forEach mock function', () => {
- forEach([0, 1], mockCallback);
-
- // The mock function was called twice
- expect(mockCallback.mock.calls).toHaveLength(2);
-
- // The first argument of the first call to the function was 0
- expect(mockCallback.mock.calls[0][0]).toBe(0);
-
- // The first argument of the second call to the function was 1
- expect(mockCallback.mock.calls[1][0]).toBe(1);
-
- // The return value of the first call to the function was 42
- expect(mockCallback.mock.results[0].value).toBe(42);
-});
-```
-
-## `.mock` property
-
-All mock functions have this special `.mock` property, which is where data about how the function has been called and what the function returned is kept. The `.mock` property also tracks the value of `this` for each call, so it is possible to inspect this as well:
-
-```javascript
-const myMock1 = jest.fn();
-const a = new myMock1();
-console.log(myMock1.mock.instances);
-// > [ ]
-
-const myMock2 = jest.fn();
-const b = {};
-const bound = myMock2.bind(b);
-bound();
-console.log(myMock2.mock.contexts);
-// > [ ]
-```
-
-These mock members are very useful in tests to assert how these functions get called, instantiated, or what they returned:
-
-```javascript
-// The function was called exactly once
-expect(someMockFunction.mock.calls).toHaveLength(1);
-
-// The first arg of the first call to the function was 'first arg'
-expect(someMockFunction.mock.calls[0][0]).toBe('first arg');
-
-// The second arg of the first call to the function was 'second arg'
-expect(someMockFunction.mock.calls[0][1]).toBe('second arg');
-
-// The return value of the first call to the function was 'return value'
-expect(someMockFunction.mock.results[0].value).toBe('return value');
-
-// The function was called with a certain `this` context: the `element` object.
-expect(someMockFunction.mock.contexts[0]).toBe(element);
-
-// This function was instantiated exactly twice
-expect(someMockFunction.mock.instances.length).toBe(2);
-
-// The object returned by the first instantiation of this function
-// had a `name` property whose value was set to 'test'
-expect(someMockFunction.mock.instances[0].name).toBe('test');
-
-// The first argument of the last call to the function was 'test'
-expect(someMockFunction.mock.lastCall[0]).toBe('test');
-```
-
-## Mock Return Values
-
-Mock functions can also be used to inject test values into your code during a test:
-
-```javascript
-const myMock = jest.fn();
-console.log(myMock());
-// > undefined
-
-myMock.mockReturnValueOnce(10).mockReturnValueOnce('x').mockReturnValue(true);
-
-console.log(myMock(), myMock(), myMock(), myMock());
-// > 10, 'x', true, true
-```
-
-Mock functions are also very effective in code that uses a functional continuation-passing style. Code written in this style helps avoid the need for complicated stubs that recreate the behavior of the real component they're standing in for, in favor of injecting values directly into the test right before they're used.
-
-```javascript
-const filterTestFn = jest.fn();
-
-// Make the mock return `true` for the first call,
-// and `false` for the second call
-filterTestFn.mockReturnValueOnce(true).mockReturnValueOnce(false);
-
-const result = [11, 12].filter(num => filterTestFn(num));
-
-console.log(result);
-// > [11]
-console.log(filterTestFn.mock.calls[0][0]); // 11
-console.log(filterTestFn.mock.calls[1][0]); // 12
-```
-
-Most real-world examples actually involve getting ahold of a mock function on a dependent component and configuring that, but the technique is the same. In these cases, try to avoid the temptation to implement logic inside of any function that's not directly being tested.
-
-## Mocking Modules
-
-Suppose we have a class that fetches users from our API. The class uses [axios](https://github.com/axios/axios) to call the API then returns the `data` attribute which contains all the users:
-
-```js title="users.js"
-import axios from 'axios';
-
-class Users {
- static all() {
- return axios.get('/users.json').then(resp => resp.data);
- }
-}
-
-export default Users;
-```
-
-Now, in order to test this method without actually hitting the API (and thus creating slow and fragile tests), we can use the `jest.mock(...)` function to automatically mock the axios module.
-
-Once we mock the module we can provide a `mockResolvedValue` for `.get` that returns the data we want our test to assert against. In effect, we are saying that we want `axios.get('/users.json')` to return a fake response.
-
-```js title="users.test.js"
-import axios from 'axios';
-import Users from './users';
-
-jest.mock('axios');
-
-test('should fetch users', () => {
- const users = [{name: 'Bob'}];
- const resp = {data: users};
- axios.get.mockResolvedValue(resp);
-
- // or you could use the following depending on your use case:
- // axios.get.mockImplementation(() => Promise.resolve(resp))
-
- return Users.all().then(data => expect(data).toEqual(users));
-});
-```
-
-## Mocking Partials
-
-Subsets of a module can be mocked and the rest of the module can keep their actual implementation:
-
-```js title="foo-bar-baz.js"
-export const foo = 'foo';
-export const bar = () => 'bar';
-export default () => 'baz';
-```
-
-```js
-//test.js
-import defaultExport, {bar, foo} from '../foo-bar-baz';
-
-jest.mock('../foo-bar-baz', () => {
- const originalModule = jest.requireActual('../foo-bar-baz');
-
- //Mock the default export and named export 'foo'
- return {
- __esModule: true,
- ...originalModule,
- default: jest.fn(() => 'mocked baz'),
- foo: 'mocked foo',
- };
-});
-
-test('should do a partial mock', () => {
- const defaultExportResult = defaultExport();
- expect(defaultExportResult).toBe('mocked baz');
- expect(defaultExport).toHaveBeenCalled();
-
- expect(foo).toBe('mocked foo');
- expect(bar()).toBe('bar');
-});
-```
-
-## Mock Implementations
-
-Still, there are cases where it's useful to go beyond the ability to specify return values and full-on replace the implementation of a mock function. This can be done with `jest.fn` or the `mockImplementationOnce` method on mock functions.
-
-```javascript
-const myMockFn = jest.fn(cb => cb(null, true));
-
-myMockFn((err, val) => console.log(val));
-// > true
-```
-
-The `mockImplementation` method is useful when you need to define the default implementation of a mock function that is created from another module:
-
-```js title="foo.js"
-module.exports = function () {
- // some implementation;
-};
-```
-
-```js title="test.js"
-jest.mock('../foo'); // this happens automatically with automocking
-const foo = require('../foo');
-
-// foo is a mock function
-foo.mockImplementation(() => 42);
-foo();
-// > 42
-```
-
-When you need to recreate a complex behavior of a mock function such that multiple function calls produce different results, use the `mockImplementationOnce` method:
-
-```javascript
-const myMockFn = jest
- .fn()
- .mockImplementationOnce(cb => cb(null, true))
- .mockImplementationOnce(cb => cb(null, false));
-
-myMockFn((err, val) => console.log(val));
-// > true
-
-myMockFn((err, val) => console.log(val));
-// > false
-```
-
-When the mocked function runs out of implementations defined with `mockImplementationOnce`, it will execute the default implementation set with `jest.fn` (if it is defined):
-
-```javascript
-const myMockFn = jest
- .fn(() => 'default')
- .mockImplementationOnce(() => 'first call')
- .mockImplementationOnce(() => 'second call');
-
-console.log(myMockFn(), myMockFn(), myMockFn(), myMockFn());
-// > 'first call', 'second call', 'default', 'default'
-```
-
-For cases where we have methods that are typically chained (and thus always need to return `this`), we have a sugary API to simplify this in the form of a `.mockReturnThis()` function that also sits on all mocks:
-
-```javascript
-const myObj = {
- myMethod: jest.fn().mockReturnThis(),
-};
-
-// is the same as
-
-const otherObj = {
- myMethod: jest.fn(function () {
- return this;
- }),
-};
-```
-
-## Mock Names
-
-You can optionally provide a name for your mock functions, which will be displayed instead of `'jest.fn()'` in the test error output. Use [`.mockName()`](MockFunctionAPI.md#mockfnmocknamename) if you want to be able to quickly identify the mock function reporting an error in your test output.
-
-```javascript
-const myMockFn = jest
- .fn()
- .mockReturnValue('default')
- .mockImplementation(scalar => 42 + scalar)
- .mockName('add42');
-```
-
-## Custom Matchers
-
-Finally, in order to make it less demanding to assert how mock functions have been called, we've added some custom matcher functions for you:
-
-```javascript
-// The mock function was called at least once
-expect(mockFunc).toHaveBeenCalled();
-
-// The mock function was called at least once with the specified args
-expect(mockFunc).toHaveBeenCalledWith(arg1, arg2);
-
-// The last call to the mock function was called with the specified args
-expect(mockFunc).toHaveBeenLastCalledWith(arg1, arg2);
-
-// All calls and the name of the mock is written as a snapshot
-expect(mockFunc).toMatchSnapshot();
-```
-
-These matchers are sugar for common forms of inspecting the `.mock` property. You can always do this manually yourself if that's more to your taste or if you need to do something more specific:
-
-```javascript
-// The mock function was called at least once
-expect(mockFunc.mock.calls.length).toBeGreaterThan(0);
-
-// The mock function was called at least once with the specified args
-expect(mockFunc.mock.calls).toContainEqual([arg1, arg2]);
-
-// The last call to the mock function was called with the specified args
-expect(mockFunc.mock.calls[mockFunc.mock.calls.length - 1]).toEqual([
- arg1,
- arg2,
-]);
-
-// The first arg of the last call to the mock function was `42`
-// (note that there is no sugar helper for this specific of an assertion)
-expect(mockFunc.mock.calls[mockFunc.mock.calls.length - 1][0]).toBe(42);
-
-// A snapshot will check that a mock was invoked the same number of times,
-// in the same order, with the same arguments. It will also assert on the name.
-expect(mockFunc.mock.calls).toEqual([[arg1, arg2]]);
-expect(mockFunc.getMockName()).toBe('a mock name');
-```
-
-For a complete list of matchers, check out the [reference docs](ExpectAPI.md).
diff --git a/website/versioned_docs/version-29.4/TutorialReact.md b/website/versioned_docs/version-29.4/TutorialReact.md
deleted file mode 100644
index 88bb4ebc6fef..000000000000
--- a/website/versioned_docs/version-29.4/TutorialReact.md
+++ /dev/null
@@ -1,329 +0,0 @@
----
-id: tutorial-react
-title: Testing React Apps
----
-
-At Facebook, we use Jest to test [React](https://reactjs.org/) applications.
-
-## Setup
-
-### Setup with Create React App
-
-If you are new to React, we recommend using [Create React App](https://create-react-app.dev/). It is ready to use and [ships with Jest](https://create-react-app.dev/docs/running-tests/#docsNav)! You will only need to add `react-test-renderer` for rendering snapshots.
-
-Run
-
-```bash npm2yarn
-npm install --save-dev react-test-renderer
-```
-
-### Setup without Create React App
-
-If you have an existing application you'll need to install a few packages to make everything work well together. We are using the `babel-jest` package and the `react` babel preset to transform our code inside of the test environment. Also see [using babel](GettingStarted.md#using-babel).
-
-Run
-
-```bash npm2yarn
-npm install --save-dev jest babel-jest @babel/preset-env @babel/preset-react react-test-renderer
-```
-
-Your `package.json` should look something like this (where `` is the actual latest version number for the package). Please add the scripts and jest configuration entries:
-
-```json
-{
- "dependencies": {
- "react": "",
- "react-dom": ""
- },
- "devDependencies": {
- "@babel/preset-env": "",
- "@babel/preset-react": "",
- "babel-jest": "",
- "jest": "",
- "react-test-renderer": ""
- },
- "scripts": {
- "test": "jest"
- }
-}
-```
-
-```js title="babel.config.js"
-module.exports = {
- presets: [
- '@babel/preset-env',
- ['@babel/preset-react', {runtime: 'automatic'}],
- ],
-};
-```
-
-**And you're good to go!**
-
-### Snapshot Testing
-
-Let's create a [snapshot test](SnapshotTesting.md) for a Link component that renders hyperlinks:
-
-```tsx title="Link.js"
-import {useState} from 'react';
-
-const STATUS = {
- HOVERED: 'hovered',
- NORMAL: 'normal',
-};
-
-export default function Link({page, children}) {
- const [status, setStatus] = useState(STATUS.NORMAL);
-
- const onMouseEnter = () => {
- setStatus(STATUS.HOVERED);
- };
-
- const onMouseLeave = () => {
- setStatus(STATUS.NORMAL);
- };
-
- return (
-
- {children}
-
- );
-}
-```
-
-:::note
-
-Examples are using Function components, but Class components can be tested in the same way. See [React: Function and Class Components](https://reactjs.org/docs/components-and-props.html#function-and-class-components). **Reminders** that with Class components, we expect Jest to be used to test props and not methods directly.
-
-:::
-
-Now let's use React's test renderer and Jest's snapshot feature to interact with the component and capture the rendered output and create a snapshot file:
-
-```tsx title="Link.test.js"
-import renderer from 'react-test-renderer';
-import Link from '../Link';
-
-it('changes the class when hovered', () => {
- const component = renderer.create(
- Facebook,
- );
- let tree = component.toJSON();
- expect(tree).toMatchSnapshot();
-
- // manually trigger the callback
- renderer.act(() => {
- tree.props.onMouseEnter();
- });
- // re-rendering
- tree = component.toJSON();
- expect(tree).toMatchSnapshot();
-
- // manually trigger the callback
- renderer.act(() => {
- tree.props.onMouseLeave();
- });
- // re-rendering
- tree = component.toJSON();
- expect(tree).toMatchSnapshot();
-});
-```
-
-When you run `yarn test` or `jest`, this will produce an output file like this:
-
-```javascript title="__tests__/__snapshots__/Link.test.js.snap"
-exports[`changes the class when hovered 1`] = `
-
- Facebook
-
-`;
-
-exports[`changes the class when hovered 2`] = `
-
- Facebook
-
-`;
-
-exports[`changes the class when hovered 3`] = `
-
- Facebook
-
-`;
-```
-
-The next time you run the tests, the rendered output will be compared to the previously created snapshot. The snapshot should be committed along with code changes. When a snapshot test fails, you need to inspect whether it is an intended or unintended change. If the change is expected you can invoke Jest with `jest -u` to overwrite the existing snapshot.
-
-The code for this example is available at [examples/snapshot](https://github.com/jestjs/jest/tree/main/examples/snapshot).
-
-#### Snapshot Testing with Mocks, Enzyme and React 16+
-
-There's a caveat around snapshot testing when using Enzyme and React 16+. If you mock out a module using the following style:
-
-```js
-jest.mock('../SomeDirectory/SomeComponent', () => 'SomeComponent');
-```
-
-Then you will see warnings in the console:
-
-```bash
-Warning: is using uppercase HTML. Always use lowercase HTML tags in React.
-
-# Or:
-Warning: The tag is unrecognized in this browser. If you meant to render a React component, start its name with an uppercase letter.
-```
-
-React 16 triggers these warnings due to how it checks element types, and the mocked module fails these checks. Your options are:
-
-1. Render as text. This way you won't see the props passed to the mock component in the snapshot, but it's straightforward:
- ```js
- jest.mock('./SomeComponent', () => () => 'SomeComponent');
- ```
-2. Render as a custom element. DOM "custom elements" aren't checked for anything and shouldn't fire warnings. They are lowercase and have a dash in the name.
- ```tsx
- jest.mock('./Widget', () => () => );
- ```
-3. Use `react-test-renderer`. The test renderer doesn't care about element types and will happily accept e.g. `SomeComponent`. You could check snapshots using the test renderer, and check component behavior separately using Enzyme.
-4. Disable warnings all together (should be done in your jest setup file):
- ```js
- jest.mock('fbjs/lib/warning', () => require('fbjs/lib/emptyFunction'));
- ```
- This shouldn't normally be your option of choice as useful warnings could be lost. However, in some cases, for example when testing react-native's components we are rendering react-native tags into the DOM and many warnings are irrelevant. Another option is to swizzle the console.warn and suppress specific warnings.
-
-### DOM Testing
-
-If you'd like to assert, and manipulate your rendered components you can use [react-testing-library](https://github.com/testing-library/react-testing-library), [Enzyme](https://enzymejs.github.io/enzyme/), or React's [TestUtils](https://reactjs.org/docs/test-utils.html). The following two examples use react-testing-library and Enzyme.
-
-#### react-testing-library
-
-```bash npm2yarn
-npm install --save-dev @testing-library/react
-```
-
-Let's implement a checkbox which swaps between two labels:
-
-```tsx title="CheckboxWithLabel.js"
-import {useState} from 'react';
-
-export default function CheckboxWithLabel({labelOn, labelOff}) {
- const [isChecked, setIsChecked] = useState(false);
-
- const onChange = () => {
- setIsChecked(!isChecked);
- };
-
- return (
-
- );
-}
-```
-
-```tsx title="__tests__/CheckboxWithLabel-test.js"
-import {cleanup, fireEvent, render} from '@testing-library/react';
-import CheckboxWithLabel from '../CheckboxWithLabel';
-
-// Note: running cleanup afterEach is done automatically for you in @testing-library/react@9.0.0 or higher
-// unmount and cleanup DOM after the test is finished.
-afterEach(cleanup);
-
-it('CheckboxWithLabel changes the text after click', () => {
- const {queryByLabelText, getByLabelText} = render(
- ,
- );
-
- expect(queryByLabelText(/off/i)).toBeTruthy();
-
- fireEvent.click(getByLabelText(/off/i));
-
- expect(queryByLabelText(/on/i)).toBeTruthy();
-});
-```
-
-The code for this example is available at [examples/react-testing-library](https://github.com/jestjs/jest/tree/main/examples/react-testing-library).
-
-#### Enzyme
-
-```bash npm2yarn
-npm install --save-dev enzyme
-```
-
-If you are using a React version below 15.5.0, you will also need to install `react-addons-test-utils`.
-
-Let's rewrite the test from above using Enzyme instead of react-testing-library. We use Enzyme's [shallow renderer](https://enzymejs.github.io/enzyme/docs/api/shallow.html) in this example.
-
-```tsx title="__tests__/CheckboxWithLabel-test.js"
-import Enzyme, {shallow} from 'enzyme';
-import Adapter from 'enzyme-adapter-react-16';
-import CheckboxWithLabel from '../CheckboxWithLabel';
-
-Enzyme.configure({adapter: new Adapter()});
-
-it('CheckboxWithLabel changes the text after click', () => {
- // Render a checkbox with label in the document
- const checkbox = shallow();
-
- expect(checkbox.text()).toBe('Off');
-
- checkbox.find('input').simulate('change');
-
- expect(checkbox.text()).toBe('On');
-});
-```
-
-### Custom transformers
-
-If you need more advanced functionality, you can also build your own transformer. Instead of using `babel-jest`, here is an example of using `@babel/core`:
-
-```javascript title="custom-transformer.js"
-'use strict';
-
-const {transform} = require('@babel/core');
-const jestPreset = require('babel-preset-jest');
-
-module.exports = {
- process(src, filename) {
- const result = transform(src, {
- filename,
- presets: [jestPreset],
- });
-
- return result || src;
- },
-};
-```
-
-Don't forget to install the `@babel/core` and `babel-preset-jest` packages for this example to work.
-
-To make this work with Jest you need to update your Jest configuration with this: `"transform": {"\\.js$": "path/to/custom-transformer.js"}`.
-
-If you'd like to build a transformer with babel support, you can also use `babel-jest` to compose one and pass in your custom configuration options:
-
-```javascript
-const babelJest = require('babel-jest');
-
-module.exports = babelJest.createTransformer({
- presets: ['my-custom-preset'],
-});
-```
-
-See [dedicated docs](CodeTransformation.md#writing-custom-transformers) for more details.
diff --git a/website/versioned_docs/version-29.4/WatchPlugins.md b/website/versioned_docs/version-29.4/WatchPlugins.md
deleted file mode 100644
index 57ddeaec07e4..000000000000
--- a/website/versioned_docs/version-29.4/WatchPlugins.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-id: watch-plugins
-title: Watch Plugins
----
-
-The Jest watch plugin system provides a way to hook into specific parts of Jest and to define watch mode menu prompts that execute code on key press. Combined, these features allow you to develop interactive experiences custom for your workflow.
-
-## Watch Plugin Interface
-
-```javascript
-class MyWatchPlugin {
- // Add hooks to Jest lifecycle events
- apply(jestHooks) {}
-
- // Get the prompt information for interactive plugins
- getUsageInfo(globalConfig) {}
-
- // Executed when the key from `getUsageInfo` is input
- run(globalConfig, updateConfigAndRun) {}
-}
-```
-
-## Hooking into Jest
-
-To connect your watch plugin to Jest, add its path under `watchPlugins` in your Jest configuration:
-
-```javascript title="jest.config.js"
-module.exports = {
- // ...
- watchPlugins: ['path/to/yourWatchPlugin'],
-};
-```
-
-Custom watch plugins can add hooks to Jest events. These hooks can be added either with or without having an interactive key in the watch mode menu.
-
-### `apply(jestHooks)`
-
-Jest hooks can be attached by implementing the `apply` method. This method receives a `jestHooks` argument that allows the plugin to hook into specific parts of the lifecycle of a test run.
-
-```javascript
-class MyWatchPlugin {
- apply(jestHooks) {}
-}
-```
-
-Below are the hooks available in Jest.
-
-#### `jestHooks.shouldRunTestSuite(testSuiteInfo)`
-
-Returns a boolean (or `Promise` for handling asynchronous operations) to specify if a test should be run or not.
-
-For example:
-
-```javascript
-class MyWatchPlugin {
- apply(jestHooks) {
- jestHooks.shouldRunTestSuite(testSuiteInfo => {
- return testSuiteInfo.testPath.includes('my-keyword');
- });
-
- // or a promise
- jestHooks.shouldRunTestSuite(testSuiteInfo => {
- return Promise.resolve(testSuiteInfo.testPath.includes('my-keyword'));
- });
- }
-}
-```
-
-#### `jestHooks.onTestRunComplete(results)`
-
-Gets called at the end of every test run. It has the test results as an argument.
-
-For example:
-
-```javascript
-class MyWatchPlugin {
- apply(jestHooks) {
- jestHooks.onTestRunComplete(results => {
- this._hasSnapshotFailure = results.snapshot.failure;
- });
- }
-}
-```
-
-#### `jestHooks.onFileChange({projects})`
-
-Gets called whenever there is a change in the file system
-
-- `projects: Array`: Includes all the test paths that Jest is watching.
-
-For example:
-
-```javascript
-class MyWatchPlugin {
- apply(jestHooks) {
- jestHooks.onFileChange(({projects}) => {
- this._projects = projects;
- });
- }
-}
-```
-
-## Watch Menu Integration
-
-Custom watch plugins can also add or override functionality to the watch menu by specifying a key/prompt pair in `getUsageInfo` method and a `run` method for the execution of the key.
-
-### `getUsageInfo(globalConfig)`
-
-To add a key to the watch menu, implement the `getUsageInfo` method, returning a key and the prompt:
-
-```javascript
-class MyWatchPlugin {
- getUsageInfo(globalConfig) {
- return {
- key: 's',
- prompt: 'do something',
- };
- }
-}
-```
-
-This will add a line in the watch mode menu _(`› Press s to do something.`)_
-
-```text
-Watch Usage
- › Press p to filter by a filename regex pattern.
- › Press t to filter by a test name regex pattern.
- › Press q to quit watch mode.
- › Press s to do something. // <-- This is our plugin
- › Press Enter to trigger a test run.
-```
-
-:::note
-
-If the key for your plugin already exists as a default key, your plugin will override that key.
-
-:::
-
-### `run(globalConfig, updateConfigAndRun)`
-
-To handle key press events from the key returned by `getUsageInfo`, you can implement the `run` method. This method returns a `Promise` that can be resolved when the plugin wants to return control to Jest. The `boolean` specifies if Jest should rerun the tests after it gets the control back.
-
-- [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422): A representation of Jest's current global configuration
-- `updateConfigAndRun`: Allows you to trigger a test run while the interactive plugin is running.
-
-```javascript
-class MyWatchPlugin {
- run(globalConfig, updateConfigAndRun) {
- // do something.
- }
-}
-```
-
-:::note
-
-If you do call `updateConfigAndRun`, your `run` method should not resolve to a truthy value, as that would trigger a double-run.
-
-:::
-
-#### Authorized configuration keys
-
-For stability and safety reasons, only part of the global configuration keys can be updated with `updateConfigAndRun`. The current white list is as follows:
-
-- [`bail`](configuration#bail-number--boolean)
-- [`changedSince`](cli#--changedsince)
-- [`collectCoverage`](configuration#collectcoverage-boolean)
-- [`collectCoverageFrom`](configuration#collectcoveragefrom-array)
-- [`coverageDirectory`](configuration#coveragedirectory-string)
-- [`coverageReporters`](configuration#coveragereporters-arraystring)
-- [`notify`](configuration#notify-boolean)
-- [`notifyMode`](configuration#notifymode-string)
-- [`onlyFailures`](configuration#onlyfailures-boolean)
-- [`reporters`](configuration#reporters-arraymodulename--modulename-options)
-- [`testNamePattern`](cli#--testnamepatternregex)
-- [`testPathPattern`](cli#--testpathpatternregex)
-- [`updateSnapshot`](cli#--updatesnapshot)
-- [`verbose`](configuration#verbose-boolean)
-
-## Customization
-
-Plugins can be customized via your Jest configuration.
-
-```javascript title="jest.config.js"
-module.exports = {
- // ...
- watchPlugins: [
- [
- 'path/to/yourWatchPlugin',
- {
- key: 'k', // <- your custom key
- prompt: 'show a custom prompt',
- },
- ],
- ],
-};
-```
-
-Recommended config names:
-
-- `key`: Modifies the plugin key.
-- `prompt`: Allows user to customize the text in the plugin prompt.
-
-If the user provided a custom configuration, it will be passed as an argument to the plugin constructor.
-
-```javascript
-class MyWatchPlugin {
- constructor({config}) {}
-}
-```
-
-## Choosing a good key
-
-Jest allows third-party plugins to override some of its built-in feature keys, but not all. Specifically, the following keys are **not overwritable** :
-
-- `c` (clears filter patterns)
-- `i` (updates non-matching snapshots interactively)
-- `q` (quits)
-- `u` (updates all non-matching snapshots)
-- `w` (displays watch mode usage / available actions)
-
-The following keys for built-in functionality **can be overwritten** :
-
-- `p` (test filename pattern)
-- `t` (test name pattern)
-
-Any key not used by built-in functionality can be claimed, as you would expect. Try to avoid using keys that are difficult to obtain on various keyboards (e.g. `é`, `€`), or not visible by default (e.g. many Mac keyboards do not have visual hints for characters such as `|`, `\`, `[`, etc.)
-
-### When a conflict happens
-
-Should your plugin attempt to overwrite a reserved key, Jest will error out with a descriptive message, something like:
-
-```bash
-
-Watch plugin YourFaultyPlugin attempted to register key `q`, that is reserved internally for quitting watch mode. Please change the configuration key for this plugin.
-
-```
-
-Third-party plugins are also forbidden to overwrite a key reserved already by another third-party plugin present earlier in the configured plugins list (`watchPlugins` array setting). When this happens, you’ll also get an error message that tries to help you fix that:
-
-```bash
-
-Watch plugins YourFaultyPlugin and TheirFaultyPlugin both attempted to register key `x`. Please change the key configuration for one of the conflicting plugins to avoid overlap.
-
-```
diff --git a/website/versioned_docs/version-29.5/Architecture.md b/website/versioned_docs/version-29.5/Architecture.md
deleted file mode 100644
index 8d9a7c1d5eba..000000000000
--- a/website/versioned_docs/version-29.5/Architecture.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-id: architecture
-title: Architecture
----
-
-import LiteYouTubeEmbed from 'react-lite-youtube-embed';
-
-If you are interested in learning more about how Jest works, understand its architecture, and how Jest is split up into individual reusable packages, check out this video:
-
-
-
-If you'd like to learn how to build a testing framework like Jest from scratch, check out this video:
-
-
-
-There is also a [written guide you can follow](https://cpojer.net/posts/building-a-javascript-testing-framework). It teaches the fundamental concepts of Jest and explains how various parts of Jest can be used to compose a custom testing framework.
diff --git a/website/versioned_docs/version-29.5/BypassingModuleMocks.md b/website/versioned_docs/version-29.5/BypassingModuleMocks.md
deleted file mode 100644
index ba3ed65d95d4..000000000000
--- a/website/versioned_docs/version-29.5/BypassingModuleMocks.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-id: bypassing-module-mocks
-title: Bypassing module mocks
----
-
-Jest allows you to mock out whole modules in your tests, which can be useful for testing if your code is calling functions from that module correctly. However, sometimes you may want to use parts of a mocked module in your _test file_, in which case you want to access the original implementation, rather than a mocked version.
-
-Consider writing a test case for this `createUser` function:
-
-```javascript title="createUser.js"
-import fetch from 'node-fetch';
-
-export const createUser = async () => {
- const response = await fetch('https://website.com/users', {method: 'POST'});
- const userId = await response.text();
- return userId;
-};
-```
-
-Your test will want to mock the `fetch` function so that we can be sure that it gets called without actually making the network request. However, you'll also need to mock the return value of `fetch` with a `Response` (wrapped in a `Promise`), as our function uses it to grab the created user's ID. So you might initially try writing a test like this:
-
-```javascript
-jest.mock('node-fetch');
-
-import fetch, {Response} from 'node-fetch';
-import {createUser} from './createUser';
-
-test('createUser calls fetch with the right args and returns the user id', async () => {
- fetch.mockReturnValue(Promise.resolve(new Response('4')));
-
- const userId = await createUser();
-
- expect(fetch).toHaveBeenCalledTimes(1);
- expect(fetch).toHaveBeenCalledWith('https://website.com/users', {
- method: 'POST',
- });
- expect(userId).toBe('4');
-});
-```
-
-However, if you ran that test you would find that the `createUser` function would fail, throwing the error: `TypeError: response.text is not a function`. This is because the `Response` class you've imported from `node-fetch` has been mocked (due to the `jest.mock` call at the top of the test file) so it no longer behaves the way it should.
-
-To get around problems like this, Jest provides the `jest.requireActual` helper. To make the above test work, make the following change to the imports in the test file:
-
-```javascript
-// BEFORE
-jest.mock('node-fetch');
-import fetch, {Response} from 'node-fetch';
-```
-
-```javascript
-// AFTER
-jest.mock('node-fetch');
-import fetch from 'node-fetch';
-const {Response} = jest.requireActual('node-fetch');
-```
-
-This allows your test file to import the actual `Response` object from `node-fetch`, rather than a mocked version. This means the test will now pass correctly.
diff --git a/website/versioned_docs/version-29.5/CLI.md b/website/versioned_docs/version-29.5/CLI.md
deleted file mode 100644
index 612ab82def11..000000000000
--- a/website/versioned_docs/version-29.5/CLI.md
+++ /dev/null
@@ -1,530 +0,0 @@
----
-id: cli
-title: Jest CLI Options
----
-
-The `jest` command line runner has a number of useful options. You can run `jest --help` to view all available options. Many of the options shown below can also be used together to run tests exactly the way you want. Every one of Jest's [Configuration](Configuration.md) options can also be specified through the CLI.
-
-Here is a brief overview:
-
-## Running from the command line
-
-Run all tests (default):
-
-```bash
-jest
-```
-
-Run only the tests that were specified with a pattern or filename:
-
-```bash
-jest my-test #or
-jest path/to/my-test.js
-```
-
-Run tests related to changed files based on hg/git (uncommitted files):
-
-```bash
-jest -o
-```
-
-Run tests related to `path/to/fileA.js` and `path/to/fileB.js`:
-
-```bash
-jest --findRelatedTests path/to/fileA.js path/to/fileB.js
-```
-
-Run tests that match this spec name (match against the name in `describe` or `test`, basically).
-
-```bash
-jest -t name-of-spec
-```
-
-Run watch mode:
-
-```bash
-jest --watch #runs jest -o by default
-jest --watchAll #runs all tests
-```
-
-Watch mode also enables to specify the name or path to a file to focus on a specific set of tests.
-
-## Using with package manager
-
-If you run Jest via your package manager, you can still pass the command line arguments directly as Jest arguments.
-
-Instead of:
-
-```bash
-jest -u -t="ColorPicker"
-```
-
-you can use:
-
-```bash npm2yarn
-npm test -- -u -t="ColorPicker"
-```
-
-## Camelcase & dashed args support
-
-Jest supports both camelcase and dashed arg formats. The following examples will have an equal result:
-
-```bash
-jest --collect-coverage
-jest --collectCoverage
-```
-
-Arguments can also be mixed:
-
-```bash
-jest --update-snapshot --detectOpenHandles
-```
-
-## Options
-
-:::note
-
-CLI options take precedence over values from the [Configuration](Configuration.md).
-
-:::
-
-import TOCInline from '@theme/TOCInline';
-
-
-
----
-
-## Reference
-
-### `jest `
-
-When you run `jest` with an argument, that argument is treated as a regular expression to match against files in your project. It is possible to run test suites by providing a pattern. Only the files that the pattern matches will be picked up and executed. Depending on your terminal, you may need to quote this argument: `jest "my.*(complex)?pattern"`. On Windows, you will need to use `/` as a path separator or escape `\` as `\\`.
-
-### `--bail[=]`
-
-Alias: `-b`. Exit the test suite immediately upon `n` number of failing test suite. Defaults to `1`.
-
-### `--cache`
-
-Whether to use the cache. Defaults to true. Disable the cache using `--no-cache`.
-
-:::caution
-
-The cache should only be disabled if you are experiencing caching related problems. On average, disabling the cache makes Jest at least two times slower.
-
-:::
-
-If you want to inspect the cache, use `--showConfig` and look at the `cacheDirectory` value. If you need to clear the cache, use `--clearCache`.
-
-### `--changedFilesWithAncestor`
-
-Runs tests related to the current changes and the changes made in the last commit. Behaves similarly to `--onlyChanged`.
-
-### `--changedSince`
-
-Runs tests related to the changes since the provided branch or commit hash. If the current branch has diverged from the given branch, then only changes made locally will be tested. Behaves similarly to `--onlyChanged`.
-
-### `--ci`
-
-When this option is provided, Jest will assume it is running in a CI environment. This changes the behavior when a new snapshot is encountered. Instead of the regular behavior of storing a new snapshot automatically, it will fail the test and require Jest to be run with `--updateSnapshot`.
-
-### `--clearCache`
-
-Deletes the Jest cache directory and then exits without running tests. Will delete `cacheDirectory` if the option is passed, or Jest's default cache directory. The default cache directory can be found by calling `jest --showConfig`.
-
-:::caution
-
-Clearing the cache will reduce performance.
-
-:::
-
-### `--clearMocks`
-
-Automatically clear mock calls, instances, contexts and results before every test. Equivalent to calling [`jest.clearAllMocks()`](JestObjectAPI.md#jestclearallmocks) before each test. This does not remove any mock implementation that may have been provided.
-
-### `--collectCoverageFrom=`
-
-A glob pattern relative to `rootDir` matching the files that coverage info needs to be collected from.
-
-### `--colors`
-
-Forces test results output highlighting even if stdout is not a TTY.
-
-:::note
-
-Alternatively you can set the environment variable `FORCE_COLOR=true` to forcefully enable or `FORCE_COLOR=false` to disable colorized output. The use of `FORCE_COLOR` overrides all other color support checks.
-
-:::
-
-### `--config=`
-
-Alias: `-c`. The path to a Jest config file specifying how to find and execute tests. If no `rootDir` is set in the config, the directory containing the config file is assumed to be the `rootDir` for the project. This can also be a JSON-encoded value which Jest will use as configuration.
-
-### `--coverage[=]`
-
-Alias: `--collectCoverage`. Indicates that test coverage information should be collected and reported in the output. Optionally pass `` to override option set in configuration.
-
-### `--coverageDirectory=`
-
-The directory where Jest should output its coverage files.
-
-### `--coverageProvider=`
-
-Indicates which provider should be used to instrument code for coverage. Allowed values are `babel` (default) or `v8`.
-
-### `--debug`
-
-Print debugging info about your Jest config.
-
-### `--detectOpenHandles`
-
-Attempt to collect and print open handles preventing Jest from exiting cleanly. Use this in cases where you need to use `--forceExit` in order for Jest to exit to potentially track down the reason. This implies `--runInBand`, making tests run serially. Implemented using [`async_hooks`](https://nodejs.org/api/async_hooks.html). This option has a significant performance penalty and should only be used for debugging.
-
-### `--env=`
-
-The test environment used for all tests. This can point to any file or node module. Examples: `jsdom`, `node` or `path/to/my-environment.js`.
-
-### `--errorOnDeprecated`
-
-Make calling deprecated APIs throw helpful error messages. Useful for easing the upgrade process.
-
-### `--expand`
-
-Alias: `-e`. Use this flag to show full diffs and errors instead of a patch.
-
-### `--filter=`
-
-Path to a module exporting a filtering function. This asynchronous function receives a list of test paths which can be manipulated to exclude tests from running by returning an object with shape `{ filtered: Array<{ test: string }> }`. Especially useful when used in conjunction with a testing infrastructure to filter known broken tests, e.g.
-
-```js title="my-filter.js"
-module.exports = testPaths => {
- const allowedPaths = testPaths
- .filter(filteringFunction)
- .map(test => ({test})); // [{ test: "path1.spec.js" }, { test: "path2.spec.js" }, etc]
-
- return {
- filtered: allowedPaths,
- };
-};
-```
-
-### `--findRelatedTests `
-
-Find and run the tests that cover a space separated list of source files that were passed in as arguments. Useful for pre-commit hook integration to run the minimal amount of tests necessary. Can be used together with `--coverage` to include a test coverage for the source files, no duplicate `--collectCoverageFrom` arguments needed.
-
-### `--forceExit`
-
-Force Jest to exit after all tests have completed running. This is useful when resources set up by test code cannot be adequately cleaned up.
-
-:::caution
-
-This feature is an escape-hatch. If Jest doesn't exit at the end of a test run, it means external resources are still being held on to or timers are still pending in your code. It is advised to tear down external resources after each test to make sure Jest can shut down cleanly. You can use `--detectOpenHandles` to help track it down.
-
-:::
-
-### `--help`
-
-Show the help information, similar to this page.
-
-### `--ignoreProjects ... `
-
-Ignore the tests of the specified projects. Jest uses the attribute `displayName` in the configuration to identify each project. If you use this option, you should provide a `displayName` to all your projects.
-
-### `--init`
-
-Generate a basic configuration file. Based on your project, Jest will ask you a few questions that will help to generate a `jest.config.js` file with a short description for each option.
-
-### `--injectGlobals`
-
-Insert Jest's globals (`expect`, `test`, `describe`, `beforeEach` etc.) into the global environment. If you set this to `false`, you should import from `@jest/globals`, e.g.
-
-```ts
-import {expect, jest, test} from '@jest/globals';
-
-jest.useFakeTimers();
-
-test('some test', () => {
- expect(Date.now()).toBe(0);
-});
-```
-
-:::note
-
-This option is only supported using the default `jest-circus` test runner.
-
-:::
-
-### `--json`
-
-Prints the test results in JSON. This mode will send all other test output and user messages to stderr.
-
-### `--lastCommit`
-
-Run all tests affected by file changes in the last commit made. Behaves similarly to `--onlyChanged`.
-
-### `--listTests`
-
-Lists all test files that Jest will run given the arguments, and exits.
-
-### `--logHeapUsage`
-
-Logs the heap usage after every test. Useful to debug memory leaks. Use together with `--runInBand` and `--expose-gc` in node.
-
-### `--maxConcurrency=`
-
-Prevents Jest from executing more than the specified amount of tests at the same time. Only affects tests that use `test.concurrent`.
-
-### `--maxWorkers=|`
-
-Alias: `-w`. Specifies the maximum number of workers the worker-pool will spawn for running tests. In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. In watch mode, this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt. It may be useful to adjust this in resource limited environments like CIs but the defaults should be adequate for most use-cases.
-
-For environments with variable CPUs available, you can use percentage based configuration: `--maxWorkers=50%`
-
-### `--noStackTrace`
-
-Disables stack trace in test results output.
-
-### `--notify`
-
-Activates notifications for test results. Good for when you don't want your consciousness to be able to focus on anything except JavaScript testing.
-
-### `--onlyChanged`
-
-Alias: `-o`. Attempts to identify which tests to run based on which files have changed in the current repository. Only works if you're running tests in a git/hg repository at the moment and requires a static dependency graph (ie. no dynamic requires).
-
-### `--onlyFailures`
-
-Alias: `-f`. Run tests that failed in the previous execution.
-
-### `--openHandlesTimeout=`
-
-When `--detectOpenHandles` and `--forceExit` are _disabled_, Jest will print a warning if the process has not exited cleanly after this number of milliseconds. A value of `0` disables the warning. Defaults to `1000`.
-
-### `--outputFile=`
-
-Write test results to a file when the `--json` option is also specified. The returned JSON structure is documented in [testResultsProcessor](Configuration.md#testresultsprocessor-string).
-
-### `--passWithNoTests`
-
-Allows the test suite to pass when no files are found.
-
-### `--projects ... `
-
-Run tests from one or more projects, found in the specified paths; also takes path globs. This option is the CLI equivalent of the [`projects`](configuration#projects-arraystring--projectconfig) configuration option.
-
-:::note
-
-If configuration files are found in the specified paths, _all_ projects specified within those configuration files will be run.
-
-:::
-
-### `--randomize`
-
-Shuffle the order of the tests within a file. The shuffling is based on the seed. See [`--seed=`](#--seednum) for more info.
-
-Seed value is displayed when this option is set. Equivalent to setting the CLI option [`--showSeed`](#--showseed).
-
-```bash
-jest --randomize --seed 1234
-```
-
-:::note
-
-This option is only supported using the default `jest-circus` test runner.
-
-:::
-
-### `--reporters`
-
-Run tests with specified reporters. [Reporter options](configuration#reporters-arraymodulename--modulename-options) are not available via CLI. Example with multiple reporters:
-
-`jest --reporters="default" --reporters="jest-junit"`
-
-### `--resetMocks`
-
-Automatically reset mock state before every test. Equivalent to calling [`jest.resetAllMocks()`](JestObjectAPI.md#jestresetallmocks) before each test. This will lead to any mocks having their fake implementations removed but does not restore their initial implementation.
-
-### `--restoreMocks`
-
-Automatically restore mock state and implementation before every test. Equivalent to calling [`jest.restoreAllMocks()`](JestObjectAPI.md#jestrestoreallmocks) before each test. This will lead to any mocks having their fake implementations removed and restores their initial implementation.
-
-### `--roots`
-
-A list of paths to directories that Jest should use to search for files in.
-
-### `--runInBand`
-
-Alias: `-i`. Run all tests serially in the current process, rather than creating a worker pool of child processes that run tests. This can be useful for debugging.
-
-### `--runTestsByPath`
-
-Run only the tests that were specified with their exact paths.
-
-:::tip
-
-The default regex matching works fine on small runs, but becomes slow if provided with multiple patterns and/or against a lot of tests. This option replaces the regex matching logic and by that optimizes the time it takes Jest to filter specific test files.
-
-:::
-
-### `--seed=`
-
-Sets a seed value that can be retrieved in a test file via [`jest.getSeed()`](JestObjectAPI.md#jestgetseed). The seed value must be between `-0x80000000` and `0x7fffffff` inclusive (`-2147483648` (`-(2 ** 31)`) and `2147483647` (`2 ** 31 - 1`) in decimal).
-
-```bash
-jest --seed=1324
-```
-
-:::tip
-
-If this option is not specified Jest will randomly generate the value. You can use the [`--showSeed`](#--showseed) flag to print the seed in the test report summary.
-
-Jest uses the seed internally for shuffling the order in which test suites are run. If the [`--randomize`](#--randomize) option is used, the seed is also used for shuffling the order of tests within each `describe` block. When dealing with flaky tests, rerunning with the same seed might help reproduce the failure.
-
-:::
-
-### `--selectProjects ... `
-
-Run the tests of the specified projects. Jest uses the attribute `displayName` in the configuration to identify each project. If you use this option, you should provide a `displayName` to all your projects.
-
-### `--setupFilesAfterEnv ... `
-
-A list of paths to modules that run some code to configure or to set up the testing framework before each test. Beware that files imported by the setup scripts will not be mocked during testing.
-
-### `--shard`
-
-The test suite shard to execute in a format of `(?\d+)/(?\d+)`.
-
-`shardIndex` describes which shard to select while `shardCount` controls the number of shards the suite should be split into.
-
-`shardIndex` and `shardCount` have to be 1-based, positive numbers, and `shardIndex` has to be lower than or equal to `shardCount`.
-
-When `shard` is specified the configured [`testSequencer`](Configuration.md#testsequencer-string) has to implement a `shard` method.
-
-For example, to split the suite into three shards, each running one third of the tests:
-
-```
-jest --shard=1/3
-jest --shard=2/3
-jest --shard=3/3
-```
-
-### `--showConfig`
-
-Print your Jest config and then exits.
-
-### `--showSeed`
-
-Prints the seed value in the test report summary. See [`--seed=`](#--seednum) for the details.
-
-Can also be set in configuration. See [`showSeed`](Configuration.md#showseed-boolean).
-
-### `--silent`
-
-Prevent tests from printing messages through the console.
-
-### `--testEnvironmentOptions=`
-
-A JSON string with options that will be passed to the `testEnvironment`. The relevant options depend on the environment.
-
-### `--testLocationInResults`
-
-Adds a `location` field to test results. Useful if you want to report the location of a test in a reporter.
-
-:::note
-
-In the resulting object `column` is 0-indexed while `line` is not.
-
-```json
-{
- "column": 4,
- "line": 5
-}
-```
-
-:::
-
-### `--testMatch glob1 ... globN`
-
-The glob patterns Jest uses to detect test files. Please refer to the [`testMatch` configuration](Configuration.md#testmatch-arraystring) for details.
-
-### `--testNamePattern=`
-
-Alias: `-t`. Run only tests with a name that matches the regex. For example, suppose you want to run only tests related to authorization which will have names like `'GET /api/posts with auth'`, then you can use `jest -t=auth`.
-
-:::tip
-
-The regex is matched against the full name, which is a combination of the test name and all its surrounding describe blocks.
-
-:::
-
-### `--testPathIgnorePatterns=|[array]`
-
-A single or array of regexp pattern strings that are tested against all tests paths before executing the test. Contrary to `--testPathPattern`, it will only run those tests with a path that does not match with the provided regexp expressions.
-
-To pass as an array use escaped parentheses and space delimited regexps such as `\(/node_modules/ /tests/e2e/\)`. Alternatively, you can omit parentheses by combining regexps into a single regexp like `/node_modules/|/tests/e2e/`. These two examples are equivalent.
-
-### `--testPathPattern=`
-
-A regexp pattern string that is matched against all tests paths before executing the test. On Windows, you will need to use `/` as a path separator or escape `\` as `\\`.
-
-### `--testRunner=`
-
-Lets you specify a custom test runner.
-
-### `--testSequencer=`
-
-Lets you specify a custom test sequencer. Please refer to the [`testSequencer` configuration](Configuration.md#testsequencer-string) for details.
-
-### `--testTimeout=`
-
-Default timeout of a test in milliseconds. Default value: 5000.
-
-### `--updateSnapshot`
-
-Alias: `-u`. Use this flag to re-record every snapshot that fails during this test run. Can be used together with a test suite pattern or with `--testNamePattern` to re-record snapshots.
-
-### `--useStderr`
-
-Divert all output to stderr.
-
-### `--verbose`
-
-Display individual test results with the test suite hierarchy.
-
-### `--version`
-
-Alias: `-v`. Print the version and exit.
-
-### `--watch`
-
-Watch files for changes and rerun tests related to changed files. If you want to re-run all tests when a file has changed, use the `--watchAll` option instead.
-
-:::tip
-
-Use `--no-watch` (or `--watch=false`) to explicitly disable the watch mode if it was enabled using `--watch`. In most CI environments, this is automatically handled for you.
-
-:::
-
-### `--watchAll`
-
-Watch files for changes and rerun all tests when something changes. If you want to re-run only the tests that depend on the changed files, use the `--watch` option.
-
-:::tip
-
-Use `--no-watchAll` (or `--watchAll=false`) to explicitly disable the watch mode if it was enabled using `--watchAll`. In most CI environments, this is automatically handled for you.
-
-:::
-
-### `--watchman`
-
-Whether to use [`watchman`](https://facebook.github.io/watchman/) for file crawling. Defaults to `true`. Disable using `--no-watchman`.
-
-### `--workerThreads`
-
-Whether to use [worker threads](https://nodejs.org/dist/latest/docs/api/worker_threads.html) for parallelization. [Child processes](https://nodejs.org/dist/latest/docs/api/child_process.html) are used by default.
-
-:::caution
-
-This is **experimental feature**. See the [`workerThreads` configuration option](Configuration.md#workerthreads) for more details.
-
-:::
diff --git a/website/versioned_docs/version-29.5/CodeTransformation.md b/website/versioned_docs/version-29.5/CodeTransformation.md
deleted file mode 100644
index 14d96a16f649..000000000000
--- a/website/versioned_docs/version-29.5/CodeTransformation.md
+++ /dev/null
@@ -1,196 +0,0 @@
----
-id: code-transformation
-title: Code Transformation
----
-
-Jest runs the code in your project as JavaScript, but if you use some syntax not supported by Node out of the box (such as JSX, TypeScript, Vue templates) then you'll need to transform that code into plain JavaScript, similar to what you would do when building for browsers.
-
-Jest supports this via the [`transform`](Configuration.md#transform-objectstring-pathtotransformer--pathtotransformer-object) configuration option.
-
-A transformer is a module that provides a method for transforming source files. For example, if you wanted to be able to use a new language feature in your modules or tests that aren't yet supported by Node, you might plug in a code preprocessor that would transpile a future version of JavaScript to a current one.
-
-Jest will cache the result of a transformation and attempt to invalidate that result based on a number of factors, such as the source of the file being transformed and changing configuration.
-
-## Defaults
-
-Jest ships with one transformer out of the box – [`babel-jest`](https://github.com/jestjs/jest/tree/main/packages/babel-jest#setup). It will load your project's Babel configuration and transform any file matching the `/\.[jt]sx?$/` RegExp (in other words, any `.js`, `.jsx`, `.ts` or `.tsx` file). In addition, `babel-jest` will inject the Babel plugin necessary for mock hoisting talked about in [ES Module mocking](ManualMocks.md#using-with-es-module-imports).
-
-:::tip
-
-Remember to include the default `babel-jest` transformer explicitly, if you wish to use it alongside with additional code preprocessors:
-
-```json
-"transform": {
- "\\.[jt]sx?$": "babel-jest",
- "\\.css$": "some-css-transformer",
-}
-```
-
-:::
-
-## Writing custom transformers
-
-You can write your own transformer. The API of a transformer is as follows:
-
-```ts
-interface TransformOptions {
- supportsDynamicImport: boolean;
- supportsExportNamespaceFrom: boolean;
- /**
- * The value is:
- * - `false` if Jest runs without Node ESM flag `--experimental-vm-modules`
- * - `true` if the file extension is defined in [extensionsToTreatAsEsm](Configuration.md#extensionstotreatasesm-arraystring)
- * and Jest runs with Node ESM flag `--experimental-vm-modules`
- *
- * See more at https://jestjs.io/docs/next/ecmascript-modules
- */
- supportsStaticESM: boolean;
- supportsTopLevelAwait: boolean;
- instrument: boolean;
- /** Cached file system which is used by `jest-runtime` to improve performance. */
- cacheFS: Map;
- /** Jest configuration of currently running project. */
- config: ProjectConfig;
- /** Stringified version of the `config` - useful in cache busting. */
- configString: string;
- /** Transformer configuration passed through `transform` option by the user. */
- transformerConfig: TransformerConfig;
-}
-
-type TransformedSource = {
- code: string;
- map?: RawSourceMap | string | null;
-};
-
-interface SyncTransformer {
- canInstrument?: boolean;
-
- getCacheKey?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => string;
-
- getCacheKeyAsync?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => Promise;
-
- process: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => TransformedSource;
-
- processAsync?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => Promise;
-}
-
-interface AsyncTransformer {
- canInstrument?: boolean;
-
- getCacheKey?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => string;
-
- getCacheKeyAsync?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => Promise;
-
- process?: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => TransformedSource;
-
- processAsync: (
- sourceText: string,
- sourcePath: string,
- options: TransformOptions,
- ) => Promise;
-}
-
-type Transformer =
- | SyncTransformer
- | AsyncTransformer;
-
-type TransformerCreator<
- X extends Transformer,
- TransformerConfig = unknown,
-> = (transformerConfig?: TransformerConfig) => X;
-
-type TransformerFactory = {
- createTransformer: TransformerCreator;
-};
-```
-
-:::note
-
-The definitions above were trimmed down for brevity. Full code can be found in [Jest repo on GitHub](https://github.com/jestjs/jest/blob/main/packages/jest-transform/src/types.ts) (remember to choose the right tag/commit for your version of Jest).
-
-:::
-
-There are a couple of ways you can import code into Jest - using Common JS (`require`) or ECMAScript Modules (`import` - which exists in static and dynamic versions). Jest passes files through code transformation on demand (for instance when a `require` or `import` is evaluated). This process, also known as "transpilation", might happen _synchronously_ (in the case of `require`), or _asynchronously_ (in the case of `import` or `import()`, the latter of which also works from Common JS modules). For this reason, the interface exposes both pairs of methods for asynchronous and synchronous processes: `process{Async}` and `getCacheKey{Async}`. The latter is called to figure out if we need to call `process{Async}` at all.
-
-Asynchronous transpilation can fall back to the synchronous `process` call if `processAsync` is unimplemented, but synchronous transpilation cannot use the asynchronous `processAsync` call. If your codebase is ESM only, implementing the async variants are sufficient. Otherwise, if any code is loaded through `require` (including `createRequire` from within ESM), then you need to implement the synchronous `process` variant.
-
-Be aware that `node_modules` is not transpiled with default config, the `transformIgnorePatterns` setting must be modified in order to do so.
-
-Semi-related to this are the supports flags we pass (see `CallerTransformOptions` above), but those should be used within the transform to figure out if it should return ESM or CJS, and has no direct bearing on sync vs async
-
-Though not required, we _highly recommend_ implementing `getCacheKey` as well, so we do not waste resources transpiling when we could have read its previous result from disk. You can use [`@jest/create-cache-key-function`](https://www.npmjs.com/package/@jest/create-cache-key-function) to help implement it.
-
-Instead of having your custom transformer implement the `Transformer` interface directly, you can choose to export `createTransformer`, a factory function to dynamically create transformers. This is to allow having a transformer config in your jest config.
-
-:::note
-
-[ECMAScript module](ECMAScriptModules.md) support is indicated by the passed in `supports*` options. Specifically `supportsDynamicImport: true` means the transformer can return `import()` expressions, which is supported by both ESM and CJS. If `supportsStaticESM: true` it means top level `import` statements are supported and the code will be interpreted as ESM and not CJS. See [Node's docs](https://nodejs.org/api/esm.html#esm_differences_between_es_modules_and_commonjs) for details on the differences.
-
-:::
-
-:::tip
-
-Make sure `process{Async}` method returns source map alongside with transformed code, so it is possible to report line information accurately in code coverage and test errors. Inline source maps also work but are slower.
-
-During the development of a transformer it can be useful to run Jest with `--no-cache` to frequently [delete cache](Troubleshooting.md#caching-issues).
-
-:::
-
-### Examples
-
-### TypeScript with type checking
-
-While `babel-jest` by default will transpile TypeScript files, Babel will not verify the types. If you want that you can use [`ts-jest`](https://github.com/kulshekhar/ts-jest).
-
-#### Transforming images to their path
-
-Importing images is a way to include them in your browser bundle, but they are not valid JavaScript. One way of handling it in Jest is to replace the imported value with its filename.
-
-```js title="fileTransformer.js"
-const path = require('path');
-
-module.exports = {
- process(sourceText, sourcePath, options) {
- return {
- code: `module.exports = ${JSON.stringify(path.basename(sourcePath))};`,
- };
- },
-};
-```
-
-```js title="jest.config.js"
-module.exports = {
- transform: {
- '\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':
- '/fileTransformer.js',
- },
-};
-```
diff --git a/website/versioned_docs/version-29.5/Configuration.md b/website/versioned_docs/version-29.5/Configuration.md
deleted file mode 100644
index d823f21dcd7c..000000000000
--- a/website/versioned_docs/version-29.5/Configuration.md
+++ /dev/null
@@ -1,2493 +0,0 @@
----
-id: configuration
-title: Configuring Jest
----
-
-The Jest philosophy is to work great by default, but sometimes you just need more configuration power.
-
-It is recommended to define the configuration in a dedicated JavaScript, TypeScript or JSON file. The file will be discovered automatically, if it is named `jest.config.js|ts|mjs|cjs|json`. You can use [`--config`](CLI.md#--configpath) flag to pass an explicit path to the file.
-
-:::note
-
-Keep in mind that the resulting configuration object must always be JSON-serializable.
-
-:::
-
-The configuration file should simply export an object:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- verbose: true,
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- verbose: true,
-};
-
-export default config;
-```
-
-Or a function returning an object:
-
-```js tab
-/** @returns {Promise} */
-module.exports = async () => {
- return {
- verbose: true,
- };
-};
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-export default async (): Promise => {
- return {
- verbose: true,
- };
-};
-```
-
-:::tip
-
-To read TypeScript configuration files Jest requires [`ts-node`](https://npmjs.com/package/ts-node). Make sure it is installed in your project.
-
-:::
-
-The configuration also can be stored in a JSON file as a plain object:
-
-```json title="jest.config.json"
-{
- "bail": 1,
- "verbose": true
-}
-```
-
-Alternatively Jest's configuration can be defined through the `"jest"` key in the `package.json` of your project:
-
-```json title="package.json"
-{
- "name": "my-project",
- "jest": {
- "verbose": true
- }
-}
-```
-
-## Options
-
-:::info
-
-You can retrieve Jest's defaults from `jest-config` to extend them if needed:
-
-```js tab
-const {defaults} = require('jest-config');
-
-/** @type {import('jest').Config} */
-const config = {
- moduleFileExtensions: [...defaults.moduleFileExtensions, 'mts', 'cts'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-import {defaults} from 'jest-config';
-
-const config: Config = {
- moduleFileExtensions: [...defaults.moduleFileExtensions, 'mts'],
-};
-
-export default config;
-```
-
-:::
-
-import TOCInline from '@theme/TOCInline';
-
-
-
----
-
-## Reference
-
-### `automock` \[boolean]
-
-Default: `false`
-
-This option tells Jest that all imported modules in your tests should be mocked automatically. All modules used in your tests will have a replacement implementation, keeping the API surface.
-
-Example:
-
-```js title="utils.js"
-export default {
- authorize: () => 'token',
- isAuthorized: secret => secret === 'wizard',
-};
-```
-
-```js title="__tests__/automock.test.js"
-import utils from '../utils';
-
-test('if utils mocked automatically', () => {
- // Public methods of `utils` are now mock functions
- expect(utils.authorize.mock).toBeTruthy();
- expect(utils.isAuthorized.mock).toBeTruthy();
-
- // You can provide them with your own implementation
- // or pass the expected return value
- utils.authorize.mockReturnValue('mocked_token');
- utils.isAuthorized.mockReturnValue(true);
-
- expect(utils.authorize()).toBe('mocked_token');
- expect(utils.isAuthorized('not_wizard')).toBeTruthy();
-});
-```
-
-:::note
-
-Node modules are automatically mocked when you have a manual mock in place (e.g.: `__mocks__/lodash.js`). More info [here](ManualMocks.md#mocking-node-modules).
-
-Node.js core modules, like `fs`, are not mocked by default. They can be mocked explicitly, like `jest.mock('fs')`.
-
-:::
-
-### `bail` \[number | boolean]
-
-Default: `0`
-
-By default, Jest runs all tests and produces all errors into the console upon completion. The bail config option can be used here to have Jest stop running tests after `n` failures. Setting bail to `true` is the same as setting bail to `1`.
-
-### `cacheDirectory` \[string]
-
-Default: `"/tmp/"`
-
-The directory where Jest should store its cached dependency information.
-
-Jest attempts to scan your dependency tree once (up-front) and cache it in order to ease some of the filesystem churn that needs to happen while running tests. This config option lets you customize where Jest stores that cache data on disk.
-
-### `clearMocks` \[boolean]
-
-Default: `false`
-
-Automatically clear mock calls, instances, contexts and results before every test. Equivalent to calling [`jest.clearAllMocks()`](JestObjectAPI.md#jestclearallmocks) before each test. This does not remove any mock implementation that may have been provided.
-
-### `collectCoverage` \[boolean]
-
-Default: `false`
-
-Indicates whether the coverage information should be collected while executing the test. Because this retrofits all executed files with coverage collection statements, it may significantly slow down your tests.
-
-Jest ships with two coverage providers: `babel` (default) and `v8`. See the [`coverageProvider`](#coverageprovider-string) option for more details.
-
-:::info
-
-The `babel` and `v8` coverage providers use `/* istanbul ignore next */` and `/* c8 ignore next */` comments to exclude lines from coverage reports, respectively. For more information, you can view the [`istanbuljs` documentation](https://github.com/istanbuljs/nyc#parsing-hints-ignoring-lines) and the [`c8` documentation](https://github.com/bcoe/c8#ignoring-uncovered-lines-functions-and-blocks).
-
-:::
-
-### `collectCoverageFrom` \[array]
-
-Default: `undefined`
-
-An array of [glob patterns](https://github.com/micromatch/micromatch) indicating a set of files for which coverage information should be collected. If a file matches the specified glob pattern, coverage information will be collected for it even if no tests exist for this file and it's never required in the test suite.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- collectCoverageFrom: [
- '**/*.{js,jsx}',
- '!**/node_modules/**',
- '!**/vendor/**',
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- collectCoverageFrom: [
- '**/*.{js,jsx}',
- '!**/node_modules/**',
- '!**/vendor/**',
- ],
-};
-
-export default config;
-```
-
-This will collect coverage information for all the files inside the project's `rootDir`, except the ones that match `**/node_modules/**` or `**/vendor/**`.
-
-:::tip
-
-Each glob pattern is applied in the order they are specified in the config. For example `["!**/__tests__/**", "**/*.js"]` will not exclude `__tests__` because the negation is overwritten with the second pattern. In order to make the negated glob work in this example it has to come after `**/*.js`.
-
-:::
-
-:::note
-
-This option requires `collectCoverage` to be set to `true` or Jest to be invoked with `--coverage`.
-
-:::
-
-
- Help:
-
-If you are seeing coverage output such as...
-
-```
-=============================== Coverage summary ===============================
-Statements : Unknown% ( 0/0 )
-Branches : Unknown% ( 0/0 )
-Functions : Unknown% ( 0/0 )
-Lines : Unknown% ( 0/0 )
-================================================================================
-Jest: Coverage data for global was not found.
-```
-
-Most likely your glob patterns are not matching any files. Refer to the [micromatch](https://github.com/micromatch/micromatch) documentation to ensure your globs are compatible.
-
-
-
-### `coverageDirectory` \[string]
-
-Default: `undefined`
-
-The directory where Jest should output its coverage files.
-
-### `coveragePathIgnorePatterns` \[array<string>]
-
-Default: `["/node_modules/"]`
-
-An array of regexp pattern strings that are matched against all file paths before executing the test. If the file path matches any of the patterns, coverage information will be skipped.
-
-These pattern strings match against the full path. Use the `` string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: `["/build/", "/node_modules/"]`.
-
-### `coverageProvider` \[string]
-
-Indicates which provider should be used to instrument code for coverage. Allowed values are `babel` (default) or `v8`.
-
-### `coverageReporters` \[array<string | \[string, options]>]
-
-Default: `["clover", "json", "lcov", "text"]`
-
-A list of reporter names that Jest uses when writing coverage reports. Any [istanbul reporter](https://github.com/istanbuljs/istanbuljs/tree/master/packages/istanbul-reports/lib) can be used.
-
-:::tip
-
-Setting this option overwrites the default values. Add `"text"` or `"text-summary"` to see a coverage summary in the console output.
-
-:::
-
-Additional options can be passed using the tuple form. For example, you may hide coverage report lines for all fully-covered files:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- coverageReporters: ['clover', 'json', 'lcov', ['text', {skipFull: true}]],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- coverageReporters: ['clover', 'json', 'lcov', ['text', {skipFull: true}]],
-};
-
-export default config;
-```
-
-For more information about the options object shape refer to `CoverageReporterWithOptions` type in the [type definitions](https://github.com/jestjs/jest/tree/main/packages/jest-types/src/Config.ts).
-
-### `coverageThreshold` \[object]
-
-Default: `undefined`
-
-This will be used to configure minimum threshold enforcement for coverage results. Thresholds can be specified as `global`, as a [glob](https://github.com/isaacs/node-glob#glob-primer), and as a directory or file path. If thresholds aren't met, jest will fail. Thresholds specified as a positive number are taken to be the minimum percentage required. Thresholds specified as a negative number represent the maximum number of uncovered entities allowed.
-
-For example, with the following configuration jest will fail if there is less than 80% branch, line, and function coverage, or if there are more than 10 uncovered statements:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- coverageThreshold: {
- global: {
- branches: 80,
- functions: 80,
- lines: 80,
- statements: -10,
- },
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- coverageThreshold: {
- global: {
- branches: 80,
- functions: 80,
- lines: 80,
- statements: -10,
- },
- },
-};
-
-export default config;
-```
-
-If globs or paths are specified alongside `global`, coverage data for matching paths will be subtracted from overall coverage and thresholds will be applied independently. Thresholds for globs are applied to all files matching the glob. If the file specified by path is not found, an error is returned.
-
-For example, with the following configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- coverageThreshold: {
- global: {
- branches: 50,
- functions: 50,
- lines: 50,
- statements: 50,
- },
- './src/components/': {
- branches: 40,
- statements: 40,
- },
- './src/reducers/**/*.js': {
- statements: 90,
- },
- './src/api/very-important-module.js': {
- branches: 100,
- functions: 100,
- lines: 100,
- statements: 100,
- },
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- coverageThreshold: {
- global: {
- branches: 50,
- functions: 50,
- lines: 50,
- statements: 50,
- },
- './src/components/': {
- branches: 40,
- statements: 40,
- },
- './src/reducers/**/*.js': {
- statements: 90,
- },
- './src/api/very-important-module.js': {
- branches: 100,
- functions: 100,
- lines: 100,
- statements: 100,
- },
- },
-};
-
-export default config;
-```
-
-Jest will fail if:
-
-- The `./src/components` directory has less than 40% branch or statement coverage.
-- One of the files matching the `./src/reducers/**/*.js` glob has less than 90% statement coverage.
-- The `./src/api/very-important-module.js` file has less than 100% coverage.
-- Every remaining file combined has less than 50% coverage (`global`).
-
-### `dependencyExtractor` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom dependency extractor. It must be a node module that exports an object with an `extract` function. E.g.:
-
-```javascript
-const crypto = require('crypto');
-const fs = require('fs');
-
-module.exports = {
- extract(code, filePath, defaultExtract) {
- const deps = defaultExtract(code, filePath);
- // Scan the file and add dependencies in `deps` (which is a `Set`)
- return deps;
- },
- getCacheKey() {
- return crypto
- .createHash('md5')
- .update(fs.readFileSync(__filename))
- .digest('hex');
- },
-};
-```
-
-The `extract` function should return an iterable (`Array`, `Set`, etc.) with the dependencies found in the code.
-
-That module can also contain a `getCacheKey` function to generate a cache key to determine if the logic has changed and any cached artifacts relying on it should be discarded.
-
-### `displayName` \[string, object]
-
-default: `undefined`
-
-Allows for a label to be printed alongside a test while it is running. This becomes more useful in multi-project repositories where there can be many jest configuration files. This visually tells which project a test belongs to.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- displayName: 'CLIENT',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- displayName: 'CLIENT',
-};
-
-export default config;
-```
-
-Alternatively, an object with the properties `name` and `color` can be passed. This allows for a custom configuration of the background color of the displayName. `displayName` defaults to white when its value is a string. Jest uses [`chalk`](https://github.com/chalk/chalk) to provide the color. As such, all of the valid options for colors supported by `chalk` are also supported by Jest.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- displayName: {
- name: 'CLIENT',
- color: 'blue',
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- displayName: {
- name: 'CLIENT',
- color: 'blue',
- },
-};
-
-export default config;
-```
-
-### `errorOnDeprecated` \[boolean]
-
-Default: `false`
-
-Make calling deprecated APIs throw helpful error messages. Useful for easing the upgrade process.
-
-### `extensionsToTreatAsEsm` \[array<string>]
-
-Default: `[]`
-
-Jest will run `.mjs` and `.js` files with nearest `package.json`'s `type` field set to `module` as ECMAScript Modules. If you have any other files that should run with native ESM, you need to specify their file extension here.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- extensionsToTreatAsEsm: ['.ts'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- extensionsToTreatAsEsm: ['.ts'],
-};
-
-export default config;
-```
-
-:::caution
-
-Jest's ESM support is still experimental, see [its docs for more details](ECMAScriptModules.md).
-
-:::
-
-### `fakeTimers` \[object]
-
-Default: `{}`
-
-The fake timers may be useful when a piece of code sets a long timeout that we don't want to wait for in a test. For additional details see [Fake Timers guide](TimerMocks.md) and [API documentation](JestObjectAPI.md#fake-timers).
-
-This option provides the default configuration of fake timers for all tests. Calling `jest.useFakeTimers()` in a test file will use these options or will override them if a configuration object is passed. For example, you can tell Jest to keep the original implementation of `process.nextTick()` and adjust the limit of recursive timers that will be run:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- fakeTimers: {
- doNotFake: ['nextTick'],
- timerLimit: 1000,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- fakeTimers: {
- doNotFake: ['nextTick'],
- timerLimit: 1000,
- },
-};
-
-export default config;
-```
-
-```js title="fakeTime.test.js"
-// install fake timers for this file using the options from Jest configuration
-jest.useFakeTimers();
-
-test('increase the limit of recursive timers for this and following tests', () => {
- jest.useFakeTimers({timerLimit: 5000});
- // ...
-});
-```
-
-:::tip
-
-Instead of including `jest.useFakeTimers()` in each test file, you can enable fake timers globally for all tests in your Jest configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- fakeTimers: {
- enableGlobally: true,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- fakeTimers: {
- enableGlobally: true,
- },
-};
-
-export default config;
-```
-
-:::
-
-Configuration options:
-
-```ts
-type FakeableAPI =
- | 'Date'
- | 'hrtime'
- | 'nextTick'
- | 'performance'
- | 'queueMicrotask'
- | 'requestAnimationFrame'
- | 'cancelAnimationFrame'
- | 'requestIdleCallback'
- | 'cancelIdleCallback'
- | 'setImmediate'
- | 'clearImmediate'
- | 'setInterval'
- | 'clearInterval'
- | 'setTimeout'
- | 'clearTimeout';
-
-type ModernFakeTimersConfig = {
- /**
- * If set to `true` all timers will be advanced automatically by 20 milliseconds
- * every 20 milliseconds. A custom time delta may be provided by passing a number.
- * The default is `false`.
- */
- advanceTimers?: boolean | number;
- /**
- * List of names of APIs that should not be faked. The default is `[]`, meaning
- * all APIs are faked.
- */
- doNotFake?: Array;
- /** Whether fake timers should be enabled for all test files. The default is `false`. */
- enableGlobally?: boolean;
- /**
- * Use the old fake timers implementation instead of one backed by `@sinonjs/fake-timers`.
- * The default is `false`.
- */
- legacyFakeTimers?: boolean;
- /** Sets current system time to be used by fake timers, in milliseconds. The default is `Date.now()`. */
- now?: number;
- /** Maximum number of recursive timers that will be run. The default is `100_000` timers. */
- timerLimit?: number;
-};
-```
-
-:::info Legacy Fake Timers
-
-For some reason you might have to use legacy implementation of fake timers. Here is how to enable it globally (additional options are not supported):
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- fakeTimers: {
- enableGlobally: true,
- legacyFakeTimers: true,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- fakeTimers: {
- enableGlobally: true,
- legacyFakeTimers: true,
- },
-};
-
-export default config;
-```
-
-:::
-
-### `forceCoverageMatch` \[array<string>]
-
-Default: `['']`
-
-Test files are normally ignored from collecting code coverage. With this option, you can overwrite this behavior and include otherwise ignored files in code coverage.
-
-For example, if you have tests in source files named with `.t.js` extension as following:
-
-```javascript title="sum.t.js"
-export function sum(a, b) {
- return a + b;
-}
-
-if (process.env.NODE_ENV === 'test') {
- test('sum', () => {
- expect(sum(1, 2)).toBe(3);
- });
-}
-```
-
-You can collect coverage from those files with setting `forceCoverageMatch`.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- forceCoverageMatch: ['**/*.t.js'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- forceCoverageMatch: ['**/*.t.js'],
-};
-
-export default config;
-```
-
-### `globals` \[object]
-
-Default: `{}`
-
-A set of global variables that need to be available in all test environments.
-
-For example, the following would create a global `__DEV__` variable set to `true` in all test environments:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- globals: {
- __DEV__: true,
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- globals: {
- __DEV__: true,
- },
-};
-
-export default config;
-```
-
-:::note
-
-If you specify a global reference value (like an object or array) here, and some code mutates that value in the midst of running a test, that mutation will _not_ be persisted across test runs for other test files. In addition, the `globals` object must be json-serializable, so it can't be used to specify global functions. For that, you should use `setupFiles`.
-
-:::
-
-### `globalSetup` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom global setup module, which must export a function (it can be sync or async). The function will be triggered once before all test suites and it will receive two arguments: Jest's [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422) and [`projectConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L424-L481).
-
-:::info
-
-A global setup module configured in a project (using multi-project runner) will be triggered only when you run at least one test from this project.
-
-Any global variables that are defined through `globalSetup` can only be read in `globalTeardown`. You cannot retrieve globals defined here in your test suites.
-
-While code transformation is applied to the linked setup-file, Jest will **not** transform any code in `node_modules`. This is due to the need to load the actual transformers (e.g. `babel` or `typescript`) to perform transformation.
-
-:::
-
-```js title="setup.js"
-module.exports = async function (globalConfig, projectConfig) {
- console.log(globalConfig.testPathPattern);
- console.log(projectConfig.cache);
-
- // Set reference to mongod in order to close the server during teardown.
- globalThis.__MONGOD__ = mongod;
-};
-```
-
-```js title="teardown.js"
-module.exports = async function (globalConfig, projectConfig) {
- console.log(globalConfig.testPathPattern);
- console.log(projectConfig.cache);
-
- await globalThis.__MONGOD__.stop();
-};
-```
-
-### `globalTeardown` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom global teardown module which must export a function (it can be sync or async). The function will be triggered once after all test suites and it will receive two arguments: Jest's [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422) and [`projectConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L424-L481).
-
-:::info
-
-A global teardown module configured in a project (using multi-project runner) will be triggered only when you run at least one test from this project.
-
-The same caveat concerning transformation of `node_modules` as for `globalSetup` applies to `globalTeardown`.
-
-:::
-
-### `haste` \[object]
-
-Default: `undefined`
-
-This will be used to configure the behavior of `jest-haste-map`, Jest's internal file crawler/cache system. The following options are supported:
-
-```ts
-type HasteConfig = {
- /** Whether to hash files using SHA-1. */
- computeSha1?: boolean;
- /** The platform to use as the default, e.g. 'ios'. */
- defaultPlatform?: string | null;
- /** Force use of Node's `fs` APIs rather than shelling out to `find` */
- forceNodeFilesystemAPI?: boolean;
- /**
- * Whether to follow symlinks when crawling for files.
- * This options cannot be used in projects which use watchman.
- * Projects with `watchman` set to true will error if this option is set to true.
- */
- enableSymlinks?: boolean;
- /** Path to a custom implementation of Haste. */
- hasteImplModulePath?: string;
- /** All platforms to target, e.g ['ios', 'android']. */
- platforms?: Array;
- /** Whether to throw an error on module collision. */
- throwOnModuleCollision?: boolean;
- /** Custom HasteMap module */
- hasteMapModulePath?: string;
- /** Whether to retain all files, allowing e.g. search for tests in `node_modules`. */
- retainAllFiles?: boolean;
-};
-```
-
-### `injectGlobals` \[boolean]
-
-Default: `true`
-
-Insert Jest's globals (`expect`, `test`, `describe`, `beforeEach` etc.) into the global environment. If you set this to `false`, you should import from `@jest/globals`, e.g.
-
-```ts
-import {expect, jest, test} from '@jest/globals';
-
-jest.useFakeTimers();
-
-test('some test', () => {
- expect(Date.now()).toBe(0);
-});
-```
-
-:::note
-
-This option is only supported using the default `jest-circus` test runner.
-
-:::
-
-### `maxConcurrency` \[number]
-
-Default: `5`
-
-A number limiting the number of tests that are allowed to run at the same time when using `test.concurrent`. Any test above this limit will be queued and executed once a slot is released.
-
-### `maxWorkers` \[number | string]
-
-Specifies the maximum number of workers the worker-pool will spawn for running tests. In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. In watch mode, this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt. It may be useful to adjust this in resource limited environments like CIs but the defaults should be adequate for most use-cases.
-
-For environments with variable CPUs available, you can use percentage based configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- maxWorkers: '50%',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- maxWorkers: '50%',
-};
-
-export default config;
-```
-
-### `moduleDirectories` \[array<string>]
-
-Default: `["node_modules"]`
-
-An array of directory names to be searched recursively up from the requiring module's location. Setting this option will _override_ the default, if you wish to still search `node_modules` for packages include it along with any other options:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- moduleDirectories: ['node_modules', 'bower_components'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- moduleDirectories: ['node_modules', 'bower_components'],
-};
-
-export default config;
-```
-
-:::caution
-
-It is discouraged to use `'.'` as one of the `moduleDirectories`, because this prevents scoped packages such as `@emotion/react` from accessing packages with the same subdirectory name (`react`). See [this issue](https://github.com/jestjs/jest/issues/10498) for more details. In most cases, it is preferable to use the [moduleNameMapper](#modulenamemapper-objectstring-string--arraystring) configuration instead.
-
-:::
-
-### `moduleFileExtensions` \[array<string>]
-
-Default: `["js", "mjs", "cjs", "jsx", "ts", "tsx", "json", "node"]`
-
-An array of file extensions your modules use. If you require modules without specifying a file extension, these are the extensions Jest will look for, in left-to-right order.
-
-We recommend placing the extensions most commonly used in your project on the left, so if you are using TypeScript, you may want to consider moving "ts" and/or "tsx" to the beginning of the array.
-
-### `moduleNameMapper` \[object<string, string | array<string>>]
-
-Default: `null`
-
-A map from regular expressions to module names or to arrays of module names that allow to stub out resources, like images or styles with a single module.
-
-Modules that are mapped to an alias are unmocked by default, regardless of whether automocking is enabled or not.
-
-Use `` string token to refer to [`rootDir`](#rootdir-string) value if you want to use file paths.
-
-Additionally, you can substitute captured regex groups using numbered backreferences.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- moduleNameMapper: {
- '^image![a-zA-Z0-9$_-]+$': 'GlobalImageStub',
- '^[./a-zA-Z0-9$_-]+\\.png$': '/RelativeImageStub.js',
- 'module_name_(.*)': '/substituted_module_$1.js',
- 'assets/(.*)': [
- '/images/$1',
- '/photos/$1',
- '/recipes/$1',
- ],
- },
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- moduleNameMapper: {
- '^image![a-zA-Z0-9$_-]+$': 'GlobalImageStub',
- '^[./a-zA-Z0-9$_-]+\\.png$': '/RelativeImageStub.js',
- 'module_name_(.*)': '/substituted_module_$1.js',
- 'assets/(.*)': [
- '/images/$1',
- '/photos/$1',
- '/recipes/$1',
- ],
- },
-};
-
-export default config;
-```
-
-The order in which the mappings are defined matters. Patterns are checked one by one until one fits. The most specific rule should be listed first. This is true for arrays of module names as well.
-
-:::info
-
-If you provide module names without boundaries `^$` it may cause hard to spot errors. E.g. `relay` will replace all modules which contain `relay` as a substring in its name: `relay`, `react-relay` and `graphql-relay` will all be pointed to your stub.
-
-:::
-
-### `modulePathIgnorePatterns` \[array<string>]
-
-Default: `[]`
-
-An array of regexp pattern strings that are matched against all module paths before those paths are to be considered 'visible' to the module loader. If a given module's path matches any of the patterns, it will not be `require()`-able in the test environment.
-
-These pattern strings match against the full path. Use the `` string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- modulePathIgnorePatterns: ['/build/'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- modulePathIgnorePatterns: ['/build/'],
-};
-
-export default config;
-```
-
-### `modulePaths` \[array<string>]
-
-Default: `[]`
-
-An alternative API to setting the `NODE_PATH` env variable, `modulePaths` is an array of absolute paths to additional locations to search when resolving modules. Use the `` string token to include the path to your project's root directory.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- modulePaths: ['/app/'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- modulePaths: ['/app/'],
-};
-
-export default config;
-```
-
-### `notify` \[boolean]
-
-Default: `false`
-
-Activates native OS notifications for test results. To display the notifications Jest needs [`node-notifier`](https://github.com/mikaelbr/node-notifier) package, which must be installed additionally:
-
-```bash npm2yarn
-npm install --save-dev node-notifier
-```
-
-:::tip
-
-On macOS, remember to allow notifications from `terminal-notifier` under System Preferences > Notifications & Focus.
-
-On Windows, `node-notifier` creates a new start menu entry on the first use and not display the notification. Notifications will be properly displayed on subsequent runs.
-
-:::
-
-### `notifyMode` \[string]
-
-Default: `failure-change`
-
-Specifies notification mode. Requires `notify: true`.
-
-#### Modes
-
-- `always`: always send a notification.
-- `failure`: send a notification when tests fail.
-- `success`: send a notification when tests pass.
-- `change`: send a notification when the status changed.
-- `success-change`: send a notification when tests pass or once when it fails.
-- `failure-change`: send a notification when tests fail or once when it passes.
-
-### `openHandlesTimeout` \[number]
-
-Default: `1000`
-
-Print a warning indicating that there are probable open handles if Jest does not exit cleanly this number of milliseconds after it completes. Use `0` to disable the warning.
-
-### `preset` \[string]
-
-Default: `undefined`
-
-A preset that is used as a base for Jest's configuration. A preset should point to an npm module that has a `jest-preset.json`, `jest-preset.js`, `jest-preset.cjs` or `jest-preset.mjs` file at the root.
-
-For example, this preset `foo-bar/jest-preset.js` will be configured as follows:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- preset: 'foo-bar',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- preset: 'foo-bar',
-};
-
-export default config;
-```
-
-Presets may also be relative to filesystem paths:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- preset: './node_modules/foo-bar/jest-preset.js',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- preset: './node_modules/foo-bar/jest-preset.js',
-};
-
-export default config;
-```
-
-:::info
-
-If you also have specified [`rootDir`](#rootdir-string), the resolution of this file will be relative to that root directory.
-
-:::
-
-### `prettierPath` \[string]
-
-Default: `'prettier'`
-
-Sets the path to the [`prettier`](https://prettier.io/) node module used to update inline snapshots.
-
-### `projects` \[array<string | ProjectConfig>]
-
-Default: `undefined`
-
-When the `projects` configuration is provided with an array of paths or glob patterns, Jest will run tests in all of the specified projects at the same time. This is great for monorepos or when working on multiple projects at the same time.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- projects: ['', '/examples/*'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- projects: ['', '/examples/*'],
-};
-
-export default config;
-```
-
-This example configuration will run Jest in the root directory as well as in every folder in the examples directory. You can have an unlimited amount of projects running in the same Jest instance.
-
-The projects feature can also be used to run multiple configurations or multiple [runners](#runner-string). For this purpose, you can pass an array of configuration objects. For example, to run both tests and ESLint (via [jest-runner-eslint](https://github.com/jest-community/jest-runner-eslint)) in the same invocation of Jest:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- projects: [
- {
- displayName: 'test',
- },
- {
- displayName: 'lint',
- runner: 'jest-runner-eslint',
- testMatch: ['/**/*.js'],
- },
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- projects: [
- {
- displayName: 'test',
- },
- {
- displayName: 'lint',
- runner: 'jest-runner-eslint',
- testMatch: ['/**/*.js'],
- },
- ],
-};
-
-export default config;
-```
-
-:::tip
-
-When using multi-project runner, it's recommended to add a `displayName` for each project. This will show the `displayName` of a project next to its tests.
-
-:::
-
-:::note
-
-With the `projects` option enabled, Jest will copy the root-level configuration options to each individual child configuration during the test run, resolving its values in the child's context. This means that string tokens like `` will point to the _child's root directory_ even if they are defined in the root-level configuration.
-
-:::
-
-### `randomize` \[boolean]
-
-Default: `false`
-
-The equivalent of the [`--randomize`](CLI.md#--randomize) flag to randomize the order of the tests in a file.
-
-### `reporters` \[array<moduleName | \[moduleName, options]>]
-
-Default: `undefined`
-
-Use this configuration option to add reporters to Jest. It must be a list of reporter names, additional options can be passed to a reporter using the tuple form:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: [
- 'default',
- ['/custom-reporter.js', {banana: 'yes', pineapple: 'no'}],
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: [
- 'default',
- ['/custom-reporter.js', {banana: 'yes', pineapple: 'no'}],
- ],
-};
-
-export default config;
-```
-
-#### Default Reporter
-
-If custom reporters are specified, the default Jest reporter will be overridden. If you wish to keep it, `'default'` must be passed as a reporters name:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: [
- 'default',
- ['jest-junit', {outputDirectory: 'reports', outputName: 'report.xml'}],
- ],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: [
- 'default',
- ['jest-junit', {outputDirectory: 'reports', outputName: 'report.xml'}],
- ],
-};
-
-export default config;
-```
-
-#### GitHub Actions Reporter
-
-If included in the list, the built-in GitHub Actions Reporter will annotate changed files with test failure messages and (if used with `'silent: false'`) print logs with github group features for easy navigation. Note that `'default'` should not be used in this case as `'github-actions'` will handle that already, so remember to also include `'summary'`. If you wish to use it only for annotations simply leave only the reporter without options as the default value of `'silent'` is `'true'`:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: [['github-actions', {silent: false}], 'summary'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: [['github-actions', {silent: false}], 'summary'],
-};
-
-export default config;
-```
-
-#### Summary Reporter
-
-Summary reporter prints out summary of all tests. It is a part of default reporter, hence it will be enabled if `'default'` is included in the list. For instance, you might want to use it as stand-alone reporter instead of the default one, or together with [Silent Reporter](https://github.com/rickhanlonii/jest-silent-reporter):
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: ['jest-silent-reporter', 'summary'],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: ['jest-silent-reporter', 'summary'],
-};
-
-export default config;
-```
-
-The `summary` reporter accepts options. Since it is included in the `default` reporter you may also pass the options there.
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- reporters: [['default', {summaryThreshold: 10}]],
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- reporters: [['default', {summaryThreshold: 10}]],
-};
-
-export default config;
-```
-
-The `summaryThreshold` option behaves in the following way, if the total number of test suites surpasses this threshold, a detailed summary of all failed tests will be printed after executing all the tests. It defaults to `20`.
-
-#### Custom Reporters
-
-:::tip
-
-Hungry for reporters? Take a look at long list of [awesome reporters](https://github.com/jest-community/awesome-jest/blob/main/README.md#reporters) from Awesome Jest.
-
-:::
-
-Custom reporter module must export a class that takes [`globalConfig`](https://github.com/jestjs/jest/blob/v29.2.1/packages/jest-types/src/Config.ts#L358-L422), `reporterOptions` and `reporterContext` as constructor arguments:
-
-```js title="custom-reporter.js"
-class CustomReporter {
- constructor(globalConfig, reporterOptions, reporterContext) {
- this._globalConfig = globalConfig;
- this._options = reporterOptions;
- this._context = reporterContext;
- }
-
- onRunComplete(testContexts, results) {
- console.log('Custom reporter output:');
- console.log('global config:', this._globalConfig);
- console.log('options for this reporter from Jest config:', this._options);
- console.log('reporter context passed from test scheduler:', this._context);
- }
-
- // Optionally, reporters can force Jest to exit with non zero code by returning
- // an `Error` from `getLastError()` method.
- getLastError() {
- if (this._shouldFail) {
- return new Error('Custom error reported!');
- }
- }
-}
-
-module.exports = CustomReporter;
-```
-
-:::note
-
-For the full list of hooks and argument types see the `Reporter` interface in [packages/jest-reporters/src/types.ts](https://github.com/jestjs/jest/blob/main/packages/jest-reporters/src/types.ts).
-
-:::
-
-### `resetMocks` \[boolean]
-
-Default: `false`
-
-Automatically reset mock state before every test. Equivalent to calling [`jest.resetAllMocks()`](JestObjectAPI.md#jestresetallmocks) before each test. This will lead to any mocks having their fake implementations removed but does not restore their initial implementation.
-
-### `resetModules` \[boolean]
-
-Default: `false`
-
-By default, each test file gets its own independent module registry. Enabling `resetModules` goes a step further and resets the module registry before running each individual test. This is useful to isolate modules for every test so that the local module state doesn't conflict between tests. This can be done programmatically using [`jest.resetModules()`](JestObjectAPI.md#jestresetmodules).
-
-### `resolver` \[string]
-
-Default: `undefined`
-
-This option allows the use of a custom resolver. This resolver must be a module that exports _either_:
-
-1. a function expecting a string as the first argument for the path to resolve and an options object as the second argument. The function should either return a path to the module that should be resolved or throw an error if the module can't be found. _or_
-2. an object containing `async` and/or `sync` properties. The `sync` property should be a function with the shape explained above, and the `async` property should also be a function that accepts the same arguments, but returns a promise which resolves with the path to the module or rejects with an error.
-
-The options object provided to resolvers has the shape:
-
-```ts
-type ResolverOptions = {
- /** Directory to begin resolving from. */
- basedir: string;
- /** List of export conditions. */
- conditions?: Array;
- /** Instance of default resolver. */
- defaultResolver: (path: string, options: ResolverOptions) => string;
- /** List of file extensions to search in order. */
- extensions?: Array;
- /** List of directory names to be looked up for modules recursively. */
- moduleDirectory?: Array;
- /** List of `require.paths` to use if nothing is found in `node_modules`. */
- paths?: Array;
- /** Allows transforming parsed `package.json` contents. */
- packageFilter?: (pkg: PackageJSON, file: string, dir: string) => PackageJSON;
- /** Allows transforms a path within a package. */
- pathFilter?: (pkg: PackageJSON, path: string, relativePath: string) => string;
- /** Current root directory. */
- rootDir?: string;
-};
-```
-
-:::tip
-
-The `defaultResolver` passed as an option is the Jest default resolver which might be useful when you write your custom one. It takes the same arguments as your custom synchronous one, e.g. `(path, options)` and returns a string or throws.
-
-:::
-
-For example, if you want to respect Browserify's [`"browser"` field](https://github.com/browserify/browserify-handbook/blob/master/readme.markdown#browser-field), you can use the following resolver:
-
-```js title="resolver.js"
-const browserResolve = require('browser-resolve');
-
-module.exports = browserResolve.sync;
-```
-
-And add it to Jest configuration:
-
-```js tab
-/** @type {import('jest').Config} */
-const config = {
- resolver: '/resolver.js',
-};
-
-module.exports = config;
-```
-
-```ts tab
-import type {Config} from 'jest';
-
-const config: Config = {
- resolver: '/resolver.js',
-};
-
-export default config;
-```
-
-By combining `defaultResolver` and `packageFilter` we can implement a `package.json` "pre-processor" that allows us to change how the default resolver will resolve modules. For example, imagine we want to use the field `"module"` if it is present, otherwise fallback to `"main"`:
-
-```js
-module.exports = (path, options) => {
- // Call the defaultResolver, so we leverage its cache, error handling, etc.
- return options.defaultResolver(path, {
- ...options,
- // Use packageFilter to process parsed `package.json` before the resolution (see https://www.npmjs.com/package/resolve#resolveid-opts-cb)
- packageFilter: pkg => {
- return {
- ...pkg,
- // Alter the value of `main` before resolving the package
- main: pkg.module || pkg.main,
- };
- },
- });
-};
-```
-
-### `restoreMocks` \[boolean]
-
-Default: `false`
-
-Automatically restore mock state and implementation before every test. Equivalent to calling [`jest.restoreAllMocks()`](JestObjectAPI.md#jestrestoreallmocks) before each test. This will lead to any mocks having their fake implementations removed and restores their initial implementation.
-
-### `rootDir` \[string]
-
-Default: The root of the directory containing your Jest [config file](#) _or_ the `package.json` _or_ the [`pwd`](http://en.wikipedia.org/wiki/Pwd) if no `package.json` is found
-
-The root directory that Jest should scan for tests and modules within. If you put your Jest config inside your `package.json` and want the root directory to be the root of your repo, the value for this config param will default to the directory of the `package.json`.
-
-Oftentimes, you'll want to set this to `'src'` or `'lib'`, corresponding to where in your repository the code is stored.
-
-:::tip
-
-Using `''` as a string token in any other path-based configuration settings will refer back to this value. For example, if you want a [`setupFiles`](#setupfiles-array) entry to point at the `some-setup.js` file at the root of the project, set its value to: `'/some-setup.js'`.
-
-:::
-
-### `roots` \[array<string>]
-
-Default: `[""]`
-
-A list of paths to directories that Jest should use to search for files in.
-
-There are times where you only want Jest to search in a single sub-directory (such as cases where you have a `src/` directory in your repo), but prevent it from accessing the rest of the repo.
-
-:::info
-
-While `rootDir` is mostly used as a token to be re-used in other configuration options, `roots` is used by the internals of Jest to locate **test files and source files**. This applies also when searching for manual mocks for modules from `node_modules` (`__mocks__` will need to live in one of the `roots`).
-
-By default, `roots` has a single entry `` but there are cases where you may want to have multiple roots within one project, for example `roots: ["/src/", "