@vitest-agent/mcp 1.0.1 → 1.2.0

package/public/vendor/vitest-docs/guide/advanced/index.md

@@ -1,147 +0,0 @@
-# Getting Started <Badge type="danger">advanced</Badge> {#getting-started}
-
-::: warning
-This guide lists advanced APIs to run tests via a Node.js script. If you just want to [run tests](/guide/), you probably don't need this. It is primarily used by library authors.
-:::
-
-You can import any method from the `vitest/node` entry-point.
-
-## startVitest
-
-```ts
-function startVitest(
-  mode: VitestRunMode,
-  cliFilters: string[] = [],
-  options: CliOptions = {},
-  viteOverrides?: ViteUserConfig,
-  vitestOptions?: VitestOptions,
-): Promise<Vitest>
-```
-
-You can start running Vitest tests using its Node API:
-
-```js
-import { startVitest } from 'vitest/node'
-
-const vitest = await startVitest('test')
-
-await vitest.close()
-```
-
-`startVitest` function returns [`Vitest`](/api/advanced/vitest) instance if tests can be started.
-
-If watch mode is not enabled, Vitest will call `close` method automatically.
-
-If watch mode is enabled and the terminal supports TTY, Vitest will register console shortcuts.
-
-You can pass down a list of filters as a second argument. Vitest will run only tests that contain at least one of the passed-down strings in their file path.
-
-Additionally, you can use the third argument to pass in CLI arguments, which will override any test config options. Alternatively, you can pass in the complete Vite config as the fourth argument, which will take precedence over any other user-defined options.
-
-After running the tests, you can get the results from the [`state.getTestModules`](/api/advanced/test-module) API:
-
-```ts
-import type { TestModule } from 'vitest/node'
-
-const vitest = await startVitest('test')
-
-console.log(vitest.state.getTestModules()) // [TestModule]
-```
-
-::: tip
-The ["Running Tests"](/guide/advanced/tests#startvitest) guide has a usage example.
-:::
-
-## createVitest
-
-```ts
-function createVitest(
-  mode: VitestRunMode,
-  options: CliOptions,
-  viteOverrides: ViteUserConfig = {},
-  vitestOptions: VitestOptions = {},
-): Promise<Vitest>
-```
-
-You can create Vitest instance by using `createVitest` function. It returns the same [`Vitest`](/api/advanced/vitest) instance as `startVitest`, but it doesn't start tests and doesn't validate installed packages.
-
-```js
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test', {
-  watch: false,
-})
-```
-
-::: tip
-The ["Running Tests"](/guide/advanced/tests#createvitest) guide has a usage example.
-:::
-
-## resolveConfig
-
-```ts
-function resolveConfig(
-  options: UserConfig = {},
-  viteOverrides: ViteUserConfig = {},
-): Promise<{
-  vitestConfig: ResolvedConfig
-  viteConfig: ResolvedViteConfig
-}>
-```
-
-This method resolves the config with custom parameters. If no parameters are given, the `root` will be `process.cwd()`.
-
-```ts
-import { resolveConfig } from 'vitest/node'
-
-// vitestConfig only has resolved "test" properties
-const { vitestConfig, viteConfig } = await resolveConfig({
-  mode: 'custom',
-  configFile: false,
-  resolve: {
-    conditions: ['custom']
-  },
-  test: {
-    setupFiles: ['/my-setup-file.js'],
-    pool: 'threads',
-  },
-})
-```
-
-::: info
-Due to how Vite's `createServer` works, Vitest has to resolve the config during the plugin's `configResolve` hook. Therefore, this method is not actually used internally and is exposed exclusively as a public API.
-
-If you pass down the config to the `startVitest` or `createVitest` APIs, Vitest will still resolve the config again.
-:::
-
-::: warning
-The `resolveConfig` doesn't resolve `projects`. To resolve projects configs, Vitest needs an established Vite server.
-
-Also note that `viteConfig.test` will not be fully resolved. If you need Vitest config, use `vitestConfig` instead.
-:::
-
-## parseCLI
-
-```ts
-function parseCLI(argv: string | string[], config: CliParseOptions = {}): {
-  filter: string[]
-  options: CliOptions
-}
-```
-
-You can use this method to parse CLI arguments. It accepts a string (where arguments are split by a single space) or a strings array of CLI arguments in the same format that Vitest CLI uses. It returns a filter and `options` that you can later pass down to `createVitest` or `startVitest` methods.
-
-```ts
-import { parseCLI } from 'vitest/node'
-
-const result = parseCLI('vitest ./files.ts --coverage --browser=chrome')
-
-result.options
-// {
-//   coverage: { enabled: true },
-//   browser: { name: 'chrome', enabled: true }
-// }
-
-result.filter
-// ['./files.ts']
-```

package/public/vendor/vitest-docs/guide/advanced/pool.md

@@ -1,148 +0,0 @@
-# Custom Pool <Badge type="danger">advanced</Badge> {#custom-pool}
-
-::: warning
-This is an advanced, experimental and very low-level API. If you just want to [run tests](/guide/), you probably don't need this. It is primarily used by library authors.
-:::
-
-Vitest runs tests in a pool. By default, there are several pool runners:
-
-- `threads` to run tests using `node:worker_threads` (isolation is provided with a new worker context)
-- `forks` to run tests using `node:child_process` (isolation is provided with a new `child_process.fork` process)
-- `vmThreads` to run tests using `node:worker_threads` (but isolation is provided with `vm` module instead of a new worker context)
-- `browser` to run tests using browser providers
-- `typescript` to run typechecking on tests
-
-::: tip
-See [`vitest-pool-example`](https://npmx.dev/package/vitest-pool-example) for example of a custom pool runner implementation.
-:::
-
-## Usage
-
-You can provide your own pool runner by a function that returns `PoolRunnerInitializer`.
-
-```ts [vitest.config.ts]
-import { defineConfig } from 'vitest/config'
-import customPool from './my-custom-pool.ts'
-
-export default defineConfig({
-  test: {
-    // will run every file with a custom pool by default
-    pool: customPool({
-      customProperty: true,
-    })
-  },
-})
-```
-
-If you need to run tests in different pools, use the [`projects`](/guide/projects) feature:
-
-```ts [vitest.config.ts]
-import customPool from './my-custom-pool.ts'
-
-export default defineConfig({
-  test: {
-    projects: [
-      {
-        extends: true,
-        test: {
-          pool: 'threads',
-        },
-      },
-      {
-        extends: true,
-        test: {
-          pool: customPool({
-            customProperty: true,
-          })
-        }
-      }
-    ],
-  },
-})
-```
-
-## API
-
-The `pool` option accepts a `PoolRunnerInitializer` that can be used for custom pool runners. The `name` property should indicate name of the custom pool runner. It should be identical with your worker's `name` property.
-
-```ts [my-custom-pool.ts]
-import type { PoolRunnerInitializer } from 'vitest/node'
-
-export function customPool(customOptions: CustomOptions): PoolRunnerInitializer {
-  return {
-    name: 'custom-pool',
-    createPoolWorker: options => new CustomPoolWorker(options, customOptions),
-  }
-}
-```
-
-In your `CustomPoolWorker` you need to define all required methods:
-
-```ts [my-custom-pool.ts]
-import type { PoolOptions, PoolWorker, WorkerRequest } from 'vitest/node'
-
-class CustomPoolWorker implements PoolWorker {
-  name = 'custom-pool'
-  private customOptions: CustomOptions
-
-  constructor(options: PoolOptions, customOptions: CustomOptions) {
-    this.customOptions = customOptions
-  }
-
-  send(message: WorkerRequest): void {
-    // Provide way to send your worker a message
-  }
-
-  on(event: string, callback: (arg: any) => void): void {
-    // Provide way to listen to your workers events, e.g. message, error, exit
-  }
-
-  off(event: string, callback: (arg: any) => void): void {
-    // Provide way to unsubscribe `on` listeners
-  }
-
-  async start() {
-    // do something when the worker is started
-  }
-
-  async stop() {
-    // cleanup the state
-  }
-
-  deserialize(data) {
-    return data
-  }
-}
-```
-
-Your `CustomPoolRunner` will be controlling how your custom test runner worker life cycles and communication channel works. For example, your `CustomPoolRunner` could launch a `node:worker_threads` `Worker`, and provide communication via `Worker.postMessage` and `parentPort`.
-
-In your worker file, you can import helper utilities from `vitest/worker`:
-
-```ts [my-worker.ts]
-import { init, runBaseTests, setupEnvironment } from 'vitest/worker'
-
-init({
-  post: (response) => {
-    // Provide way to send this message to CustomPoolRunner's onWorker as message event
-  },
-  on: (callback) => {
-    // Provide a way to listen CustomPoolRunner's "postMessage" calls
-  },
-  off: (callback) => {
-    // Optional, provide a way to remove listeners added by "on" calls
-  },
-  teardown: () => {
-    // Optional, provide a way to teardown worker, e.g. unsubscribe all the `on` listeners
-  },
-  serialize: (value) => {
-    // Optional, provide custom serializer for `post` calls
-  },
-  deserialize: (value) => {
-    // Optional, provide custom deserializer for `on` callbacks
-  },
-  runTests: (state, traces) => runBaseTests('run', state, traces),
-  collectTests: (state, traces) => runBaseTests('collect', state, traces),
-  setup: setupEnvironment,
-})
-```

package/public/vendor/vitest-docs/guide/advanced/reporters.md

@@ -1,93 +0,0 @@
-# Extending Reporters <Badge type="danger">advanced</Badge> {#extending-reporters}
-
-::: warning
-This is an advanced API. If you just want to configure built-in reporters, read the ["Reporters"](/guide/reporters) guide.
-:::
-
-You can import reporters from `vitest/node` and extend them to create your custom reporters.
-
-## Extending Built-in Reporters
-
-In general, you don't need to create your reporter from scratch. `vitest` comes with several default reporting programs that you can extend.
-
-```ts
-import { DefaultReporter } from 'vitest/node'
-
-export default class MyDefaultReporter extends DefaultReporter {
-  // do something
-}
-```
-
-::: warning
-However, note that exposed reports are not considered stable and can change the shape of their API within a minor version.
-:::
-
-Of course, you can create your reporter from scratch. Just implement the [`Reporter`](/api/advanced/reporters) interface:
-
-And here is an example of a custom reporter:
-
-```ts [custom-reporter.js]
-import type { Reporter } from 'vitest/node'
-
-export default class CustomReporter implements Reporter {
-  onTestModuleCollected(testModule) {
-    console.log(testModule.moduleId, 'is finished')
-
-    for (const test of testModule.children.allTests()) {
-      console.log(test.name, test.result().state)
-    }
-  }
-}
-```
-
-Then you can use your custom reporter in the `vitest.config.ts` file:
-
-```ts [vitest.config.ts]
-import { defineConfig } from 'vitest/config'
-import CustomReporter from './custom-reporter.js'
-
-export default defineConfig({
-  test: {
-    reporters: [new CustomReporter()],
-  },
-})
-```
-
-## Reported Tasks
-
-Reported [events](/api/advanced/reporters) receive tasks for [tests](/api/advanced/test-case), [suites](/api/advanced/test-suite) and [modules](/api/advanced/test-module):
-
-```ts twoslash
-import type { Reporter, TestModule } from 'vitest/node'
-
-class MyReporter implements Reporter {
-  onTestRunEnd(testModules: ReadonlyArray<TestModule>) {
-    for (const testModule of testModules) {
-      for (const task of testModule.children) {
-        //                          ^?
-        console.log('test run end', task.type, task.fullName)
-      }
-    }
-  }
-}
-```
-
-## Exported Reporters
-
-`vitest` comes with a few [built-in reporters](/guide/reporters) that you can use out of the box.
-
-### Built-in reporters:
-
-1. `DefaultReporter`
-2. `DotReporter`
-3. `JsonReporter`
-4. `VerboseReporter`
-5. `TapReporter`
-6. `JUnitReporter`
-7. `TapFlatReporter`
-8. `HangingProcessReporter`
-9. `TreeReporter`
-
-### Interface reporters:
-
-1. `Reporter`

package/public/vendor/vitest-docs/guide/advanced/tests.md

@@ -1,125 +0,0 @@
-# Running Tests <Badge type="danger">advanced</Badge> {#running-tests}
-
-::: warning
-This guide explains how to use the advanced API to run tests via a Node.js script. If you just want to [run tests](/guide/), you probably don't need this. It is primarily used by library authors.
-:::
-
-Vitest exposes two methods to initiate Vitest:
-
-- `startVitest` initiates Vitest, validates the packages are installed and runs tests immediately
-- `createVitest` only initiates Vitest and doesn't run any tests
-
-## `startVitest`
-
-```ts
-import { startVitest } from 'vitest/node'
-
-const vitest = await startVitest(
-  'test',
-  [], // CLI filters
-  {}, // override test config
-  {}, // override Vite config
-  {}, // custom Vitest options
-)
-const testModules = vitest.state.getTestModules()
-for (const testModule of testModules) {
-  console.log(testModule.moduleId, testModule.ok() ? 'passed' : 'failed')
-}
-```
-
-## `createVitest`
-
-Creates a [Vitest](/api/advanced/vitest) instances without running tests.
-
-`createVitest` method doesn't validate that required packages are installed. It also doesn't respect `config.standalone` or `config.mergeReports`. Vitest won't be closed automatically even if `watch` is disabled.
-
-```ts
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest(
-  'test',
-  {}, // override test config
-  {}, // override Vite config
-  {}, // custom Vitest options
-)
-
-// called when `vitest.cancelCurrentRun()` is invoked
-vitest.onCancel(() => {})
-// called during `vitest.close()` call
-vitest.onClose(() => {})
-// called when Vitest reruns test files
-vitest.onTestsRerun((files) => {})
-
-try {
-  // this will set process.exitCode to 1 if tests failed,
-  // and won't close the process automatically
-  await vitest.start(['my-filter'])
-}
-catch (err) {
-  // this can throw
-  // "FilesNotFoundError" if no files were found
-  // "GitNotFoundError" with `--changed` and repository is not initialized
-}
-finally {
-  await vitest.close()
-}
-```
-
-If you intend to keep the `Vitest` instance, make sure to at least call [`init`](/api/advanced/vitest#init). This will initialise reporters and the coverage provider, but won't run any tests. It is also recommended to enable the `watch` mode even if you don't intend to use the Vitest watcher, but want to keep the instance running. Vitest relies on this flag for some of its features to work correctly in a continuous process.
-
-After reporters are initialised, use [`runTestSpecifications`](/api/advanced/vitest#runtestspecifications) or [`rerunTestSpecifications`](/api/advanced/vitest#reruntestspecifications) to run tests if manual run is required:
-
-```ts
-watcher.on('change', async (file) => {
-  const specifications = vitest.getModuleSpecifications(file)
-  if (specifications.length) {
-    vitest.invalidateFile(file)
-    // you can use runTestSpecifications if "reporter.onWatcher*" hooks
-    // should not be invoked
-    await vitest.rerunTestSpecifications(specifications)
-  }
-})
-```
-
-::: warning
-The example above shows a potential use-case if you disable the default watcher behaviour. By default, Vitest already reruns tests if files change.
-
-Also note that `getModuleSpecifications` will not resolve test files unless they were already processed by `globTestSpecifications`. If the file was just created, use `project.matchesGlobPattern` instead:
-
-```ts
-watcher.on('add', async (file) => {
-  const specifications = []
-  for (const project of vitest.projects) {
-    if (project.matchesGlobPattern(file)) {
-      specifications.push(project.createSpecification(file))
-    }
-  }
-
-  if (specifications.length) {
-    await vitest.rerunTestSpecifications(specifications)
-  }
-})
-```
-:::
-
-In cases where you need to disable the watcher, you can pass down `server.watch: null` since Vite 5.3 or `server.watch: { ignored: ['*/*'] }` to a Vite config:
-
-```ts
-await createVitest(
-  'test',
-  {},
-  {
-    plugins: [
-      {
-        name: 'stop-watcher',
-        async configureServer(server) {
-          await server.watcher.close()
-        }
-      }
-    ],
-    server: {
-      watch: null,
-    },
-  }
-)
-```