@vitest-agent/mcp 1.1.0 → 1.3.0

package/vendor/vitest-docs/config/onunhandlederror.md

@@ -1,35 +0,0 @@
-# onUnhandledError <CRoot /> <Version>4.0.0</Version>
-
-- **Type:**
-
-```ts
-function onUnhandledError(
-  error: (TestError | Error) & { type: string }
-): boolean | void
-```
-
-A custom callback for filtering unhandled errors that should not be reported. When an error is filtered out, it no longer affects the result of the test run.
-
-To report unhandled errors without affecting the test outcome, use the [`dangerouslyIgnoreUnhandledErrors`](/config/dangerouslyignoreunhandlederrors) option instead.
-
-::: tip
-This callback is called on the main thread, it doesn't have access to your test context.
-:::
-
-## Example
-
-```ts
-import type { ParsedStack } from 'vitest'
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    onUnhandledError(error): boolean | void {
-      // Ignore all errors with the name "MySpecialError".
-      if (error.name === 'MySpecialError') {
-        return false
-      }
-    },
-  },
-})
-```

package/vendor/vitest-docs/config/open.md

@@ -1,7 +0,0 @@
-# open <CRoot />
-
-- **Type:** `boolean`
-- **Default:** `!process.env.CI`
-- **CLI:** `--open`, `--open=false`
-
-Open Vitest UI automatically if it's [enabled](/config/ui).

package/vendor/vitest-docs/config/outputfile.md

@@ -1,7 +0,0 @@
-# outputFile <CRoot /> {#outputfile}
-
-- **Type:** `string | Record<string, string>`
-- **CLI:** `--outputFile=<path>`, `--outputFile.json=./path`
-
-Write test results to a file when the `--reporter=json`, `--reporter=html` or `--reporter=junit` option is also specified.
-By providing an object instead of a string you can define individual outputs when using multiple reporters.

package/vendor/vitest-docs/config/passwithnotests.md

@@ -1,7 +0,0 @@
-# passWithNoTests <CRoot />
-
-- **Type:** `boolean`
-- **Default:** `false`
-- **CLI:** `--passWithNoTests`, `--passWithNoTests=false`
-
-Vitest will not fail, if no tests will be found.

package/vendor/vitest-docs/config/pool.md

