@vitest-agent/mcp 1.1.0 → 1.3.0

package/vendor/vitest-docs/guide/filtering.md

@@ -1,175 +0,0 @@
-# Test Filtering
-
-As your test suite grows, running every test on every change becomes slow and distracting. If you're fixing a bug in a single module, you don't need to wait for hundreds of unrelated tests to finish. Test filtering lets you narrow down which tests run so you can stay focused on the code you're actively working on.
-
-Vitest offers several ways to filter tests: from the command line, inside your test files, and through tags. Each approach is useful in different situations.
-
-::: tip Performance Note
-Filters like `-t`, `--tags-filter`, `.only`, and `.skip` are applied *per test file* — Vitest still has to run each test file to discover which tests match. In a large project, this overhead adds up even if only a few tests actually execute.
-
-To avoid this, always pass a file path alongside your filter so Vitest only loads the files you care about:
-
-```bash
-vitest utils.test.ts -t "handles empty input"
-```
-
-Alternatively, you can use the [`--experimental.preParse`](/config/experimental#experimental-preparse) flag, which parses test files to discover test names without fully executing them:
-
-```bash
-vitest --experimental.preParse -t "handles empty input"
-```
-:::
-
-## Filtering by File Name
-
-The simplest way to run a subset of tests is to pass a filename pattern as a CLI argument. Vitest will only run test files whose path contains the given string:
-
-```bash
-vitest basic
-```
-
-This matches any test file with `basic` in its path:
-
-```
-basic.test.ts
-basic-foo.test.ts
-basic/foo.test.ts
-```
-
-This is useful when you know which file you need to work on and want to skip everything else.
-
-## Filtering by Test Name
-
-Sometimes the test you care about is buried in a file with many other tests. The `-t` (or `--testNamePattern`) option filters by the test's name rather than the filename. It accepts a regex pattern and matches against the full test name, which includes any `describe` block names:
-
-```bash
-vitest -t "handles empty input"
-```
-
-You can combine this with a file filter to narrow things down further:
-
-```bash
-vitest utils -t "handles empty input"
-```
-
-This runs only tests whose name matches `"handles empty input"` inside files matching `utils`.
-
-## Filtering by Line Number
-
-When you're looking at a specific test in your editor, you often just want to run *that one test*. You can point directly to a line number:
-
-```bash
-vitest basic/foo.test.ts:10
-```
-
-Vitest will run the test that contains line 10. This requires the full filename (relative or absolute):
-
-```bash
-vitest basic/foo.test.ts:10 # ✅
-vitest ./basic/foo.test.ts:10 # ✅
-vitest /users/project/basic/foo.test.ts:10 # ✅
-vitest foo:10 # ❌ partial name won't work
-vitest ./basic/foo:10 # ❌ missing file extension
-```
-
-To run multiple specific tests, separate them with spaces:
-
-```bash
-vitest basic/foo.test.ts:10 basic/foo.test.ts:25 # ✅
-vitest basic/foo.test.ts:10-25 # ❌ ranges are not supported
-```
-
-## Filtering by Tags
-
-For larger projects, you may want to categorize tests and run them by category. [Tags](/guide/test-tags) let you label tests and then filter by those labels from the CLI:
-
-```ts
-test('renders a form', { tags: ['frontend'] }, () => {
-  // ...
-})
-
-test('calls an external API', { tags: ['backend'] }, () => {
-  // ...
-})
-```
-
-```bash
-vitest --tags-filter=frontend
-```
-
-This is particularly helpful in CI pipelines where you might want to run frontend and backend tests in separate jobs, or skip slow integration tests during quick checks.
-
-## Focusing on Specific Tests with `.only`
-
-When you're debugging a failing test, you want to run just that test without modifying CLI arguments every time. Adding `.only` to a test or suite tells Vitest to skip everything else in the file:
-
-```ts
-import { describe, expect, it } from 'vitest'
-
-describe.only('suite', () => {
-  it('test', () => {
-    // This runs because the suite is marked with .only
-    expect(Math.sqrt(4)).toBe(2)
-  })
-})
-
-describe('another suite', () => {
-  it('skipped test', () => {
-    // This does not run
-    expect(Math.sqrt(4)).toBe(2)
-  })
-
-  it.only('focused test', () => {
-    // This also runs because it is marked with .only
-    expect(Math.sqrt(4)).toBe(2)
-  })
-})
-```
-
-You can use `.only` on both `describe` blocks and individual tests. When any test or suite in a file is marked with `.only`, all unmarked tests in that file are skipped.
-
-::: warning
-Remember to remove `.only` before committing. By default, Vitest will fail the entire test run if it encounters `.only` in CI (when `process.env.CI` is set), preventing you from accidentally skipping tests in your pipeline. This behavior is controlled by the [`allowOnly`](/config/allowonly) option.
-
-To catch `.only` even earlier, the [`no-focused-tests`](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/no-focused-tests.md) ESLint rule (also available in [oxlint](https://oxc.rs/docs/guide/usage/linter/rules/jest/no-focused-tests.html)) can flag it in your editor before you commit.
-:::
-
-## Skipping Tests with `.skip`
-
-The opposite of `.only` is `.skip`. Use it to temporarily disable a test or suite without deleting it. Skipped tests still show up in the report so you don't forget about them:
-
-```ts
-import { describe, expect, it } from 'vitest'
-
-describe.skip('skipped suite', () => {
-  it('test', () => {
-    // This entire suite is skipped
-    expect(Math.sqrt(4)).toBe(2)
-  })
-})
-
-describe('suite', () => {
-  it.skip('skipped test', () => {
-    // Just this one test is skipped
-    expect(Math.sqrt(4)).toBe(2)
-  })
-})
-```
-
-This is useful when a test is flaky or depends on an external service that's temporarily down. It lets you keep the test in place as a reminder while unblocking the rest of the suite.
-
-## Placeholder Tests with `.todo`
-
-When planning new features, you might know what tests you'll need before you write the actual implementation. `.todo` marks a test as planned but not yet written. It shows up in the report as a reminder:
-
-```ts
-import { describe, it } from 'vitest'
-
-describe.todo('unimplemented suite')
-
-describe('suite', () => {
-  it.todo('unimplemented test')
-})
-```
-
-Unlike `.skip`, a `.todo` test has no test body. It's purely a placeholder for future work.

package/vendor/vitest-docs/guide/ide.md

@@ -1,43 +0,0 @@
-<script setup>
-import { useData } from 'vitepress'
-const { isDark } = useData()
-</script>
-
-# IDE Integrations
-
-## VS Code <Badge>Official</Badge> {#vs-code}
-
-<p text-center>
-<img :src="`https://raw.githubusercontent.com/vitest-dev/vscode/main/img/cover-${isDark ? 'light' : 'dark' }.png`" w-60 alt="vscode logo">
-</p>
-
-[GitHub](https://github.com/vitest-dev/vscode) | [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=vitest.explorer)
-
-![A gif of vscode extension in vscode](https://i.ibb.co/bJCbCf2/202203292020.gif)
-
-## JetBrains IDE
-
-WebStorm, PhpStorm, IntelliJ IDEA Ultimate, and other JetBrains IDEs come with built-in support for Vitest.
-
-<p text-center>
-<img :src="`/ide/vitest-jb-${isDark ? 'light' : 'dark'}.png`" w-60 alt="webstorm logo">
-</p>
-
-[WebStorm Help](https://www.jetbrains.com/help/webstorm/vitest.html) | [IntelliJ IDEA Ultimate Help](https://www.jetbrains.com/help/idea/vitest.html) | [PhpStorm Help](https://www.jetbrains.com/help/phpstorm/vitest.html)
-
-![Vitest WebStorm Demo](https://raw.githubusercontent.com/kricact/WS-info/main/gifs/vitest-run-all.gif)
-
-## Wallaby.js <Badge>Paid (free for OSS)</Badge>
-
-Created by [The Wallaby Team](https://wallabyjs.com)
-
-[Wallaby.js](https://wallabyjs.com) runs your Vitest tests immediately as you type, highlighting results in your IDE right next to your code.
-
-<p text-left>
-  <img :src="`/ide/vitest-wallaby-${isDark ? 'light' : 'dark'}.png`" alt="Vitest + Wallaby logos" w-142>
-</p>
-
-[VS Code](https://marketplace.visualstudio.com/items?itemName=WallabyJs.wallaby-vscode) | [JetBrains](https://plugins.jetbrains.com/plugin/15742-wallaby) |
-[Visual Studio](https://marketplace.visualstudio.com/items?itemName=vs-publisher-999439.WallabyjsforVisualStudio2022) | [Sublime Text](https://packagecontrol.io/packages/Wallaby)
-
-![Wallaby VS Code Demo](https://wallabyjs.com/assets/img/vitest_demo.gif)

package/vendor/vitest-docs/guide/improving-performance.md

@@ -1,245 +0,0 @@
-# Improving Performance
-
-## Test Isolation
-
-By default Vitest runs every test file in an isolated environment based on the [pool](/config/pool):
-
-- `threads` pool runs every test file in a separate [`Worker`](https://nodejs.org/api/worker_threads.html#class-worker)
-- `forks` pool runs every test file in a separate [forked child process](https://nodejs.org/api/child_process.html#child_processforkmodulepath-args-options)
-- `vmThreads` pool runs every test file in a separate [VM context](https://nodejs.org/api/vm.html#vmcreatecontextcontextobject-options), but it uses workers for parallelism
-
-This greatly increases test times, which might not be desirable for projects that don't rely on side effects and properly cleanup their state (which is usually true for projects with `node` environment). In this case disabling isolation will improve the speed of your tests. To do that, you can provide `--no-isolate` flag to the CLI or set [`test.isolate`](/config/isolate) property in the config to `false`.
-
-::: code-group
-```bash [CLI]
-vitest --no-isolate
-```
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    isolate: false,
-  },
-})
-```
-:::
-
-You can also disable isolation for specific files only by using `projects`:
-
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    projects: [
-      {
-        test: {
-          name: 'Isolated',
-          isolate: true, // (default value)
-          exclude: ['**.non-isolated.test.ts'],
-        },
-      },
-      {
-        test: {
-          name: 'Non-isolated',
-          isolate: false,
-          include: ['**.non-isolated.test.ts'],
-        },
-      },
-    ],
-  },
-})
-```
-
-:::tip
-If you are using `vmThreads` pool, you cannot disable isolation. Use `threads` pool instead to improve your tests performance.
-:::
-
-For some projects, it might also be desirable to disable parallelism to improve startup time. To do that, provide `--no-file-parallelism` flag to the CLI or set [`test.fileParallelism`](/config/fileparallelism) property in the config to `false`.
-
-::: code-group
-```bash [CLI]
-vitest --no-file-parallelism
-```
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    fileParallelism: false,
-  },
-})
-```
-:::
-
-## Limiting Directory Search
-
-You can limit the working directory when Vitest searches for files using [`test.dir`](/config/dir) option. This should make the search faster if you have unrelated folders and files in the root directory.
-
-## Caching Between Reruns
-
-In watch mode, Vitest caches all transformed files in memory, which makes reruns fast. However, this cache is discarded once the test run finishes. By enabling [`experimental.fsModuleCache`](/config/experimental#experimental-fsmodulecache), Vitest persists this cache to the file system so it can be reused across reruns.
-
-This improvement is most noticeable when rerunning a small number of tests that depend on a large module graph. For full test suites, parallelization already mitigates the cost because other tests populate the in-memory cache while earlier tests are still running. For example, running one test file with a huge module graph (>900 modules):
-
-```shell
-# the first run
-Duration  8.75s (transform 4.02s, setup 629ms, import 5.52s, tests 2.52s, environment 0ms, prepare 3ms)
-
-# the second run
-Duration  5.90s (transform 842ms, setup 543ms, import 2.35s, tests 2.94s, environment 0ms, prepare 3ms)
-```
-
-## Pool
-
-By default Vitest runs tests in `pool: 'forks'`. While `'forks'` pool is better for compatibility issues ([hanging process](/guide/common-errors.html#failed-to-terminate-worker) and [segfaults](/guide/common-errors.html#segfaults-and-native-code-errors)), it may be slightly slower than `pool: 'threads'` in larger projects.
-
-You can try to improve test run time by switching `pool` option in configuration:
-
-::: code-group
-```bash [CLI]
-vitest --pool=threads
-```
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    pool: 'threads',
-  },
-})
-```
-:::
-
-## Sharding
-
-Test sharding is a process of splitting your test suite into groups, or shards. This can be useful when you have a large test suite and multiple machines that could run subsets of that suite simultaneously.
-
-To split Vitest tests on multiple different runs, use [`--shard`](/guide/cli#shard) option with [`--reporter=blob`](/guide/reporters#blob-reporter) option:
-
-```sh
-vitest run --reporter=blob --shard=1/3 # 1st machine
-vitest run --reporter=blob --shard=2/3 # 2nd machine
-vitest run --reporter=blob --shard=3/3 # 3rd machine
-```
-
-> Vitest splits your _test files_, not your test cases, into shards. If you've got 1000 test files, the `--shard=1/4` option will run 250 test files, no matter how many test cases individual files have.
-
-Collect the results stored in `.vitest-reports` directory from each machine and merge them with [`--merge-reports`](/guide/cli#merge-reports) option:
-
-```sh
-vitest run --merge-reports
-```
-
-::: details GitHub Actions example
-This setup is also used at https://github.com/vitest-tests/test-sharding.
-
-```yaml
-# Inspired from https://playwright.dev/docs/test-sharding
-name: Tests
-on:
-  push:
-    branches:
-      - main
-jobs:
-  tests:
-    runs-on: ubuntu-latest
-    strategy:
-      matrix:
-        shardIndex: [1, 2, 3, 4]
-        shardTotal: [4]
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - name: Install pnpm
-        uses: pnpm/action-setup@a7487c7e89a18df4991f7f222e4898a00d66ddda # v4.1.0
-
-      - name: Install dependencies
-        run: pnpm i
-
-      - name: Run tests
-        run: pnpm run test --reporter=blob --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}
-
-      - name: Upload blob report to GitHub Actions Artifacts
-        if: ${{ !cancelled() }}
-        uses: actions/upload-artifact@v4
-        with:
-          name: blob-report-${{ matrix.shardIndex }}
-          path: .vitest-reports/*
-          include-hidden-files: true
-          retention-days: 1
-
-      - name: Upload attachments to GitHub Actions Artifacts
-        if: ${{ !cancelled() }}
-        uses: actions/upload-artifact@v4
-        with:
-          name: blob-attachments-${{ matrix.shardIndex }}
-          path: .vitest-attachments/**
-          include-hidden-files: true
-          retention-days: 1
-
-  merge-reports:
-    if: ${{ !cancelled() }}
-    needs: [tests]
-
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - name: Install pnpm
-        uses: pnpm/action-setup@a7487c7e89a18df4991f7f222e4898a00d66ddda # v4.1.0
-
-      - name: Install dependencies
-        run: pnpm i
-
-      - name: Download blob reports from GitHub Actions Artifacts
-        uses: actions/download-artifact@v4
-        with:
-          path: .vitest-reports
-          pattern: blob-report-*
-          merge-multiple: true
-
-      - name: Download attachments from GitHub Actions Artifacts
-        uses: actions/download-artifact@v4
-        with:
-          path: .vitest-attachments
-          pattern: blob-attachments-*
-          merge-multiple: true
-
-      - name: Merge reports
-        run: npx vitest --merge-reports
-```
-
-If your tests create file-based attachments (for example via `context.annotate` or custom artifacts), upload and restore [`attachmentsDir`](/config/attachmentsdir) in the merge job as shown above.
-
-:::
-
-:::tip
-Test sharding can also become useful on high CPU-count machines.
-
-Vitest will run only a single Vite server in its main thread. Rest of the threads are used to run test files.
-In a high CPU-count machine the main thread can become a bottleneck as it cannot handle all the requests coming from the threads. For example in 32 CPU machine the main thread is responsible to handle load coming from 31 test threads.
-
-To reduce the load from main thread's Vite server you can use test sharding. The load can be balanced on multiple Vite server.
-
-```sh
-# Example for splitting tests on 32 CPU to 4 shards.
-# As each process needs 1 main thread, there's 7 threads for test runners (1+7)*4 = 32
-# Use VITEST_MAX_WORKERS:
-VITEST_MAX_WORKERS=7 vitest run --reporter=blob --shard=1/4 & \
-VITEST_MAX_WORKERS=7 vitest run --reporter=blob --shard=2/4 & \
-VITEST_MAX_WORKERS=7 vitest run --reporter=blob --shard=3/4 & \
-VITEST_MAX_WORKERS=7 vitest run --reporter=blob --shard=4/4 & \
-wait # https://man7.org/linux/man-pages/man2/waitpid.2.html
-
-vitest run --merge-reports
-```
-
-:::

package/vendor/vitest-docs/guide/in-source.md

@@ -1,159 +0,0 @@
-# In-Source Testing
-
-Vitest provides a way to run tests within your source code along side the implementation, similar to [Rust's module tests](https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest).
-
-This makes the tests share the same closure as the implementations and able to test against private states without exporting. Meanwhile, it also brings a closer feedback loop for development.
-
-::: warning
-This guide explains how to write tests inside your source code. If you need to write tests in separate test files, follow the ["Writing Tests" guide](/guide/#writing-tests).
-:::
-
-## Setup
-
-To get started, put a `if (import.meta.vitest)` block at the end of your source file and write some tests inside it. For example:
-
-```ts [src/index.ts]
-// the implementation
-export function add(...args: number[]) {
-  return args.reduce((a, b) => a + b, 0)
-}
-
-// 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)
-  })
-}
-```
-
-Update the `includeSource` config for Vitest to grab the files under `src/`:
-
-```ts [vitest.config.ts]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    includeSource: ['src/**/*.{js,ts}'], // [!code ++]
-  },
-})
-```
-
-Then you can start to test!
-
-```bash
-$ npx vitest
-```
-
-## Production Build
-
-For the production build, you will need to set the `define` options in your config file, letting the bundler do the dead code elimination. For example, in Vite
-
-```ts [vite.config.ts]
-/// <reference types="vitest/config" />
-
-import { defineConfig } from 'vite'
-
-export default defineConfig({
-  test: {
-    includeSource: ['src/**/*.{js,ts}'],
-  },
-  define: { // [!code ++]
-    'import.meta.vitest': 'undefined', // [!code ++]
-  }, // [!code ++]
-})
-```
-
-### Other Bundlers
-
-::: details Rolldown
-```js [rolldown.config.js]
-import { defineConfig } from 'rolldown/config'
-
-export default defineConfig({
-  transform: {
-    define: { // [!code ++]
-      'import.meta.vitest': 'undefined', // [!code ++]
-    }, // [!code ++]
-  },
-})
-```
-
-Learn more: [Rolldown](https://rolldown.rs/)
-:::
-
-::: details Rollup
-```js [rollup.config.js]
-import replace from '@rollup/plugin-replace' // [!code ++]
-
-export default {
-  plugins: [
-    replace({ // [!code ++]
-      'import.meta.vitest': 'undefined', // [!code ++]
-    }) // [!code ++]
-  ],
-  // other options
-}
-```
-
-Learn more: [Rollup](https://rollupjs.org/)
-:::
-
-::: details unbuild
-```js [build.config.js]
-import { defineBuildConfig } from 'unbuild'
-
-export default defineBuildConfig({
-  replace: { // [!code ++]
-    'import.meta.vitest': 'undefined', // [!code ++]
-  }, // [!code ++]
-  // other options
-})
-```
-
-Learn more: [unbuild](https://github.com/unjs/unbuild)
-:::
-
-::: details webpack
-```js [webpack.config.js]
-const webpack = require('webpack')
-
-module.exports = {
-  plugins: [
-    new webpack.DefinePlugin({ // [!code ++]
-      'import.meta.vitest': 'undefined', // [!code ++]
-    })// [!code ++]
-  ],
-}
-```
-
-Learn more: [webpack](https://webpack.js.org/plugins/define-plugin/)
-:::
-
-## TypeScript
-
-To get TypeScript support for `import.meta.vitest`, add `vitest/importMeta` to your `tsconfig.json`:
-
-```json [tsconfig.json]
-{
-  "compilerOptions": {
-    "types": [
-      "vitest/importMeta" // [!code ++]
-    ]
-  }
-}
-```
-
-Reference to [`examples/in-source-test`](https://github.com/vitest-dev/vitest/tree/main/examples/in-source-test) for the full example.
-
-## Notes
-
-This feature could be useful for:
-
-- Unit testing for small-scoped functions or utilities
-- Prototyping
-- Inline Assertion
-
-It's recommended to **use separate test files instead** for more complex tests like components or E2E testing.