@vitest-agent/mcp 1.1.0 → 1.3.0

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

@@ -1,72 +0,0 @@
-# globalSetup
-
-- **Type:** `string | string[]`
-
-Path to global setup files relative to project [root](/config/root).
-
-A global setup file can either export named functions `setup` and `teardown` or a `default` function that returns a teardown function:
-
-::: code-group
-```js [exports]
-export function setup(project) {
-  console.log('setup')
-}
-
-export function teardown() {
-  console.log('teardown')
-}
-```
-```js [default]
-export default function setup(project) {
-  console.log('setup')
-
-  return function teardown() {
-    console.log('teardown')
-  }
-}
-```
-:::
-
-Note that the `setup` method and a `default` function receive a [test project](/api/advanced/test-project) as the first argument. The global setup is called before the test workers are created and only if there is at least one test queued, and teardown is called after all test files have finished running. In [watch mode](/config/watch), the teardown is called before the process is exited instead. If you need to reconfigure your setup before the test rerun, you can use [`onTestsRerun`](#handling-test-reruns) hook instead.
-
-Multiple global setup files are possible. `setup` and `teardown` are executed sequentially with teardown in reverse order.
-
-::: danger
-Beware that the global setup is running in a different global scope before test workers are even created, so your tests don't have access to global variables defined here. However, you can pass down serializable data to tests via [`provide`](/config/provide) method and read them in your tests via `inject` imported from `vitest`:
-
-:::code-group
-```ts [example.test.ts]
-import { inject } from 'vitest'
-
-inject('wsPort') === 3000
-```
-```ts [globalSetup.ts]
-import type { TestProject } from 'vitest/node'
-
-export default function setup(project: TestProject) {
-  project.provide('wsPort', 3000)
-}
-
-declare module 'vitest' {
-  export interface ProvidedContext {
-    wsPort: number
-  }
-}
-```
-
-If you need to execute code in the same process as tests, use [`setupFiles`](/config/setupfiles) instead, but note that it runs before every test file.
-:::
-
-## Handling Test Reruns
-
-You can define a custom callback function to be called when Vitest reruns tests. The test runner will wait for it to complete before executing tests. Note that you cannot destruct the `project` like `{ onTestsRerun }` because it relies on the context.
-
-```ts [globalSetup.ts]
-import type { TestProject } from 'vitest/node'
-
-export default function setup(project: TestProject) {
-  project.onTestsRerun(async () => {
-    await restartDb()
-  })
-}
-```

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

@@ -1,7 +0,0 @@
-# hideSkippedTests
-
-- **Type:** `boolean`
-- **CLI:** `--hideSkippedTests`, `--hide-skipped-tests`
-- **Default:** `false`
-
-Hide logs for skipped tests

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

@@ -1,7 +0,0 @@
-# hookTimeout
-
-- **Type:** `number`
-- **Default:** `10_000` in Node.js, `30_000` if `browser.enabled` is `true`
-- **CLI:** `--hook-timeout=10000`, `--hookTimeout=10000`
-
-Default timeout of a hook in milliseconds. Use `0` to disable timeout completely.

package/vendor/vitest-docs/config/include-source.md

@@ -1,115 +0,0 @@
-# includeSource
-
-- **Type:** `string[]`
-- **Default:** `[]`
-
-A list of [glob patterns](https://superchupu.dev/tinyglobby/comparison) that match your [in-source test files](/guide/in-source). These patterns are resolved relative to the [`root`](/config/root) ([`process.cwd()`](https://nodejs.org/api/process.html#processcwd) by default).
-
-When defined, Vitest will run all matched files that have `import.meta.vitest` inside.
-
-::: warning
-Vitest performs a simple text-based inclusion check on source files. If a file contains `import.meta.vitest`, even in a comment, it will be matched as an in-source test file.
-:::
-
-Vitest uses the [`tinyglobby`](https://npmx.dev/package/tinyglobby) package to resolve the globs.
-
-## Example
-
-```js
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    includeSource: ['src/**/*.{js,ts}'],
-  },
-})
-```
-
-Then you can write tests inside your source files:
-
-```ts [src/index.ts]
-export function add(...args: number[]) {
-  return args.reduce((a, b) => a + b, 0)
-}
-
-// #region in-source test suites
-if (import.meta.vitest) {
-  const { it, expect } = import.meta.vitest
-  it('add', () => {
-    expect(add()).toBe(0)
-    expect(add(1)).toBe(1)
-    expect(add(1, 2, 3)).toBe(6)
-  })
-}
-// #endregion
-```
-
-For your production build, you need to replace the `import.meta.vitest` with `undefined`, letting the bundler do the dead code elimination.
-
-::: code-group
-```js [vite.config.ts]
-import { defineConfig } from 'vite'
-
-export default defineConfig({
-  define: { // [!code ++]
-    'import.meta.vitest': 'undefined', // [!code ++]
-  }, // [!code ++]
-})
-```
-```js [rolldown.config.js]
-import { defineConfig } from 'rolldown/config'
-
-export default defineConfig({
-  transform: {
-    define: { // [!code ++]
-      'import.meta.vitest': 'undefined', // [!code ++]
-    }, // [!code ++]
-  },
-})
-```
-```js [rollup.config.js]
-import replace from '@rollup/plugin-replace' // [!code ++]
-
-export default {
-  plugins: [
-    replace({ // [!code ++]
-      'import.meta.vitest': 'undefined', // [!code ++]
-    }) // [!code ++]
-  ],
-  // other options
-}
-```
-```js [build.config.js]
-import { defineBuildConfig } from 'unbuild'
-
-export default defineBuildConfig({
-  replace: { // [!code ++]
-    'import.meta.vitest': 'undefined', // [!code ++]
-  }, // [!code ++]
-  // other options
-})
-```
-```js [webpack.config.js]
-const webpack = require('webpack')
-
-module.exports = {
-  plugins: [
-    new webpack.DefinePlugin({ // [!code ++]
-      'import.meta.vitest': 'undefined', // [!code ++]
-    })// [!code ++]
-  ],
-}
-```
-:::
-
-::: tip
-To get TypeScript support for `import.meta.vitest`, add `vitest/importMeta` to your `tsconfig.json`:
-
-```json [tsconfig.json]
-{
-  "compilerOptions": {
-    "types": ["vitest/importMeta"]
-  }
-}
-```
-:::

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

@@ -1,71 +0,0 @@
-# include
-
-- **Type:** `string[]`
-- **Default:** `['**/*.{test,spec}.?(c|m)[jt]s?(x)']`
-- **CLI:** `vitest [...include]`, `vitest **/*.test.js`
-
-A list of [glob patterns](https://superchupu.dev/tinyglobby/comparison) that match your test files. These patterns are resolved relative to the [`root`](/config/root) ([`process.cwd()`](https://nodejs.org/api/process.html#processcwd) by default).
-
-Vitest uses the [`tinyglobby`](https://npmx.dev/package/tinyglobby) package to resolve the globs.
-
-::: tip NOTE
-When using coverage, Vitest automatically adds test files `include` patterns to coverage's default `exclude` patterns. See [`coverage.exclude`](/config/coverage#exclude).
-:::
-
-## Example
-
-```js
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    include: [
-      './test',
-      './**/*.{test,spec}.tsx?',
-    ],
-  },
-})
-```
-
-Vitest provides reasonable defaults, so normally you wouldn't override them. A good example of defining `include` is for [test projects](/guide/projects):
-
-```js{8,12} [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    projects: [
-      {
-        test: {
-          name: 'unit',
-          include: ['./test/unit/*.test.js'],
-        },
-      },
-      {
-        test: {
-          name: 'e2e',
-          include: ['./test/e2e/*.test.js'],
-        },
-      },
-    ],
-  },
-})
-```
-
-::: warning
-This option will override Vitest defaults. If you just want to extend them, use `configDefaults` from `vitest/config`:
-
-```js{6}
-import { configDefaults, defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    include: [
-      ...configDefaults.include,
-      './test',
-      './**/*.{test,spec}.tsx?',
-    ],
-  },
-})
-```
-:::

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

@@ -1,17 +0,0 @@
-# includeTaskLocation
-
-- **Type:** `boolean`
-- **Default:** `false`
-
-Should `location` property be included when Vitest API receives tasks in [reporters](/config/reporters). If you have a lot of tests, this might cause a small performance regression.
-
-The `location` property has `column` and `line` values that correspond to the `test` or `describe` position in the original file.
-
-This option will be auto-enabled if you don't disable it explicitly, and you are running Vitest with:
-- [Vitest UI](/guide/ui)
-- or using the [Browser Mode](/guide/browser/) without [headless](/guide/browser/#headless) mode
-- or using [HTML Reporter](/guide/reporters#html-reporter)
-
-::: tip
-This option has no effect if you do not use custom code that relies on this.
-:::

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

@@ -1,85 +0,0 @@
-# Configuring Vitest
-
-If you are using Vite and have a `vite.config` file, Vitest will read it to match with the plugins and setup as your Vite app. If you want to have a different configuration for testing or your main app doesn't rely on Vite specifically, you could either:
-
-- Create `vitest.config.ts`, which will have the higher priority and will **override** the configuration from `vite.config.ts` (Vitest supports all conventional JS and TS extensions, but doesn't support `json`) - it means all options in your `vite.config` will be **ignored**
-- Pass `--config` option to CLI, e.g. `vitest --config ./path/to/vitest.config.ts`
-- Use `process.env.VITEST` or `mode` property on `defineConfig` (will be set to `test`/`benchmark` if not overridden with `--mode`) to conditionally apply different configuration in `vite.config.ts`. Note that like any other environment variable, `VITEST` is also exposed on `import.meta.env` in your tests
-
-To configure `vitest` itself, add `test` property in your Vite config. You'll also need to add a reference to Vitest types using a [triple slash command](https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-) at the top of your config file, if you are importing `defineConfig` from `vite` itself.
-
-If you are not using `vite`, add `defineConfig` imported from `vitest/config` to your config file:
-
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    // ... Specify options here.
-  },
-})
-```
-
-If you have a `vite` config already, you can add `/// <reference types="vitest/config" />` to include the `test` types:
-
-```js [vite.config.js]
-/// <reference types="vitest/config" />
-import { defineConfig } from 'vite'
-
-export default defineConfig({
-  test: {
-    // ... Specify options here.
-  },
-})
-```
-
-You can retrieve Vitest's default options to expand them if needed:
-
-```js [vitest.config.js]
-import { configDefaults, defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    exclude: [...configDefaults.exclude, 'packages/template/*'],
-  },
-})
-```
-
-When using a separate `vitest.config.js`, you can also extend Vite's options from another config file if needed:
-
-```js [vitest.config.js]
-import { defineConfig, mergeConfig } from 'vitest/config'
-import viteConfig from './vite.config'
-
-export default mergeConfig(viteConfig, defineConfig({
-  test: {
-    exclude: ['packages/template/*'],
-  },
-}))
-```
-
-If your Vite config is defined as a function, you can define the config like this:
-
-```js [vitest.config.js]
-import { defineConfig, mergeConfig } from 'vitest/config'
-import viteConfig from './vite.config'
-
-export default defineConfig(configEnv => mergeConfig(
-  viteConfig(configEnv),
-  defineConfig({
-    test: {
-      exclude: ['packages/template/*'],
-    },
-  })
-))
-```
-
-Since Vitest uses Vite config, you can also use any configuration option from [Vite](https://vitejs.dev/config/). For example, `define` to define global variables, or `resolve.alias` to define aliases - these options should be defined on the top level, _not_ within a `test` property.
-
-## Automatic Dependency Installation
-
-Vitest will prompt you to install certain dependencies if they are not already installed. You can disable this behavior by setting the `VITEST_SKIP_INSTALL_CHECKS=1` environment variable.
-
-## Config Options
-
-Configuration options that are not supported inside a [project](/guide/projects) config have <CRoot /> icon next to them. This means they can only be set in the root Vitest config.

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

@@ -1,13 +0,0 @@
-# isolate
-
-- **Type:** `boolean`
-- **Default:** `true`
-- **CLI:** `--no-isolate`, `--isolate=false`
-
-Run tests in an isolated environment. This option has no effect on `vmThreads` and `vmForks` pools.
-
-Disabling this option might [improve performance](/guide/improving-performance) if your code doesn't rely on side effects (which is usually true for projects with `node` environment).
-
-::: tip
-You can disable isolation for specific test files by using Vitest workspaces and disabling isolation per project.
-:::

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

@@ -1,7 +0,0 @@
-# logHeapUsage
-
-- **Type:** `boolean`
-- **Default:** `false`
-- **CLI:** `--logHeapUsage`, `--logHeapUsage=false`
-
-Show heap usage after each test. Useful for debugging memory leaks.

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

@@ -1,9 +0,0 @@
-# maxConcurrency
-
-- **Type:** `number`
-- **Default:** `5`
-- **CLI:** `--max-concurrency=10`, `--maxConcurrency=10`
-
-The maximum number of tests and hooks that can run at the same time when using `test.concurrent` or `describe.concurrent`.
-
-The hook execution order within a single group is also controlled by [`sequence.hooks`](/config/sequence#sequence-hooks). With `sequence.hooks: 'parallel'`, the execution is bounded by the same limit of [`maxConcurrency`](/config/maxconcurrency).

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

@@ -1,49 +0,0 @@
-# maxWorkers
-
-- **Type:** `number | string`
-- **Default:**
-  - if [`watch`](/config/watch) is disabled, uses all available parallelism
-  - if [`watch`](/config/watch) is enabled, uses half of all available parallelism
-
-Defines the maximum concurrency for test workers. Accepts either a number or a percentage string.
-
-- Number: spawns up to the specified number of workers.
-- Percentage string (e.g., "50%"): computes the worker count as the given percentage of the machine’s available parallelism.
-
-## Example
-
-### Number
-
-::: code-group
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    maxWorkers: 4,
-  },
-})
-```
-```bash [CLI]
-vitest --maxWorkers=4
-```
-:::
-
-### Percent
-
-::: code-group
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    maxWorkers: '50%',
-  },
-})
-```
-```bash [CLI]
-vitest --maxWorkers=50%
-```
-:::
-
-Vitest uses [`os.availableParallelism`](https://nodejs.org/api/os.html#osavailableparallelism) to know the maximum amount of parallelism available.

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

@@ -1,22 +0,0 @@
-# mockReset
-
-- **Type:** `boolean`
-- **Default:** `false`
-
-Should Vitest automatically call [`vi.resetAllMocks()`](/api/vi#vi-resetallmocks) before each test.
-
-This will clear mock history and reset each implementation.
-
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    mockReset: 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 clear the mock history and implementation for all mocks, including those currently being used by other tests in progress.
-:::

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

@@ -1,7 +0,0 @@
-# mode
-
-- **Type:** `string`
-- **CLI:** `--mode=staging`
-- **Default:** `'test'`
-
-Overrides Vite mode.

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

@@ -1,111 +0,0 @@
-# name
-
-- **Type:**
-
-```ts
-interface UserConfig {
-  name?: string | { label: string; color?: LabelColor }
-}
-```
-
-Assign a custom name to the test project or Vitest process. The name will be visible in the CLI and UI, and available in the Node.js API via [`project.name`](/api/advanced/test-project#name).
-
-The color used by the CLI and UI can be changed by providing an object with a `color` property.
-
-## Colors
-
-The displayed colors depend on your terminal’s color scheme. In the UI, colors match their CSS equivalents.
-
-- black
-- red
-- green
-- yellow
-- blue
-- magenta
-- cyan
-- white
-
-## Example
-
-::: code-group
-```js [string]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    name: 'unit',
-  },
-})
-```
-```js [object]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    name: {
-      label: 'unit',
-      color: 'blue',
-    },
-  },
-})
-```
-:::
-
-This property is mostly useful if you have several projects as it helps distinguish them in your terminal:
-
-```js{7,11} [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    projects: [
-      {
-        name: 'unit',
-        include: ['./test/*.unit.test.js'],
-      },
-      {
-        name: 'e2e',
-        include: ['./test/*.e2e.test.js'],
-      },
-    ],
-  },
-})
-```
-
-::: tip
-Vitest automatically assigns a name when none is provided. Resolution order:
-
-- If the project is specified by a config file or directory, Vitest uses the package.json's `name` field.
-- If there is no `package.json`, Vitest falls back to the project folder's basename.
-- If the project is defined inline in the `projects` array (an object), Vitest assigns a numeric name equal to that project's array index (0-based).
-:::
-
-::: warning
-Note that projects cannot have the same name. Vitest will throw an error during the config resolution.
-:::
-
-You can also assign different names to different browser [instances](/config/browser/instances):
-
-```js{10,11} [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-import { playwright } from '@vitest/browser-playwright'
-
-export default defineConfig({
-  test: {
-    browser: {
-      enabled: true,
-      provider: playwright(),
-      instances: [
-        { browser: 'chromium', name: 'Chrome' },
-        { browser: 'firefox', name: 'Firefox' },
-      ],
-    },
-  },
-})
-```
-
-::: tip
-Browser instances inherit their parent project's name with the browser name appended in parentheses. For example, a project named `browser` with a chromium instance will be shown as `browser (chromium)`.
-
-If the parent project has no name, or instances are defined at the root level (not inside a named project), the instance name defaults to the browser value (e.g. `chromium`). To override this behavior, set an explicit `name` on the instance.
-:::

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

@@ -1,25 +0,0 @@
-# onConsoleLog <CRoot />
-
-```ts
-function onConsoleLog(
-  log: string,
-  type: 'stdout' | 'stderr',
-  entity: TestModule | TestSuite | TestCase | undefined,
-): boolean | void
-```
-
-Custom handler for `console` methods in tests. If you return `false`, Vitest will not print the log to the console. Note that Vitest ignores all other falsy values.
-
-Can be useful for filtering out logs from third-party libraries.
-
-```ts
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    onConsoleLog(log: string, type: 'stdout' | 'stderr'): boolean | void {
-      return !(log === 'message from third party library' && type === 'stdout')
-    },
-  },
-})
-```

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

@@ -1,32 +0,0 @@
-# onStackTrace <CRoot />
-
-- **Type:** `(error: Error, frame: ParsedStack) => boolean | void`
-
-Apply a filtering function to each frame of each stack trace when handling errors. This does not apply to stack traces printed by [`printConsoleTrace`](/config/printconsoletrace#printconsoletrace). The first argument, `error`, is a `TestError`.
-
-Can be useful for filtering out stack trace frames from third-party libraries.
-
-::: tip
-The stack trace's total size is also typically limited by V8's [`Error.stackTraceLimit`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stackTraceLimit) number. You could set this to a high value in your test setup function to prevent stacks from being truncated.
-:::
-
-```ts
-import type { ParsedStack, TestError } from 'vitest'
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    onStackTrace(error: TestError, { file }: ParsedStack): boolean | void {
-      // If we've encountered a ReferenceError, show the whole stack.
-      if (error.name === 'ReferenceError') {
-        return
-      }
-
-      // Reject all frames from third party libraries.
-      if (file.includes('node_modules')) {
-        return false
-      }
-    },
-  },
-})
-```