@@ -1,45 +0,0 @@
-# pool
-
-- **Type:** `'threads' | 'forks' | 'vmThreads' | 'vmForks'`
-- **Default:** `'forks'`
-- **CLI:** `--pool=threads`
-
-Pool used to run tests in.
-
-## threads
-
-Enable multi-threading. When using threads you are unable to use process related APIs such as `process.chdir()`. Some libraries written in native languages, such as `Prisma`, `bcrypt` and `canvas`, have problems when running in multiple threads and run into segfaults. In these cases it is advised to use `forks` pool instead.
-
-## forks
-
-Similar as `threads` pool but uses `child_process` instead of `worker_threads`. Communication between tests and main process is not as fast as with `threads` pool. Process related APIs such as `process.chdir()` are available in `forks` pool.
-
-## vmThreads
-
-Run tests using [VM context](https://nodejs.org/api/vm.html) (inside a sandboxed environment) in a `threads` pool.
-
-This makes tests run faster, but the VM module is unstable when running [ESM code](https://github.com/nodejs/node/issues/37648). Your tests will [leak memory](https://github.com/nodejs/node/issues/33439) - to battle that, consider manually editing [`vmMemoryLimit`](/config/vmmemorylimit) value.
-
-::: warning
-Running code in a sandbox has some advantages (faster tests), but also comes with a number of disadvantages.
-
-- The globals within native modules, such as (`fs`, `path`, etc), differ from the globals present in your test environment. As a result, any error thrown by these native modules will reference a different Error constructor compared to the one used in your code:
-
-```ts
-try {
-  fs.writeFileSync('/does-not-exist')
-}
-catch (err) {
-  console.log(err instanceof Error) // false
-}
-```
-
-- Importing ES modules caches them indefinitely which introduces memory leaks if you have a lot of contexts (test files). There is no API in Node.js that clears that cache.
-- Accessing globals [takes longer](https://github.com/nodejs/node/issues/31658) in a sandbox environment.
-
-Please, be aware of these issues when using this option. Vitest team cannot fix any of the issues on our side.
-:::
-
-## vmForks
-
-Similar as `vmThreads` pool but uses `child_process` instead of `worker_threads`. Communication between tests and the main process is not as fast as with `vmThreads` pool. Process related APIs such as `process.chdir()` are available in `vmForks` pool. Please be aware that this pool has the same pitfalls listed in `vmThreads`.

package/vendor/vitest-docs/config/printconsoletrace.md

@@ -1,6 +0,0 @@
-# printConsoleTrace
-
-- **Type:** `boolean`
-- **Default:** `false`
-
-Always print console traces when calling any `console` method. This is useful for debugging.

package/vendor/vitest-docs/config/projects.md

@@ -1,6 +0,0 @@
-# projects <CRoot />
-
-- **Type:** `TestProjectConfiguration[]`
-- **Default:** `[]`
-
-An array of [projects](/guide/projects).

package/vendor/vitest-docs/config/provide.md

@@ -1,45 +0,0 @@
-# provide
-
-- **Type:** `Partial<ProvidedContext>`
-
-Define values that can be accessed inside your tests using `inject` method.
-
-:::code-group
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    provide: {
-      API_KEY: '123',
-    },
-  },
-})
-```
-```ts [api.test.js]
-import { expect, inject, test } from 'vitest'
-
-test('api key is defined', () => {
-  expect(inject('API_KEY')).toBe('123')
-})
-```
-:::
-
-::: warning
-Properties have to be strings and values need to be [serializable](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#supported_types) because this object will be transferred between different processes.
-:::
-
-::: tip
-If you are using TypeScript, you will need to augment `ProvidedContext` type for type safe access:
-
-```ts [vitest.shims.d.ts]
-declare module 'vitest' {
-  export interface ProvidedContext {
-    API_KEY: string
-  }
-}
-
-// mark this file as a module so augmentation works correctly
-export {}
-```
-:::

package/vendor/vitest-docs/config/reporters.md

@@ -1,69 +0,0 @@
-# reporters <CRoot />
-
-- **Type:**
-
-```ts
-interface UserConfig {
-  reporters?: ConfigReporter | Array<ConfigReporter>
-}
-
-type ConfigReporter = string | Reporter | [string, object?]
-```
-
-- **Default:** [`'default'`](/guide/reporters#default-reporter) (or <code>[['default'](/guide/reporters#default-reporter), ['github-actions'](/guide/reporters#github-actions-reporter)]</code> when `process.env.GITHUB_ACTIONS === 'true'`)
-- **CLI:**
-  - `--reporter=tap` for a single reporter
-  - `--reporter=verbose --reporter=github-actions` for multiple reporters
-
-This option defines a single reporter or a list of reporters available to Vitest during the test run.
-
-Alongside built-in reporters, you can also pass down a custom implementation of a [`Reporter` interface](/api/advanced/reporters), or a path to a module that exports it as a default export (e.g. `'./path/to/reporter.ts'`, `'@scope/reporter'`).
-
-You can configure a reporter by providing a tuple: `[string, object]`, where the string is a reporter name, and the object is the reporter's options.
-
-::: warning
-Note that the [coverage](/guide/coverage) feature uses a different [`coverage.reporter`](/config/coverage#reporter) option instead of this one.
-:::
-
-## Built-in Reporters
-
-- [`default`](/guide/reporters#default-reporter)
-- [`verbose`](/guide/reporters#verbose-reporter)
-- [`tree`](/guide/reporters#tree-reporter)
-- [`dot`](/guide/reporters#dot-reporter)
-- [`junit`](/guide/reporters#junit-reporter)
-- [`json`](/guide/reporters#json-reporter)
-- [`html`](/guide/reporters#html-reporter)
-- [`tap`](/guide/reporters#tap-reporter)
-- [`tap-flat`](/guide/reporters#tap-flat-reporter)
-- [`hanging-process`](/guide/reporters#hanging-process-reporter)
-- [`github-actions`](/guide/reporters#github-actions-reporter)
-- [`minimal`](/guide/reporters#minimal-reporter) (aliased as `agent`)
-- [`blob`](/guide/reporters#blob-reporter)
-
-## Example
-
-::: code-group
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    reporters: [
-      'default',
-      // conditional reporter
-      process.env.CI ? 'github-actions' : {},
-      // custom reporter from npm package
-      // options are passed down as a tuple
-      [
-        'vitest-sonar-reporter',
-        { outputFile: 'sonar-report.xml' }
-      ],
-    ]
-  }
-})
-```
-```bash [CLI]
-vitest --reporter=github-actions --reporter=junit
-```
-:::

package/vendor/vitest-docs/config/resolvesnapshotpath.md

