@vitest-agent/mcp 1.1.0 → 1.2.0

package/vendor/vitest-docs/guide/test-tags.md

@@ -1,314 +0,0 @@
-# Test Tags <Version>4.1.0</Version> {#test-tags}
-
-[`Tags`](/config/tags) let you label tests so you can filter what runs and override their options when needed.
-
-## Defining Tags
-
-Tags must be defined in your configuration file — Vitest does not provide any built-in tags. If a test uses a tag that isn't defined in the config, the test runner will throw an error. This prevents unexpected behavior from mistyped tag names. You can disable this check with the [`strictTags`](/config/stricttags) option.
-
-You must define a `name` of the tag, and you may define additional options that will be applied to every test marked with the tag, e.g., a `timeout`, or `retry`. For the full list of available options, see [`tags`](/config/tags).
-
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    tags: [
-      {
-        name: 'frontend',
-        description: 'Tests written for frontend.',
-      },
-      {
-        name: 'backend',
-        description: 'Tests written for backend.',
-      },
-      {
-        name: 'db',
-        description: 'Tests for database queries.',
-        timeout: 60_000,
-      },
-      {
-        name: 'flaky',
-        description: 'Flaky CI tests.',
-        retry: process.env.CI ? 3 : 0,
-        timeout: 30_000,
-        priority: 1,
-      },
-    ],
-  },
-})
-```
-
-::: warning
-If several tags have the same options and are used on the same test, they will be resolved in the order they were specified, or sorted by priority first (the lower the number, the higher the priority). Tags without a defined priority are merged first and will be overridden by higher priority ones:
-
-```ts
-test('flaky database test', { tags: ['flaky', 'db'] })
-// { timeout: 30_000, retry: 3 }
-```
-
-Note that the `timeout` is 30 seconds (and not 60) because `flaky` tag has a priority of `1` while `db` (that defines 60 second timeout) has no priority.
-
-If test defines its own options, they will have the highest priority:
-
-```ts
-test('flaky database test', { tags: ['flaky', 'db'], timeout: 120_000 })
-// { timeout: 120_000, retry: 3 }
-```
-:::
-
-If you are using TypeScript, you can enforce what tags are available by augmenting the `TestTags` type with a property that contains a union of strings (make sure this file is included by your `tsconfig`):
-
-```ts [vitest.shims.ts]
-import 'vitest'
-
-declare module 'vitest' {
-  interface TestTags {
-    tags:
-      | 'frontend'
-      | 'backend'
-      | 'db'
-      | 'flaky'
-  }
-}
-```
-
-To see all your tags, you can use [`--list-tags`](/guide/cli#listtags) command:
-
-```shell
-vitest --list-tags
-
-frontend: Tests written for frontend.
-backend: Tests written for backend.
-db: Tests for database queries.
-flaky: Flaky CI tests.
-```
-
-To print it in JSON, pass down `--list-tags=json`:
-
-```json
-{
-  "tags": [
-    {
-      "name": "frontend",
-      "description": "Tests written for frontend."
-    },
-    {
-      "name": "backend",
-      "description": "Tests written for backend."
-    },
-    {
-      "name": "db",
-      "description": "Tests for database queries.",
-      "timeout": 60000
-    },
-    {
-      "name": "flaky",
-      "description": "Flaky CI tests.",
-      "retry": 0,
-      "timeout": 30000,
-      "priority": 1
-    }
-  ],
-  "projects": []
-}
-```
-
-## Using Tags in Tests
-
-You can apply tags to individual tests or entire suites using the `tags` option:
-
-```ts
-import { describe, test } from 'vitest'
-
-test('renders homepage', { tags: ['frontend'] }, () => {
-  // ...
-})
-
-describe('API endpoints', { tags: ['backend'] }, () => {
-  test('returns user data', () => {
-    // This test inherits the "backend" tag from the parent suite
-  })
-
-  test('validates input', { tags: ['validation'] }, () => {
-    // This test has both "backend" (inherited) and "validation" tags
-  })
-})
-```
-
-Tags are inherited from parent suites, so all tests inside a tagged `describe` block will automatically have that tag.
-
-It's also possible to define `tags` for every test in the file by using JSDoc's `@module-tag` at the top of the file:
-
-```ts
-/**
- * Auth tests
- * @module-tag admin/pages/dashboard
- * @module-tag acceptance
- */
-
-test('dashboard renders items', () => {
-  // ...
-})
-```
-
-::: danger
-A `@module-tag` in a JSDoc comment applies to all tests in that file, not just the test it precedes.
-
-Consider this example:
-
-```js{3,10}
-describe('forms', () => {
-  /**
-   * @module-tag frontend
-   */
-  test('renders a form', () => {
-    // ...
-  })
-
-  /**
-   * @module-tag db
-   */
-  test('db returns users', () => {
-    // ...
-  })
-})
-```
-
-In this example, every test in the file will have both the `frontend` and `db` tags. To tag individual tests, use the options argument instead:
-
-```js{2,6}
-describe('forms', () => {
-  test('renders a form', { tags: 'frontend' }, () => {
-    // ...
-  })
-
-  test('db returns users', { tags: 'db' }, () => {
-    // ...
-  })
-})
-```
-:::
-
-## Filtering Tests by Tag
-
-To run only tests with specific tags, use the [`--tags-filter`](/guide/cli#tagsfilter) CLI option:
-
-```shell
-vitest --tags-filter=frontend
-vitest --tags-filter="frontend and backend"
-```
-
-If you are running Vitest UI, you can start a filter with a `tag:` prefix to filter out tests by tags using the same tags expression syntax:
-
-<img alt="The tags filter in Vitest UI" img-light src="/ui/light-ui-tags.png">
-<img alt="The tags filter in Vitest UI" img-dark src="/ui/dark-ui-tags.png">
-
-If you are using a programmatic API, you can pass down a `tagsFilter` option to [`startVitest`](/guide/advanced/#startvitest) or [`createVitest`](/guide/advanced/#createvitest):
-
-```ts
-import { startVitest } from 'vitest/node'
-
-await startVitest('test', [], {
-  tagsFilter: ['frontend and backend'],
-})
-```
-
-Or you can create a [test specification](/api/advanced/test-specification) with your custom filters:
-
-```ts
-const specification = vitest.getRootProject().createSpecification(
-  '/path-to-file.js',
-  {
-    testTagsFilter: ['frontend and backend'],
-  },
-)
-```
-
-### Syntax
-
-You can combine tags in different ways. Vitest supports these keywords:
-
-- `and` or `&&` to include both expressions
-- `or` or `||` to include at least one expression
-- `not` or `!` to exclude the expression
-- `*` to match any number of characters (0 or more)
-- `()` to group expressions and override precedence
-
-The parser follows standard [operator precedence](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_precedence): `not`/`!` has the highest priority, then `and`/`&&`, then `or`/`||`. Use parentheses to override default precedence.
-
-::: warning Reserved Names
-Tag names cannot be `and`, `or`, or `not` (case-insensitive) as these are reserved keywords. Tag names also cannot contain special characters (`(`, `)`, `&`, `|`, `!`, `*`, spaces) as these are used by the expression parser.
-:::
-
-### Wildcards
-
-You can use a wildcard (`*`) to match any number of characters:
-
-```shell
-vitest --tags-filter="unit/*"
-```
-
-This will match tags like `unit/components`, `unit/utils`, etc.
-
-### Excluding Tags
-
-To exclude tests with a specific tag, add an exclamation mark (`!`) at the start or a "not" keyword:
-
-```shell
-vitest --tags-filter="!slow and not flaky"
-```
-
-### Examples
-
-Here are some common filtering patterns:
-
-```shell
-# Run only unit tests
-vitest --tags-filter="unit"
-
-# Run tests that are both frontend AND fast
-vitest --tags-filter="frontend and fast"
-
-# Run tests that are either unit OR e2e
-vitest --tags-filter="unit or e2e"
-
-# Run all tests except slow ones
-vitest --tags-filter="!slow"
-
-# Run frontend tests that are not flaky
-vitest --tags-filter="frontend && !flaky"
-
-# Run tests matching a wildcard pattern
-vitest --tags-filter="api/*"
-
-# Complex expression with parentheses
-vitest --tags-filter="(unit || e2e) && !slow"
-
-# Run database tests that are either postgres or mysql, but not slow
-vitest --tags-filter="db && (postgres || mysql) && !slow"
-```
-
-You can also pass multiple `--tags-filter` flags. They are combined with AND logic:
-
-```shell
-# Run tests that match (unit OR e2e) AND are NOT slow
-vitest --tags-filter="unit || e2e" --tags-filter="!slow"
-```
-
-### Checking Tags Filter at Runtime
-
-You can use `TestRunner.matchesTags` (since Vitest 4.1.1) to check whether the current tags filter matches a set of tags. This is useful for conditionally running expensive setup logic only when relevant tests are included:
-
-```ts
-import { beforeAll, TestRunner } from 'vitest'
-
-beforeAll(async () => {
-  // Seed database when "vitest --tags-filter db" is used
-  if (TestRunner.matchesTags(['db'])) {
-    await seedDatabase()
-  }
-})
-```
-
-The method accepts an array of tags and returns `true` if the current `--tags-filter` would include a test with those tags. If no tags filter is active, it always returns `true`.

package/vendor/vitest-docs/guide/testing-types.md

@@ -1,149 +0,0 @@
-# Testing Types
-
-::: tip Sample Project
-
-[GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/typecheck) - [Play Online](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/typecheck?initialPath=__vitest__/)
-
-:::
-
-Vitest allows you to write tests for your types, using `expectTypeOf` or `assertType` syntaxes. By default all tests inside `*.test-d.ts` files are considered type tests, but you can change it with [`typecheck.include`](/config/typecheck#typecheck-include) config option.
-
-Under the hood Vitest calls `tsc` or `vue-tsc`, depending on your config, and parses results. Vitest will also print out type errors in your source code, if it finds any. You can disable it with [`typecheck.ignoreSourceErrors`](/config/typecheck#typecheck-ignoresourceerrors) config option.
-
-Keep in mind that Vitest doesn't run these files, they are only statically analyzed by the compiler. Meaning, that if you use a dynamic name or `test.each` or `test.for`, the test name will not be evaluated - it will be displayed as is.
-
-::: warning
-Before Vitest 2.1, your `typecheck.include` overrode the `include` pattern, so your runtime tests did not actually run; they were only type-checked.
-
-Since Vitest 2.1, if your `include` and `typecheck.include` overlap, Vitest will report type tests and runtime tests as separate entries.
-:::
-
-Using CLI flags, like `--allowOnly` and `-t` are also supported for type checking.
-
-```ts [mount.test-d.ts]
-import { assertType, expectTypeOf } from 'vitest'
-import { mount } from './mount.js'
-
-test('my types work properly', () => {
-  expectTypeOf(mount).toBeFunction()
-  expectTypeOf(mount).parameter(0).toExtend<{ name: string }>()
-
-  // @ts-expect-error name is a string
-  assertType(mount({ name: 42 }))
-})
-```
-
-Any type error triggered inside a test file will be treated as a test error, so you can use any type trick you want to test types of your project.
-
-You can see a list of possible matchers in [API section](/api/expect-typeof).
-
-## Reading Errors
-
-If you are using `expectTypeOf` API, refer to the [expect-type documentation on its error messages](https://github.com/mmkal/expect-type#error-messages).
-
-When types don't match, `.toEqualTypeOf` and `.toExtend` use a special helper type to produce error messages that are as actionable as possible. But there's a bit of an nuance to understanding them. Since the assertions are written "fluently", the failure should be on the "expected" type, not the "actual" type (`expect<Actual>().toEqualTypeOf<Expected>()`). This means that type errors can be a little confusing - so this library produces a `MismatchInfo` type to try to make explicit what the expectation is. For example:
-
-```ts
-expectTypeOf({ a: 1 }).toEqualTypeOf<{ a: string }>()
-```
-
-Is an assertion that will fail, since `{a: 1}` has type `{a: number}` and not `{a: string}`.  The error message in this case will read something like this:
-
-```
-test/test.ts:999:999 - error TS2344: Type '{ a: string; }' does not satisfy the constraint '{ a: \\"Expected: string, Actual: number\\"; }'.
-  Types of property 'a' are incompatible.
-    Type 'string' is not assignable to type '\\"Expected: string, Actual: number\\"'.
-
-999 expectTypeOf({a: 1}).toEqualTypeOf<{a: string}>()
-```
-
-Note that the type constraint reported is a human-readable messaging specifying both the "expected" and "actual" types. Rather than taking the sentence `Types of property 'a' are incompatible // Type 'string' is not assignable to type "Expected: string, Actual: number"` literally - just look at the property name (`'a'`) and the message: `Expected: string, Actual: number`. This will tell you what's wrong, in most cases. Extremely complex types will of course be more effort to debug, and may require some experimentation. Please [raise an issue](https://github.com/mmkal/expect-type) if the error messages are actually misleading.
-
-The `toBe...` methods (like `toBeString`, `toBeNumber`, `toBeVoid` etc.) fail by resolving to a non-callable type when the `Actual` type under test doesn't match up. For example, the failure for an assertion like `expectTypeOf(1).toBeString()` will look something like this:
-
-```
-test/test.ts:999:999 - error TS2349: This expression is not callable.
-  Type 'ExpectString<number>' has no call signatures.
-
-999 expectTypeOf(1).toBeString()
-                    ~~~~~~~~~~
-```
-
-The `This expression is not callable` part isn't all that helpful - the meaningful error is the next line, `Type 'ExpectString<number> has no call signatures`. This essentially means you passed a number but asserted it should be a string.
-
-If TypeScript added support for ["throw" types](https://github.com/microsoft/TypeScript/pull/40468) these error messages could be improved significantly. Until then they will take a certain amount of squinting.
-
-### Concrete "expected" objects vs typeargs
-
-Error messages for an assertion like this:
-
-```ts
-expectTypeOf({ a: 1 }).toEqualTypeOf({ a: '' })
-```
-
-Will be less helpful than for an assertion like this:
-
-```ts
-expectTypeOf({ a: 1 }).toEqualTypeOf<{ a: string }>()
-```
-
-This is because the TypeScript compiler needs to infer the typearg for the `.toEqualTypeOf({a: ''})` style, and this library can only mark it as a failure by comparing it against a generic `Mismatch` type. So, where possible, use a typearg rather than a concrete type for `.toEqualTypeOf` and `.toExtend`. If it's much more convenient to compare two concrete types, you can use `typeof`:
-
-```ts
-const one = valueFromFunctionOne({ some: { complex: inputs } })
-const two = valueFromFunctionTwo({ some: { other: inputs } })
-
-expectTypeOf(one).toEqualTypeOf<typeof two>()
-```
-
-If you find it hard working with `expectTypeOf` API and figuring out errors, you can always use more simple `assertType` API:
-
-```ts
-const answer = 42
-
-assertType<number>(answer)
-// @ts-expect-error answer is not a string
-assertType<string>(answer)
-```
-
-::: tip
-When using `@ts-expect-error` syntax, you might want to make sure that you didn't make a typo. You can do that by including your type files in [`test.include`](/config/include) config option, so Vitest will also actually *run* these tests and fail with `ReferenceError`.
-
-This will pass, because it expects an error, but the word “answer” has a typo, so it's a false positive error:
-
-```ts
-// @ts-expect-error answer is not a string
-assertType<string>(answr)
-```
-:::
-
-## Run Typechecking
-
-To enable typechecking, just add [`--typecheck`](/config/typecheck) flag to your Vitest command in `package.json`:
-
-```json [package.json]
-{
-  "scripts": {
-    "test": "vitest --typecheck"
-  }
-}
-```
-
-Now you can run typecheck:
-
-::: code-group
-```bash [npm]
-npm run test
-```
-```bash [yarn]
-yarn test
-```
-```bash [pnpm]
-pnpm run test
-```
-```bash [bun]
-bun test
-```
-:::
-
-Vitest uses `tsc --noEmit` or `vue-tsc --noEmit`, depending on your configuration, so you can remove these scripts from your pipeline.

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

@@ -1,160 +0,0 @@
-# Vitest UI
-
-Powered by Vite, Vitest also has a dev server under the hood when running the tests. This allows Vitest to provide a beautiful UI to view and interact with your tests. The Vitest UI is optional, so you'll need to install it with:
-
-```bash
-npm i -D @vitest/ui
-```
-
-Then you can start the tests with UI by passing the `--ui` flag:
-
-```bash
-vitest --ui
-```
-
-Then you can visit the Vitest UI at <a href="http://localhost:51204/__vitest__/">`http://localhost:51204/__vitest__/`</a>
-
-::: warning
-The UI is interactive and requires a running Vite server, so make sure to run Vitest in `watch` mode (the default). Alternatively, you can generate a static HTML report that looks identical to the Vitest UI by specifying `html` in config's `reporters` option.
-:::
-
-<img alt="Vitest UI" img-light src="/ui-1-light.png">
-<img alt="Vitest UI" img-dark src="/ui-1-dark.png">
-
-UI can also be used as a reporter. Use `'html'` reporter in your Vitest configuration to generate HTML output and preview the results of your tests:
-
-```ts [vitest.config.ts]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    reporters: ['html'],
-  },
-})
-```
-
-You can check your coverage report in Vitest UI: see [Vitest UI Coverage](/guide/coverage#vitest-ui) for more details.
-
-::: warning
-If you still want to see how your tests are running in real time in the terminal, don't forget to add `default` reporter to `reporters` option: `['default', 'html']`.
-:::
-
-::: tip
-To preview your HTML report, you can use the [vite preview](https://vitejs.dev/guide/cli.html#vite-preview) command:
-
-```sh
-npx vite preview --outDir ./html
-```
-
-You can configure output with [`outputFile`](/config/outputfile) config option. You need to specify `.html` path there. For example, `./html/index.html` is the default value.
-:::
-
-::: tip
-To view the HTML report from CI, for example in GitHub Actions, upload the output directory as an artifact:
-
-```yaml
-- uses: actions/upload-artifact@v4
-  id: upload-report
-  with:
-    name: vitest-report
-    path: html/
-
-- name: Viewer link in summary
-  run: echo "[View HTML report](https://viewer.vitest.dev/?url=${{ steps.upload-report.outputs.artifact-url }})" >> $GITHUB_STEP_SUMMARY
-```
-
-This adds a link to the job summary. Click it to open the report in [Vitest Viewer](https://viewer.vitest.dev/) directly in the browser. You can also download the artifact manually and extract it, then run `vite preview` locally as above.
-:::
-
-## Module Graph
-
-Module Graph's tab displays the module graph of the selected test file.
-
-::: info
-All of the provided images use [Zammad](https://github.com/zammad/zammad) repository as an example.
-:::
-
-<img alt="The module graph view" img-light src="/ui/light-module-graph.png">
-<img alt="The module graph view" img-dark src="/ui/dark-module-graph.png">
-
-If there are more than 50 modules, the module graph displays only the first two levels of the graph to reduce the visual clutter. You can always click on "Show Full Graph" icon to preview the full graph.
-
-<center>
-  <img alt="The 'Show Full Graph' button located close to the legend" img-light src="/ui/light-ui-show-graph.png">
-  <img alt="The 'Show Full Graph' button located close to the legend" img-dark src="/ui/dark-ui-show-graph.png">
-</center>
-
-::: warning
-Note that if your graph is too big, it may take some time before the node positions are stabilized.
-:::
-
-You can always restore the entry module graph by clicking on "Reset". To expand the module graph, right-click or hold <kbd>Shift</kbd> while clicking the node that interests you. It will display all nodes related to the selected one.
-
-By default, Vitest doesn't show the modules from `node_modules`. Usually, these modules are externalized. You can enable them by deselecting "Hide node_modules".
-
-### Module Info
-
-By left-clicking on the module node, you open the Module Info view.
-
-<img alt="The module info view for an inlined module" img-light src="/ui/light-module-info.png">
-<img alt="The module info view for an inlined module" img-dark src="/ui/dark-module-info.png">
-
-This view is separated into two parts. The top part shows the full module ID and some diagnostics about the module. If [`experimental.fsModuleCache`](/config/experimental#experimental-fsmodulecache) is enabled, there will be a "cached" or "not cached" badge. On the right you can see time diagnostics:
-
-- Self Time: the time it took to import the module, excluding static imports.
-- Total Time: the time it took to import the module, including static imports. Note that this does not include `transform` time of the current module.
-- Transform: the time it took to transform the module.
-
-If you opened this view by clicking on an import, you will also see a "Back" button at the start that will take you to the previous module.
-
-The bottom part depends on the module type. If the module is external, you will only see the source code of that file. You will not be able to traverse the module graph any further, and you won't see how long it took to import static imports.
-
-<img alt="The module info view for an external module" img-light src="/ui/light-module-info-external.png">
-<img alt="The module info view for an external module" img-dark src="/ui/dark-module-info-external.png">
-
-If the module was inlined, you will see three more windows:
-
-- Source: unchanged source code of the module
-- Transformed: the transformed code that Vitest executes using Vite's [module runner](https://vite.dev/guide/api-environment-runtimes#modulerunner)
-- Source Map (v3): source map mappings
-
-All static imports in the "Source" window show a total time it took to evaluate them by the current module. If the import was already evaluated in the module graph, it will show `0ms` because it is cached by that point.
-
-If the module took longer than the [`danger` threshold](/config/experimental#experimental-importdurations-thresholds) (default: 500ms) to load, the time will be displayed in red. If the module took longer than the [`warn` threshold](/config/experimental#experimental-importdurations-thresholds) (default: 100ms), the time will be displayed in orange.
-
-You can click on an import source to jump into that module and traverse the graph further (note `./support/assertions/index.ts` below).
-
-<img alt="The module info view for an internal module" img-light src="/ui/light-module-info-traverse.png">
-<img alt="The module info view for an internal module" img-dark src="/ui/dark-module-info-traverse.png">
-
-::: warning
-Note that type-only imports are not executed at runtime and do not display a total duration. They also cannot be opened.
-:::
-
-If another plugin injects a module import during transformation, those imports will be displayed at the start of the module in gray colour (for example, modules injected by `import.meta.glob`). They also show the total time and can be traversed further.
-
-<img alt="The module info view for an internal module" img-light src="/ui/light-module-info-shadow.png">
-<img alt="The module info view for an internal module" img-dark src="/ui/dark-module-info-shadow.png">
-
-::: tip
-If you are developing a custom integration on top of Vitest, you can use [`vitest.experimental_getSourceModuleDiagnostic`](/api/advanced/vitest#getsourcemodulediagnostic) to retrieve this information.
-:::
-
-### Import Breakdown
-
-::: tip FEEDBACK
-Please, leave feedback regarding this feature in a [GitHub Discussion](https://github.com/vitest-dev/vitest/discussions/9224).
-:::
-
-The Module Graph tab also provides an Import Breakdown with a list of modules that take the longest time to load (top 10 by default), sorted by Total Time.
-
-<img alt="Import breakdown with a list of top 10 modules that take the longest time to load" img-light src="/ui/light-import-breakdown.png">
-<img alt="Import breakdown with a list of top 10 modules that take the longest time to load" img-dark src="/ui/dark-import-breakdown.png">
-
-You can click on the module to see the Module Info. If the module is external, it will have the yellow color (the same color in the module graph).
-
-The breakdown shows a list of modules with self time, total time, and a percentage relative to the time it took to load the whole test file.
-
-The "Show Import Breakdown" icon will have a red color if there is at least one file that took longer than the [`danger` threshold](/config/experimental#experimental-importdurations-thresholds) (default: 500ms) to load, and it will be orange if there is at least one file that took longer than the [`warn` threshold](/config/experimental#experimental-importdurations-thresholds) (default: 100ms).
-
-You can use [`experimental.importDurations.limit`](/config/experimental#experimental-importdurationslimit) to control the number of imports displayed.

package/vendor/vitest-docs/guide/using-plugins.md

@@ -1,5 +0,0 @@
-# Using Plugins
-
-Vitest can be extended using plugins, similar to how Vite plugins work. This allows you to enhance and customize Vitest's functionality by using the same API and concepts of Vite plugins.
-
-For detailed guidance on how to write plugins, you can refer to the [Vite plugin documentation](https://vitejs.dev/guide/api-plugin).