@vitest-agent/mcp 1.1.0 → 1.2.0

package/vendor/vitest-docs/api/advanced/test-collection.md

@@ -1,89 +0,0 @@
-# TestCollection
-
-`TestCollection` represents a collection of top-level [suites](/api/advanced/test-suite) and [tests](/api/advanced/test-case) in a suite or a module. It also provides useful methods to iterate over itself.
-
-::: info
-Most methods return an iterator instead of an array for better performance in case you don't need every item in the collection. If you prefer working with array, you can spread the iterator: `[...children.allSuites()]`.
-
-Also note that the collection itself is an iterator:
-
-```ts
-for (const child of module.children) {
-  console.log(child.type, child.name)
-}
-```
-:::
-
-## size
-
-The number of tests and suites in the collection.
-
-::: warning
-This number includes only tests and suites at the top-level, it doesn't include nested suites and tests.
-:::
-
-## at
-
-```ts
-function at(index: number): TestCase | TestSuite | undefined
-```
-
-Returns the test or suite at a specific index. This method accepts negative indexes.
-
-## array
-
-```ts
-function array(): (TestCase | TestSuite)[]
-```
-
-The same collection but as an array. This is useful if you want to use `Array` methods like `map` and `filter` that are not supported by the `TaskCollection` implementation.
-
-## allSuites
-
-```ts
-function allSuites(): Generator<TestSuite, undefined, void>
-```
-
-Filters all suites that are part of this collection and its children.
-
-```ts
-for (const suite of module.children.allSuites()) {
-  if (suite.errors().length) {
-    console.log('failed to collect', suite.errors())
-  }
-}
-```
-
-## allTests
-
-```ts
-function allTests(state?: TestState): Generator<TestCase, undefined, void>
-```
-
-Filters all tests that are part of this collection and its children.
-
-```ts
-for (const test of module.children.allTests()) {
-  if (test.result().state === 'pending') {
-    console.log('test', test.fullName, 'did not finish')
-  }
-}
-```
-
-You can pass down a `state` value to filter tests by the state.
-
-## tests
-
-```ts
-function tests(state?: TestState): Generator<TestCase, undefined, void>
-```
-
-Filters only the tests that are part of this collection. You can pass down a `state` value to filter tests by the state.
-
-## suites
-
-```ts
-function suites(): Generator<TestSuite, undefined, void>
-```
-
-Filters only the suites that are part of this collection.

package/vendor/vitest-docs/api/advanced/test-module.md

