@vitest-agent/mcp 1.0.1 → 1.2.0

package/public/vendor/vitest-docs/guide/cli.md

@@ -1,234 +0,0 @@
-# Command Line Interface
-
-## Commands
-
-### `vitest`
-
-Start Vitest in the current directory. Will enter the watch mode in development environment and run mode in CI (or non-interactive terminal) automatically.
-
-You can pass an additional argument as the filter of the test files to run. For example:
-
-```bash
-vitest foobar
-```
-
-Will run only the test file that contains `foobar` in their paths. This filter only checks inclusion and doesn't support regexp or glob patterns (unless your terminal processes it before Vitest receives the filter).
-
-Since Vitest 3, you can also specify the test by filename and line number:
-
-```bash
-$ vitest basic/foo.test.ts:10
-```
-
-::: warning
-Note that Vitest requires the full filename for this feature to work. It can be relative to the current working directory or an absolute file path.
-
-```bash
-$ vitest basic/foo.js:10 # ✅
-$ vitest ./basic/foo.js:10 # ✅
-$ vitest /users/project/basic/foo.js:10 # ✅
-$ vitest foo:10 # ❌
-$ vitest ./basic/foo:10 # ❌
-```
-
-At the moment Vitest also doesn't support ranges:
-
-```bash
-$ vitest basic/foo.test.ts:10, basic/foo.test.ts:25 # ✅
-$ vitest basic/foo.test.ts:10-25 # ❌
-```
-:::
-
-### `vitest run`
-
-Perform a single run without watch mode.
-
-### `vitest watch`
-
-Run all test suites but watch for changes and rerun tests when they change. Same as calling `vitest` without an argument. Will fallback to `vitest run` in CI or when stdin is not a TTY (non-interactive environment).
-
-### `vitest dev`
-
-Alias to `vitest watch`.
-
-### `vitest related`
-
-Run only tests that cover a list of source files. Works with static imports (e.g., `import('./index.js')` or `import index from './index.js`), but not the dynamic ones (e.g., `import(filepath)`). All files should be relative to root folder.
-
-Useful to run with [`lint-staged`](https://github.com/okonet/lint-staged) or with your CI setup.
-
-```bash
-vitest related /src/index.ts /src/hello-world.js
-```
-
-::: tip
-Don't forget that Vitest runs with enabled watch mode by default. If you are using tools like `lint-staged`, you  should also pass `--run` option, so that command can exit normally.
-
-```js [.lintstagedrc.js]
-export default {
-  '*.{js,ts}': 'vitest related --run',
-}
-```
-:::
-
-### `vitest bench`
-
-Run only [benchmark](/guide/features.html#benchmarking) tests, which compare performance results.
-
-### `vitest init`
-
-`vitest init <name>` can be used to setup project configuration. At the moment, it only supports [`browser`](/guide/browser/) value:
-
-```bash
-vitest init browser
-```
-
-### `vitest list`
-
-`vitest list` command inherits all `vitest` options to print the list of all matching tests. This command ignores `reporters` option. By default, it will print the names of all tests that matched the file filter and name pattern:
-
-```shell
-vitest list filename.spec.ts -t="some-test"
-```
-
-```txt
-describe > some-test
-describe > some-test > test 1
-describe > some-test > test 2
-```
-
-You can pass down `--json` flag to print tests in JSON format or save it in a separate file:
-
-```bash
-vitest list filename.spec.ts -t="some-test" --json=./file.json
-```
-
-If `--json` flag doesn't receive a value, it will output the JSON into stdout.
-
-You also can pass down `--filesOnly` flag to print the test files only:
-
-```bash
-vitest list --filesOnly
-```
-
-```txt
-tests/test1.test.ts
-tests/test2.test.ts
-```
-
-Since Vitest 4.1, you may pass `--static-parse` to [parse test files](/api/advanced/vitest#parsespecifications) instead of running them to collect tests. Vitest parses test files with limited concurrency, defaulting to `os.availableParallelism()`. You can change it via the `--static-parse-concurrency` option.
-
-## Shell Autocompletions
-
-Vitest provides shell autocompletions for commands, options, and option values powered by [`@bomb.sh/tab`](https://github.com/bombshell-dev/tab).
-
-### Setup
-
-For permanent setup in zsh, add this to your `~/.zshrc`:
-
-```bash
-# Add to ~/.zshrc for permanent autocompletions (same can be done for other shells)
-source <(vitest complete zsh)
-```
-
-### Package Manager Integration
-
-`@bomb.sh/tab` integrates with [package managers](https://github.com/bombshell-dev/tab?tab=readme-ov-file#package-manager-completions). Autocompletions work when running vitest directly:
-
-::: code-group
-
-```bash [npm]
-npm vitest <Tab>
-```
-
-```bash [npm]
-npm exec vitest <Tab>
-```
-
-```bash [pnpm]
-pnpm vitest <Tab>
-```
-
-```bash [yarn]
-yarn vitest <Tab>
-```
-
-```bash [bun]
-bun vitest <Tab>
-```
-
-:::
-
-For package manager autocompletions, you should install [tab's package manager completions](https://github.com/bombshell-dev/tab?tab=readme-ov-file#package-manager-completions) separately.
-
-## Options
-
-::: tip
-Vitest supports both camel case and kebab case for [CLI arguments](https://github.com/cacjs/cac#dot-nested-options). For example, `--passWithNoTests` and `--pass-with-no-tests` will both work (`--no-color` and `--inspect-brk` are the exceptions).
-
-Vitest also supports different ways of specifying the value: `--reporter dot` and `--reporter=dot` are both valid.
-
-If option supports an array of values, you need to pass the option multiple times:
-
-```
-vitest --reporter=dot --reporter=default
-```
-
-Boolean options can be negated with `no-` prefix. Specifying the value as `false` also works:
-
-```
-vitest --no-api
-vitest --api=false
-```
-:::
-
-<!--@include: ./cli-generated.md-->
-
-### changed
-
-- **Type:** `boolean | string`
-- **Default:** false
-
-Run tests only against changed files. If no value is provided, it will run tests against uncommitted changes (including staged and unstaged).
-
-To run tests against changes made in the last commit, you can use `--changed HEAD~1`. You can also pass commit hash (e.g. `--changed 09a9920`) or branch name (e.g. `--changed origin/develop`).
-
-When used with code coverage the report will contain only the files that were related to the changes.
-
-If paired with the [`forceRerunTriggers`](/config/forcereruntriggers) config option it will run the whole test suite if at least one of the files listed in the `forceRerunTriggers` list changes. By default, changes to the Vitest config file and `package.json` will always rerun the whole suite.
-
-### shard
-
-- **Type:** `string`
-- **Default:** disabled
-
-Test suite shard to execute in a format of `<index>`/`<count>`, where
-
-- `count` is a positive integer, count of divided parts
-- `index` is a positive integer, index of divided part
-
-This command will divide all tests into `count` equal parts, and will run only those that happen to be in an `index` part. For example, to split your tests suite into three parts, use this:
-
-```sh
-vitest run --shard=1/3
-vitest run --shard=2/3
-vitest run --shard=3/3
-```
-
-:::warning
-You cannot use this option with `--watch` enabled (enabled in dev by default).
-:::
-
-::: tip
-If `--reporter=blob` is used without an output file, the default path will include the current shard config to avoid collisions with other Vitest processes.
-:::
-
-### merge-reports
-
-- **Type:** `boolean | string`
-
-Merges every blob report located in the specified folder (`.vitest-reports` by default). You can use any reporters with this command (except [`blob`](/guide/reporters#blob-reporter)):
-
-```sh
-vitest --merge-reports --reporter=junit
-```

package/public/vendor/vitest-docs/guide/common-errors.md

@@ -1,163 +0,0 @@
-# Common Errors
-
-## Cannot find module './relative-path'
-
-If you receive an error that module cannot be found, it might mean several different things:
-
-1. You misspelled the path. Make sure the path is correct.
-
-2. It's possible that you rely on `baseUrl` in your `tsconfig.json`. Vite doesn't take into account `tsconfig.json` by default, so you might need to install [`vite-tsconfig-paths`](https://npmx.dev/package/vite-tsconfig-paths) yourself, if you rely on this behavior.
-
-```ts
-import { defineConfig } from 'vitest/config'
-import tsconfigPaths from 'vite-tsconfig-paths'
-
-export default defineConfig({
-  plugins: [tsconfigPaths()]
-})
-```
-
-Or rewrite your path to not be relative to root:
-
-```diff
-- import helpers from 'src/helpers'
-+ import helpers from '../src/helpers'
-```
-
-3. Make sure you don't have relative [aliases](/config/alias). Vite treats them as relative to the file where the import is instead of the root.
-
-```ts
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    alias: {
-      '@/': './src/', // [!code --]
-      '@/': new URL('./src/', import.meta.url).pathname, // [!code ++]
-    }
-  }
-})
-```
-
-## Failed to Terminate Worker
-
-This error can happen when NodeJS's `fetch` is used with [`pool: 'threads'`](/config/pool#threads). See [#3077](https://github.com/vitest-dev/vitest/issues/3077) for details.
-
-The default [`pool: 'forks'`](/config/pool#forks) does not have this issue. If you've explicitly set `pool: 'threads'`, switching back to `'forks'` or using [`'vmForks'`](/config/pool#vmforks) will resolve it.
-
-## Custom package conditions are not resolved
-
-If you are using custom conditions in your `package.json` [exports](https://nodejs.org/api/packages.html#package-entry-points) or [subpath imports](https://nodejs.org/api/packages.html#subpath-imports), you may find that Vitest does not respect these conditions by default.
-
-For example, if you have the following in your `package.json`:
-
-```json
-{
-  "exports": {
-    ".": {
-      "custom": "./lib/custom.js",
-      "import": "./lib/index.js"
-    }
-  },
-  "imports": {
-    "#internal": {
-      "custom": "./src/internal.js",
-      "default": "./lib/internal.js"
-    }
-  }
-}
-```
-
-By default, Vitest will only use the `import` and `default` conditions. To make Vitest respect custom conditions, you need to configure [`ssr.resolve.conditions`](https://vite.dev/config/ssr-options#ssr-resolve-conditions) in your Vitest config:
-
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  ssr: {
-    resolve: {
-      conditions: ['custom', 'import', 'default'],
-    },
-  },
-})
-```
-
-::: tip Why `ssr.resolve.conditions` and not `resolve.conditions`?
-Vitest follows Vite's configuration convention:
-- [`resolve.conditions`](https://vite.dev/config/shared-options#resolve-conditions) applies to Vite's `client` environment, which corresponds to Vitest's browser mode, jsdom, happy-dom, or custom environments with `viteEnvironment: 'client'`.
-- [`ssr.resolve.conditions`](https://vite.dev/config/ssr-options#ssr-resolve-conditions) applies to Vite's `ssr` environment, which corresponds to Vitest's node environment or custom environments with `viteEnvironment: 'ssr'`.
-
-Since Vitest defaults to the `node` environment (which uses `viteEnvironment: 'ssr'`), module resolution uses `ssr.resolve.conditions`. This applies to both package exports and subpath imports.
-
-You can learn more about Vite environments and Vitest environments in [`environment`](/config/environment).
-:::
-
-## Segfaults and Native Code Errors
-
-Running [native NodeJS modules](https://nodejs.org/api/addons.html) in `pool: 'threads'` can run into cryptic errors coming from the native code.
-
-- `Segmentation fault (core dumped)`
-- `thread '<unnamed>' panicked at 'assertion failed`
-- `Abort trap: 6`
-- `internal error: entered unreachable code`
-
-In these cases the native module is likely not built to be multi-thread safe. As a workaround, you can switch to `pool: 'forks'` which runs the test cases in multiple `node:child_process` instead of multiple `node:worker_threads`.
-
-::: code-group
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    pool: 'forks',
-  },
-})
-```
-```bash [CLI]
-vitest --pool=forks
-```
-:::
-
-## Unhandled Promise Rejection
-
-This error happens when a Promise rejects but no `.catch()` handler or `await` is attached to it before the microtask queue flushes. This behavior comes from JavaScript itself and is not specific to Vitest. Learn more in the [Node.js documentation](https://nodejs.org/api/process.html#event-unhandledrejection).
-
-A common cause is calling an async function without `await`ing it:
-
-```ts
-async function fetchUser(id) {
-  const res = await fetch(`/api/users/${id}`)
-  if (!res.ok) {
-    throw new Error(`User ${id} not found`) // [!code highlight]
-  }
-  return res.json()
-}
-
-test('fetches user', async () => {
-  fetchUser(123) // [!code error]
-})
-```
-
-Because `fetchUser()` is not `await`ed, its rejection has no handler and Vitest reports:
-
-```
-Unhandled Rejection: Error: User 123 not found
-```
-
-### Fix
-
-`await` the promise so Vitest can catch the error:
-
-```ts
-test('fetches user', async () => {
-  await fetchUser(123) // [!code ++]
-})
-```
-
-If you expect the call to throw, use [`expect().rejects`](/api/expect#rejects):
-
-```ts
-test('rejects for missing user', async () => {
-  await expect(fetchUser(123)).rejects.toThrow('User 123 not found')
-})
-```