Description

In preparation for the public API. Previously TestProject was a prototype for the public API, but it was hard to work with internally because it was too restrictive. In this PR I decided to merge them together and introduce a sort of convention:

• All public methods starting with _ and marked with @internal are internal and not part of the public API. They are striped from the public interface during bundling
• All those methods were renamed, and the previous names stayed with a @deprecated tag - they will be removed in V3 (we can remove them right away, they shouldn't have been used at all)
• The WorkspaceProject was renamed to TestProject - all properties from the test project are now present there. The file was also renamed from workspace to project
• Added a getter to throw an error if .vite or .config was accessed before the project was initialised. This should catch unexpected errors with a nice stack trace

The public test project API now looks like this (excluding deprecated and private APIs):

export interface TestProject {
  readonly name: string
  readonly serializedConfig: SerializedConfig
  readonly globalConfig: ResolvedConfig
  readonly vitest: Vitest
  readonly config: ResolvedConfig // project config
  readonly vite: ViteDevServer
  browser?: BrowserServer
  
  provide(key: string | symbol, value: unknown): void
  getProvidedContext(): ProvidedContext
  createSpecification(moduleId: string, pool?: string): TestSpecification
  isRootProject(): boolean
  globTestFiles(filters?: string[]): Promise<{ testFiles, typecheckTestFiles }>
  matchesTestGlob(filepath: string, code?: string): boolean
  close(): Promise<void>
}

TODO:

• Better docs

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.