Workspace

Vitest bietet integrierte Unterstützung für Monorepositories durch eine Workspace-Konfigurationsdatei. Du kannst einen Workspace erstellen, um die Setups deiner Projekte zu definieren und zu verwalten.

Definieren von Workspaces

Ein Workspace benötigt eine vitest.workspace- oder vitest.projects-Datei in seinem Root-Verzeichnis (im selben Ordner wie deine Hauptkonfigurationsdatei, falls vorhanden). Vitest unterstützt die Dateiendungen .ts, .js und .json für diese Datei.

Die Workspace-Konfigurationsdatei sollte einen Standardexport mit einer Liste von Dateien oder Glob-Mustern enthalten, die auf deine Projekte verweisen. Wenn du beispielsweise einen Ordner namens packages hast, der deine Projekte enthält, kannst du einen Workspace mit folgender Konfigurationsdatei definieren:

vitest.workspace.ts

export default ['packages/*'];

Vitest betrachtet jeden Ordner in packages als separates Projekt, selbst wenn er keine eigene Konfigurationsdatei enthält.

WARNING

Vitest betrachtet die Root-Konfiguration nicht als Workspace-Projekt (führt also keine in include angegebenen Tests aus), es sei denn, sie ist explizit in der Workspace-Konfiguration definiert.

Du kannst auch Projekte anhand ihrer Konfigurationsdateien referenzieren:

vitest.workspace.ts

export default ['packages/*/vitest.config.{e2e,unit}.ts'];

Dieses Muster bezieht sich nur auf Projekte mit einer vitest.config-Datei, deren Dateiname mit e2e oder unit endet.

WARNING

Wenn du Dateinamen mit einem Glob-Muster referenzierst, stelle sicher, dass deine Konfigurationsdatei mit vite.config oder vitest.config beginnt. Andernfalls wird Vitest sie ignorieren.

Du kannst Projekte auch mit Inline-Konfiguration definieren. Die Workspace-Datei unterstützt die gleichzeitige Verwendung beider Syntaxen.

vitest.workspace.ts

import { defineWorkspace } from 'vitest/config';

// defineWorkspace bietet eine verbesserte Developer Experience (DX) mit Typinformationen
export default defineWorkspace([
  'packages/*',
  {
    // mit "extends" können Konfigurationen zusammengeführt werden
    extends: './vite.config.js',
    test: {
      include: ['tests/**/*.{browser}.test.{ts,js}'],
      // es wird empfohlen, einen Namen zu definieren, wenn Inline-Konfigurationen verwendet werden
      name: 'happy-dom',
      environment: 'happy-dom',
    },
  },
  {
    test: {
      include: ['tests/**/*.{node}.test.{ts,js}'],
      name: 'node',
      environment: 'node',
    },
  },
]);

WARNING

Alle Projekte sollten eindeutige Namen haben. Andernfalls gibt Vitest einen Fehler aus. Wenn du keinen Namen innerhalb der Inline-Konfiguration definierst, weist Vitest automatisch eine Nummer zu. Wenn du keinen Namen innerhalb einer Projektkonfiguration definierst, die mit der Glob-Syntax definiert wurde, verwendet Vitest standardmäßig den Ordnernamen.

Wenn du keine Inline-Konfigurationen benötigst, kannst du einfach eine kleine JSON-Datei in deinem Stammverzeichnis erstellen:

vitest.workspace.json

["packages/*"]

Workspace-Projekte unterstützen nicht alle Konfigurationseinstellungen. Für eine bessere Typsicherheit innerhalb von Projektkonfigurationsdateien verwende die Methode defineProject anstelle der Methode defineConfig:

packages/a/vitest.config.ts

import { defineProject } from 'vitest/config';

export default defineProject({
  test: {
    environment: 'jsdom',
    // "reporters" wird in einer Projektkonfiguration nicht unterstützt,
    // daher wird ein Fehler angezeigt
    reporters: ['json'],
  },
});

Konfiguration

Keine der Konfigurationsoptionen wird von der Konfigurationsdatei im Root-Verzeichnis vererbt. Du kannst eine gemeinsam genutzte Konfigurationsdatei erstellen und diese explizit mit der Projektkonfiguration zusammenführen:

packages/a/vitest.config.ts

import { defineProject, mergeConfig } from 'vitest/config';
import configShared from '../vitest.shared.js';

export default mergeConfig(
  configShared,
  defineProject({
    test: {
      environment: 'jsdom',
    },
  })
);

Darüber hinaus sind einige Konfigurationsoptionen in einer Projektkonfiguration nicht zulässig. Insbesondere:

• coverage: Die Codeabdeckung wird für den gesamten Workspace durchgeführt.
• reporters: Es werden nur Reporter auf Root-Level unterstützt.
• resolveSnapshotPath: Es wird nur der Resolver auf Root-Level berücksichtigt.
• Alle anderen Optionen, die sich nicht auf den Test Runner auswirken.

TIP

Alle Konfigurationsoptionen, die innerhalb einer Projektkonfiguration nicht unterstützt werden, sind auf der Seite "Config" mit dem Zeichen * gekennzeichnet.

Coverage

Die Codeabdeckung für Workspace-Projekte funktioniert sofort nach der Einrichtung. Wenn du jedoch die Option all aktiviert hast und in einigen deiner Projekte ungewöhnliche Dateiendungen verwendest, benötigst du ein Plugin in deiner Root-Konfigurationsdatei, das diese Dateiendungen verarbeitet.

Wenn du beispielsweise ein Package hast, das Vue-Dateien verwendet und eine eigene Konfigurationsdatei besitzt, aber einige dieser Dateien nicht in deinen Tests importiert werden, schlägt die Coverage-Analyse fehl, da sie versucht, die Verwendung nicht verwendeter Dateien anhand der Root-Konfiguration anstelle der Projektkonfiguration zu analysieren.