@@ -1,36 +0,0 @@
-# resolveSnapshotPath <CRoot />
-
-- **Type:** `(testPath: string, snapExtension: string, context: { config: SerializedConfig }) => string`
-- **Default:** stores snapshot files in `__snapshots__` directory
-
-Overrides default snapshot path. For example, to store snapshots next to test files:
-
-```ts
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    resolveSnapshotPath: (testPath, snapExtension) => testPath + snapExtension,
-  },
-})
-```
-
-You can also use the `context` parameter to access the project's serialized config. This is useful when you have multiple [projects](/guide/projects) and want to store snapshots in different locations based on the project name:
-
-```ts
-import { basename, dirname, join } from 'node:path'
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    resolveSnapshotPath(testPath, snapExtension, context) {
-      return join(
-        dirname(testPath),
-        '__snapshots__',
-        context.config.name ?? 'default',
-        basename(testPath) + snapExtension,
-      )
-    },
-  },
-})
-```

package/vendor/vitest-docs/config/restoremocks.md

@@ -1,22 +0,0 @@
-# restoreMocks
-
-- **Type:** `boolean`
-- **Default:** `false`
-
-Should Vitest automatically call [`vi.restoreAllMocks()`](/api/vi#vi-restoreallmocks) before each test.
-
-This restores all original implementations on spies created manually with [`vi.spyOn`](/api/vi#vi-spyon).
-
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    restoreMocks: true,
-  },
-})
-```
-
-::: warning
-Be aware that this option may cause problems with async [concurrent tests](/api/test#test-concurrent). If enabled, the completion of one test will restore the implementation for all spies, including those currently being used by other tests in progress.
-:::

package/vendor/vitest-docs/config/retry.md

@@ -1,140 +0,0 @@
-# retry
-
-Retry the test specific number of times if it fails.
-
-- **Type:** `number | { count?: number, delay?: number, condition?: RegExp }`
-- **Default:** `0`
-- **CLI:** `--retry <times>`, `--retry.count <times>`, `--retry.delay <ms>`, `--retry.condition <pattern>`
-
-## Basic Usage
-
-Specify a number to retry failed tests:
-
-```ts
-export default defineConfig({
-  test: {
-    retry: 3,
-  },
-})
-```
-
-## CLI Usage
-
-You can also configure retry options from the command line:
-
-```bash
-# Simple retry count
-vitest --retry 3
-
-# Advanced options using dot notation
-vitest --retry.count 3 --retry.delay 500 --retry.condition 'ECONNREFUSED|timeout'
-```
-
-## Advanced Options <Version>4.1.0</Version> {#advanced-options}
-
-Use an object to configure retry behavior:
-
-```ts
-export default defineConfig({
-  test: {
-    retry: {
-      count: 3, // Number of times to retry
-      delay: 1000, // Delay in milliseconds between retries
-      condition: /ECONNREFUSED|timeout/i, // RegExp to match errors that should trigger retry
-    },
-  },
-})
-```
-
-### count
-
-Number of times to retry a test if it fails. Default is `0`.
-
-```ts
-export default defineConfig({
-  test: {
-    retry: {
-      count: 2,
-    },
-  },
-})
-```
-
-### delay
-
-Delay in milliseconds between retry attempts. Useful for tests that interact with rate-limited APIs or need time to recover. Default is `0`.
-
-```ts
-export default defineConfig({
-  test: {
-    retry: {
-      count: 3,
-      delay: 500, // Wait 500ms between retries
-    },
-  },
-})
-```
-
-### condition
-
-A RegExp pattern or a function to determine if a test should be retried based on the error.
-
-- When a **RegExp**, it's tested against the error message
-- When a **function**, it receives the error and returns a boolean
-
-::: warning
-When defining `condition` as a function, it must be done in a test file directly, not in a configuration file (configurations are serialized for worker threads).
-:::
-
-#### RegExp condition (in config file):
-
-```ts
-export default defineConfig({
-  test: {
-    retry: {
-      count: 2,
-      condition: /ECONNREFUSED|ETIMEDOUT/i, // Retry on connection/timeout errors
-    },
-  },
-})
-```
-
-#### Function condition (in test file):
-
-```ts
-import { describe, test } from 'vitest'
-
-describe('tests with advanced retry condition', () => {
-  test('with function condition', { retry: { count: 2, condition: error => error.message.includes('Network') } }, () => {
-    // test code
-  })
-})
-```
-
-## Test File Override
-
-You can also define retry options per test or suite in test files:
-
-```ts
-import { describe, test } from 'vitest'
-
-describe('flaky tests', {
-  retry: {
-    count: 2,
-    delay: 100,
-  },
-}, () => {
-  test('network request', () => {
-    // test code
-  })
-})
-
-test('another test', {
-  retry: {
-    count: 3,
-    condition: error => error.message.includes('timeout'),
-  },
-}, () => {
-  // test code
-})
-```

package/vendor/vitest-docs/config/root.md

@@ -1,6 +0,0 @@
-# root
-
-- **Type:** `string`
-- **CLI:** `-r <path>`, `--root=<path>`
-
-Project root

package/vendor/vitest-docs/config/runner.md

@@ -1,6 +0,0 @@
-# runner
-
-- **Type:** `VitestRunnerConstructor`
-- **Default:** `node`, when running tests, or `benchmark`, when running benchmarks
-
-Path to a custom test runner. This is an advanced feature and should be used with custom library runners. You can read more about it in [the documentation](/api/advanced/runner).

package/vendor/vitest-docs/config/sequence.md

@@ -1,158 +0,0 @@
-# sequence
-
-- **Type:** `{ sequencer?, shuffle?, seed?, hooks?, setupFiles?, groupOrder }`
-
-Options for how tests should be sorted.
-
-You can provide sequence options to CLI with dot notation:
-
-```sh
-npx vitest --sequence.shuffle --sequence.seed=1000
-```
-
-## sequence.sequencer <CRoot />
-
-- **Type:** `TestSequencerConstructor`
-- **Default:** `BaseSequencer`
-
-A custom class that defines methods for sharding and sorting. You can extend `BaseSequencer` from `vitest/node`, if you only need to redefine one of the `sort` and `shard` methods, but both should exist.
-
-Sharding is happening before sorting, and only if `--shard` option is provided.
-
-If [`sequence.groupOrder`](#sequence-grouporder) is specified, the sequencer will be called once for each group and pool.
-
-## sequence.groupOrder
-
-- **Type:** `number`
-- **Default:** `0`
-
-Controls the order in which this project runs its tests when using multiple [projects](/guide/projects).
-
-- Projects with the same group order number will run together, and groups are run from lowest to highest.
-- If you don't set this option, all projects run in parallel.
-- If several projects use the same group order, they will run at the same time.
-
-This setting only affects the order in which projects run, not the order of tests within a project.
-To control test isolation or the order of tests inside a project, use the [`isolate`](/config/isolate) and [`sequence.sequencer`](/config/sequence#sequence-sequencer) options.
-
-::: details Example
-Consider this example:
-
-```ts
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    projects: [
-      {
-        test: {
-          name: 'slow',
-          sequence: {
-            groupOrder: 0,
-          },
-        },
-      },
-      {
-        test: {
-          name: 'fast',
-          sequence: {
-            groupOrder: 0,
-          },
-        },
-      },
-      {
-        test: {
-          name: 'flaky',
-          sequence: {
-            groupOrder: 1,
-          },
-        },
-      },
-    ],
-  },
-})
-```
-
-Tests in these projects will run in this order:
-
-```
- 0. slow  |
-          |> running together
- 0. fast  |
-
- 1. flaky |> runs after slow and fast alone
-```
-:::
-
-## sequence.shuffle
-
-- **Type:** `boolean | { files?, tests? }`
-- **Default:** `false`
-- **CLI:** `--sequence.shuffle`, `--sequence.shuffle=false`
-
-If you want files and tests to run randomly, you can enable it with this option, or CLI argument [`--sequence.shuffle`](/guide/cli).
-
-Vitest usually uses cache to sort tests, so long-running tests start earlier, which makes tests run faster. If your files and tests run in random order, you will lose this performance improvement, but it may be useful to track tests that accidentally depend on another test run previously.
-
-### sequence.shuffle.files {#sequence-shuffle-files}
-
-- **Type:** `boolean`
-- **Default:** `false`
-- **CLI:** `--sequence.shuffle.files`, `--sequence.shuffle.files=false`
-
-Whether to randomize files, be aware that long running tests will not start earlier if you enable this option.
-
-### sequence.shuffle.tests {#sequence-shuffle-tests}
-
-- **Type:** `boolean`
-- **Default:** `false`
-- **CLI:** `--sequence.shuffle.tests`, `--sequence.shuffle.tests=false`
-
-Whether to randomize tests.
-
-## sequence.concurrent {#sequence-concurrent}
-
-- **Type:** `boolean`
-- **Default:** `false`
-- **CLI:** `--sequence.concurrent`, `--sequence.concurrent=false`
-
-If you want tests to run in parallel, you can enable it with this option, or CLI argument [`--sequence.concurrent`](/guide/cli).
-
-::: warning
-When you run tests with `sequence.concurrent` and `expect.requireAssertions` set to `true`, you should use [local expect](/guide/test-context.html#expect) instead of the global one. Otherwise, this may cause false negatives in [some situations (#8469)](https://github.com/vitest-dev/vitest/issues/8469).
-:::
-
-## sequence.seed <CRoot />
-
-- **Type:** `number`
-- **Default:** `Date.now()`
-- **CLI:** `--sequence.seed=1000`
-
-Sets the randomization seed, if tests are running in random order.
-
-## sequence.hooks
-
-- **Type:** `'stack' | 'list' | 'parallel'`
-- **Default:** `'stack'`
-- **CLI:** `--sequence.hooks=<value>`
-
-Changes the order in which hooks are executed.
-
-- `stack` will order "after" hooks in reverse order, "before" hooks will run in the order they were defined
-- `list` will order all hooks in the order they are defined
-- `parallel` runs hooks in a single group in parallel (hooks in parent suites still run before the current suite's hooks). The actual number of simultaneously running hooks is limited by [`maxConcurrency`](/config/maxconcurrency).
-
-::: tip
-This option doesn't affect [`onTestFinished`](/api/hooks#ontestfinished). It is always called in reverse order.
-:::
-
-## sequence.setupFiles {#sequence-setupfiles}
-
-- **Type:** `'list' | 'parallel'`
-- **Default:** `'parallel'`
-- **CLI:** `--sequence.setupFiles=<value>`
-
-Changes the order in which setup files are executed.
-
-- `list` will run setup files in the order they are defined
-- `parallel` will run setup files in parallel

package/vendor/vitest-docs/config/server.md

@@ -1,68 +0,0 @@
-# server <Deprecated />
-
-Before Vitest 4, this option was used to define the configuration for the `vite-node` server.
-
-At the moment, this option allows you to configure the inlining and externalization mechanisms, along with the module runner debugging configuration.
-
-::: warning
-These options should be used only as the last resort to improve performance by externalizing auto-inlined dependencies or to fix issues by inlining invalid external dependencies.
-
-Normally, Vitest should do this automatically.
-:::
-
-## server.deps
-
-### server.deps.external
-
-- **Type:** `(string | RegExp)[]`
-- **Default:** files inside [`moduleDirectories`](/config/deps#moduledirectories)
-
-Specifies modules that should not be transformed by Vite and should instead be processed directly by the engine. These modules are imported via native dynamic `import` and bypass both transformation and resolution phases.
-
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    server: {
-      deps: {
-        external: ['react'],
-      },
-    },
-  },
-})
-```
-
-External modules and their dependencies are not present in the module graph and will not trigger test restarts when they change.
-
-Typically, packages under `node_modules` are externalized.
-
-::: tip
-If a string is provided, it is first normalized by prefixing the `/node_modules/` or other [`moduleDirectories`](/config/deps#moduledirectories) segments (for example, `'react'` becomes `/node_modules/react/`), and the resulting string is then matched against the full file path. For example, package `@company/some-name` located inside `packages/some-name` should be specified as `some-name`, and `packages` should be included in `deps.moduleDirectories`.
-
-If a `RegExp` is provided, it is matched against the full file path.
-:::
-
-### server.deps.inline
-
-- **Type:** `(string | RegExp)[] | true`
-- **Default:** everything that is not externalized
-
-Specifies modules that should be transformed and resolved by Vite. These modules are run by Vite's [module runner](https://vite.dev/guide/api-environment-runtimes#modulerunner).
-
-Typically, your source files are inlined.
-
-::: tip
-If a string is provided, it is first normalized by prefixing the `/node_modules/` or other [`moduleDirectories`](/config/deps#moduledirectories) segments (for example, `'react'` becomes `/node_modules/react/`), and the resulting string is then matched against the full file path. For example, package `@company/some-name` located inside `packages/some-name` should be specified as `some-name`, and `packages` should be included in `deps.moduleDirectories`.
-
-If a `RegExp` is provided, it is matched against the full file path.
-:::
-
-### server.deps.fallbackCJS
-
-- **Type:** `boolean`
-- **Default:** `false`
-
-When enabled, Vitest will try to guess a CommonJS build for an ESM entry by checking a few common CJS/UMD file name and folder patterns (like `.mjs`, `.umd.js`, `.cjs.js`, `umd/`, `cjs/`, `lib/`).
-
-This is a best-effort heuristic to work around confusing or incorrect ESM/CJS packaging and may not work for all dependencies.