@@ -1,140 +0,0 @@
-# TestModule
-
-The `TestModule` class represents a single module in a single project. This class is only available in the main thread. Refer to the ["Runner API"](/api/advanced/runner#tasks) if you are working with runtime tasks.
-
-The `TestModule` instance always has a `type` property with the value of `module`. You can use it to distinguish between different task types:
-
-```ts
-if (task.type === 'module') {
-  task // TestModule
-}
-```
-
-::: warning Extending Suite Methods
-The `TestModule` class inherits all methods and properties from the [`TestSuite`](/api/advanced/test-suite). This guide will only list methods and properties unique to the `TestModule`.
-:::
-
-## moduleId
-
-This is usually an absolute unix file path (even on Windows). It can be a virtual id if the file is not on the disk. This value corresponds to Vite's `ModuleGraph` id.
-
-```ts
-'C:/Users/Documents/project/example.test.ts' // ✅
-'/Users/mac/project/example.test.ts' // ✅
-'C:\\Users\\Documents\\project\\example.test.ts' // ❌
-```
-
-## relativeModuleId
-
-Module id relative to the project. This is the same as `task.name` in the deprecated API.
-
-```ts
-'project/example.test.ts' // ✅
-'example.test.ts' // ✅
-'project\\example.test.ts' // ❌
-```
-
-## state
-
-```ts
-function state(): TestModuleState
-```
-
-Works the same way as [`testSuite.state()`](/api/advanced/test-suite#state), but can also return `queued` if module wasn't executed yet.
-
-## meta <Version>3.1.0</Version> {#meta}
-
-```ts
-function meta(): TaskMeta
-```
-
-Custom [metadata](/api/advanced/metadata) that was attached to the module during its execution or collection. The meta can be attached by assigning a property to the `task.meta` object during a test run:
-
-```ts {5,10}
-import { test } from 'vitest'
-
-describe('the validation works correctly', (task) => {
-  // assign "decorated" during collection
-  task.file.meta.decorated = false
-
-  test('some test', ({ task }) => {
-    // assign "decorated" during test run, it will be available
-    // only in onTestCaseReady hook
-    task.file.meta.decorated = false
-  })
-})
-```
-
-:::tip
-If metadata was attached during collection (outside of the `test` function), then it will be available in [`onTestModuleCollected`](./reporters#ontestmodulecollected) hook in the custom reporter.
-:::
-
-## diagnostic
-
-```ts
-function diagnostic(): ModuleDiagnostic
-```
-
-Useful information about the module like duration, memory usage, etc. If the module was not executed yet, all diagnostic values will return `0`.
-
-```ts
-interface ModuleDiagnostic {
-  /**
-   * The time it takes to import and initiate an environment.
-   */
-  readonly environmentSetupDuration: number
-  /**
-   * The time it takes Vitest to setup test harness (runner, mocks, etc.).
-   */
-  readonly prepareDuration: number
-  /**
-   * The time it takes to import the test module.
-   * This includes importing everything in the module and executing suite callbacks.
-   */
-  readonly collectDuration: number
-  /**
-   * The time it takes to import the setup module.
-   */
-  readonly setupDuration: number
-  /**
-   * Accumulated duration of all tests and hooks in the module.
-   */
-  readonly duration: number
-  /**
-   * The amount of memory used by the module in bytes.
-   * This value is only available if the test was executed with `logHeapUsage` flag.
-   */
-  readonly heap: number | undefined
-  /**
-   * The time spent importing every non-externalized dependency that Vitest has processed.
-   */
-  readonly importDurations: Record<string, ImportDuration>
-}
-
-/** The time spent importing & executing a non-externalized file. */
-interface ImportDuration {
-  /** The time spent importing & executing the file itself, not counting all non-externalized imports that the file does. */
-  selfTime: number
-
-  /** The time spent importing & executing the file and all its imports. */
-  totalTime: number
-}
-```
-
-## viteEnvironment <Version>4.1.0</Version> {#viteenvironment}
-
-This is a Vite's [`DevEnvironment`](https://vite.dev/guide/api-environment) that transforms all files inside of the test module.
-
-::: details History
-- `v4.0.15`: added as experimental
-:::
-
-## toTestSpecification <Version>4.1.0</Version> {#totestspecification}
-
-```ts
-function toTestSpecification(testCases?: TestCase[]): TestSpecification
-```
-
-Returns a new [test specification](/api/advanced/test-specification) that can be used to filter or run this specific test module.
-
-It accepts an optional array of test cases that should be filtered.

package/vendor/vitest-docs/api/advanced/test-project.md

@@ -1,321 +0,0 @@
-# TestProject <Version>3.0.0</Version> {#testproject}
-
-::: warning
-This guide describes the advanced Node.js API. If you just want to define projects, follow the ["Test Projects"](/guide/projects) guide.
-:::
-
-## name
-
-The name is a unique string assigned by the user or interpreted by Vitest. If user did not provide a name, Vitest tries to load a `package.json` in the root of the project and takes the `name` property from there. If there is no `package.json`, Vitest uses the name of the folder by default. Inline projects use numbers as the name (converted to string).
-
-::: code-group
-```ts [node.js]
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test')
-vitest.projects.map(p => p.name) === [
-  '@pkg/server',
-  'utils',
-  '2',
-  'custom'
-]
-```
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    projects: [
-      './packages/server', // has package.json with "@pkg/server"
-      './utils', // doesn't have a package.json file
-      {
-        // doesn't customize the name
-        test: {
-          pool: 'threads',
-        },
-      },
-      {
-        // customized the name
-        test: {
-          name: 'custom',
-        },
-      },
-    ],
-  },
-})
-```
-:::
-
-::: info
-If the [root project](/api/advanced/vitest#getrootproject) is not part of user projects, its `name` will not be resolved.
-:::
-
-## vitest
-
-`vitest` references the global [`Vitest`](/api/advanced/vitest) process.
-
-## serializedConfig
-
-This is the config that test processes receive. Vitest [serializes config](https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/node/config/serializeConfig.ts) manually by removing all functions and properties that are not possible to serialize. Since this value is available in both tests and node, its type is exported from the main entry point.
-
-```ts
-import type { SerializedConfig } from 'vitest'
-
-const config: SerializedConfig = vitest.projects[0].serializedConfig
-```
-
-::: warning
-The `serializedConfig` property is a getter. Every time it's accessed Vitest serializes the config again in case it was changed. This also means that it always returns a different reference:
-
-```ts
-project.serializedConfig === project.serializedConfig // ❌
-```
-:::
-
-## globalConfig
-
-The test config that [`Vitest`](/api/advanced/vitest) was initialized with. If this is the [root project](/api/advanced/vitest#getrootproject), `globalConfig` and `config` will reference the same object. This config is useful for values that cannot be set on the project level, like `coverage` or `reporters`.
-
-```ts
-import type { ResolvedConfig } from 'vitest/node'
-
-vitest.config === vitest.projects[0].globalConfig
-```
-
-## config
-
-This is the project's resolved test config.
-
-## hash <Version>3.2.0</Version> {#hash}
-
-The unique hash of this project. This value is consistent between the reruns.
-
-It is based on the root of the project and its name. Note that the root path is not consistent between different OS, so the hash will also be different.
-
-## vite
-
-This is project's [`ViteDevServer`](https://vite.dev/guide/api-javascript#vitedevserver). All projects have their own Vite servers.
-
-## browser
-
-This value will be set only if tests are running in the browser. If `browser` is enabled, but tests didn't run yet, this will be `undefined`. If you need to check if the project supports browser tests, use `project.isBrowserEnabled()` method.
-
-::: warning
-The browser API is even more experimental and doesn't follow SemVer. The browser API will be standardized separately from the rest of the APIs.
-:::
-
-## provide
-
-```ts
-function provide<T extends keyof ProvidedContext & string>(
-  key: T,
-  value: ProvidedContext[T],
-): void
-```
-
-A way to provide custom values to tests in addition to [`config.provide`](/config/provide) field. All values are validated with [`structuredClone`](https://developer.mozilla.org/en-US/docs/Web/API/Window/structuredClone) before they are stored, but the values on `providedContext` themselves are not cloned.
-
-::: code-group
-```ts [node.js]
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test')
-const project = vitest.projects.find(p => p.name === 'custom')
-project.provide('key', 'value')
-await vitest.start()
-```
-```ts [test.spec.js]
-import { inject } from 'vitest'
-const value = inject('key')
-```
-:::
-
-The values can be provided dynamically. Provided value in tests will be updated on their next run.
-
-::: tip
-This method is also available to [global setup files](/config/globalsetup) for cases where you cannot use the public API:
-
-```js
-export default function setup({ provide }) {
-  provide('wsPort', 3000)
-}
-```
-:::
-
-## getProvidedContext
-
-```ts
-function getProvidedContext(): ProvidedContext
-```
-
-This returns the context object. Every project also inherits the global context set by `vitest.provide`.
-
-```ts
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test')
-vitest.provide('global', true)
-const project = vitest.projects.find(p => p.name === 'custom')
-project.provide('key', 'value')
-
-// { global: true, key: 'value' }
-const context = project.getProvidedContext()
-```
-
-::: tip
-Project context values will always override root project's context.
-:::
-
-## createSpecification
-
-```ts
-function createSpecification(
-  moduleId: string,
-  locations?: number[],
-): TestSpecification
-```
-
-Create a [test specification](/api/advanced/test-specification) that can be used in [`vitest.runTestSpecifications`](/api/advanced/vitest#runtestspecifications). Specification scopes the test file to a specific `project` and test `locations` (optional). Test [locations](/api/advanced/test-case#location) are code lines where the test is defined in the source code. If locations are provided, Vitest will only run tests defined on those lines. Note that if [`testNamePattern`](/config/testnamepattern) is defined, then it will also be applied.
-
-```ts
-import { createVitest } from 'vitest/node'
-import { resolve } from 'node:path/posix'
-
-const vitest = await createVitest('test')
-const project = vitest.projects[0]
-const specification = project.createSpecification(
-  resolve('./example.test.ts'),
-  [20, 40], // optional test lines
-)
-await vitest.runTestSpecifications([specification])
-```
-
-::: warning
-`createSpecification` expects resolved [module ID](/api/advanced/test-specification#moduleid). It doesn't auto-resolve the file or check that it exists on the file system.
-
-Also note that `project.createSpecification` always returns a new instance.
-:::
-
-## isRootProject
-
-```ts
-function isRootProject(): boolean
-```
-
-Checks if the current project is the root project. You can also get the root project by calling [`vitest.getRootProject()`](/api/advanced/vitest#getrootproject).
-
-## globTestFiles
-
-```ts
-function globTestFiles(filters?: string[]): {
-  /**
-   * Test files that match the filters.
-   */
-  testFiles: string[]
-  /**
-   * Typecheck test files that match the filters. This will be empty unless `typecheck.enabled` is `true`.
-   */
-  typecheckTestFiles: string[]
-}
-```
-
-Globs all test files. This function returns an object with regular tests and typecheck tests.
-
-This method accepts `filters`. Filters can only a part of the file path, unlike in other methods on the [`Vitest`](/api/advanced/vitest) instance:
-
-```js
-project.globTestFiles(['foo']) // ✅
-project.globTestFiles(['basic/foo.js:10']) // ❌
-```
-
-::: tip
-Vitest uses [fast-glob](https://npmx.dev/package/fast-glob) to find test files. `test.dir`, `test.root`, `root` or `process.cwd()` define the `cwd` option.
-
-This method looks at several config options:
-
-- `test.include`, `test.exclude` to find regular test files
-- `test.includeSource`, `test.exclude` to find in-source tests
-- `test.typecheck.include`, `test.typecheck.exclude` to find typecheck tests
-:::
-
-## matchesTestGlob
-
-```ts
-function matchesTestGlob(
-  moduleId: string,
-  source?: () => string
-): boolean
-```
-
-This method checks if the file is a regular test file. It uses the same config properties that `globTestFiles` uses for validation.
-
-This method also accepts a second parameter, which is the source code. This is used to validate if the file is an in-source test. If you are calling this method several times for several projects it is recommended to read the file once and pass it down directly. If the file is not a test file, but matches the `includeSource` glob, Vitest will synchronously read the file unless the `source` is provided.
-
-```ts
-import { createVitest } from 'vitest/node'
-import { resolve } from 'node:path/posix'
-
-const vitest = await createVitest('test')
-const project = vitest.projects[0]
-
-project.matchesTestGlob(resolve('./basic.test.ts')) // true
-project.matchesTestGlob(resolve('./basic.ts')) // false
-project.matchesTestGlob(resolve('./basic.ts'), () => `
-if (import.meta.vitest) {
-  // ...
-}
-`) // true if `includeSource` is set
-```
-
-## import
-
-<!--@include: ./import-example.md-->
-
-Import a file using Vite module runner. The file will be transformed by Vite with provided project's config and executed in a separate context. Note that `moduleId` will be relative to the `config.root`.
-
-::: danger
-`project.import` reuses Vite's module graph, so importing the same module using a regular import will return a different module:
-
-```ts
-import * as staticExample from './example.js'
-const dynamicExample = await project.import('./example.js')
-
-dynamicExample !== staticExample // ✅
-```
-:::
-
-::: info
-Internally, Vitest uses this method to import global setups, custom coverage providers and custom reporters, meaning all of them share the same module graph as long as they belong to the same Vite server.
-:::
-
-## onTestsRerun
-
-```ts
-function onTestsRerun(cb: OnTestsRerunHandler): void
-```
-
-This is a shorthand for [`project.vitest.onTestsRerun`](/api/advanced/vitest#ontestsrerun). It accepts a callback that will be awaited when the tests have been scheduled to rerun (usually, due to a file change).
-
-```ts
-project.onTestsRerun((specs) => {
-  console.log(specs)
-})
-```
-
-## isBrowserEnabled
-
-```ts
-function isBrowserEnabled(): boolean
-```
-
-Returns `true` if this project runs tests in the browser.
-
-## close
-
-```ts
-function close(): Promise<void>
-```
-
-Closes the project and all associated resources. This can only be called once; the closing promise is cached until the server restarts. If the resources are needed again, create a new project.
-
-In detail, this method closes the Vite server, stops the typechecker service, closes the browser if it's running, deletes the temporary directory that holds the source code, and resets the provided context.

package/vendor/vitest-docs/api/advanced/test-specification.md

@@ -1,96 +0,0 @@
-# TestSpecification
-
-The `TestSpecification` class describes what module to run as a test and its parameters.
-
-You can only create a specification by calling [`createSpecification`](/api/advanced/test-project#createspecification) method on a test project:
-
-```ts
-const specification = project.createSpecification(
-  resolve('./example.test.ts'),
-  {
-    testLines: [20, 40],
-    testNamePattern: /hello world/,
-    testIds: ['1223128da3_0_0_0', '1223128da3_0_0'],
-    testTagsFilter: ['frontend and backend'],
-  } // optional test filters
-)
-```
-
-`createSpecification` expects resolved module identifier. It doesn't auto-resolve the file or check that it exists on the file system.
-
-## taskId
-
-[Test module's](/api/advanced/test-suite#id) identifier.
-
-## project
-
-This references the [`TestProject`](/api/advanced/test-project) that the test module belongs to.
-
-## moduleId
-
-The ID of the module in Vite's module graph. Usually, it's an absolute file path using posix separator:
-
-```ts
-'C:/Users/Documents/project/example.test.ts' // ✅
-'/Users/mac/project/example.test.ts' // ✅
-'C:\\Users\\Documents\\project\\example.test.ts' // ❌
-```
-
-## testModule
-
-Instance of [`TestModule`](/api/advanced/test-module) associated with the specification. If test wasn't queued yet, this will be `undefined`.
-
-## pool {#pool}
-
-The [`pool`](/config/pool) in which the test module will run.
-
-::: danger
-It's possible to have multiple pools in a single test project with [`typecheck.enabled`](/config/typecheck#typecheck-enabled). This means it's possible to have several specifications with the same `moduleId` but different `pool`. In later versions, the project will only support a single pool.
-:::
-
-## testLines
-
-This is an array of lines in the source code where the test files are defined. This field is defined only if the `createSpecification` method received an array.
-
-Note that if there is no test on at least one of the lines, the whole suite will fail. An example of a correct `testLines` configuration:
-
-::: code-group
-```ts [script.js]
-const specification = project.createSpecification(
-  resolve('./example.test.ts'),
-  [3, 8, 9],
-)
-```
-```ts:line-numbers{3,8,9} [example.test.js]
-import { test, describe } from 'vitest'
-
-test('verification works')
-
-describe('a group of tests', () => { // [!code error]
-  // ...
-
-  test('nested test')
-  test.skip('skipped test')
-})
-```
-:::
-
-## testNamePattern <Version>4.1.0</Version> {#testnamepattern}
-
-A regexp that matches the name of the test in this module. This value will override the global [`testNamePattern`](/config/testnamepattern) option if it's set.
-
-## testIds <Version>4.1.0</Version> {#testids}
-
-The ids of tasks inside of this specification to run.
-
-## testTagsFilter <Version>4.1.0</Version> {#testtagsfilter}
-
-The [tags filter](/guide/test-tags#syntax) that a test must pass in order to be included in the run. Multiple filters are treated as `AND`.
-
-## toJSON
-
-```ts
-function toJSON(): SerializedTestSpecification
-```
-
-`toJSON` generates a JSON-friendly object that can be consumed by the [Browser Mode](/guide/browser/) or [Vitest UI](/guide/ui).