Obszar roboczy

Vitest zapewnia wbudowane wsparcie dla monorepozytoriów poprzez plik konfiguracyjny obszaru roboczego. Możesz utworzyć obszar roboczy, aby zdefiniować konfiguracje dla poszczególnych projektów w repozytorium.

Definiowanie obszaru roboczego

Plik vitest.workspace lub vitest.projects powinien znajdować się w katalogu głównym obszaru roboczego (w tym samym folderze co plik konfiguracyjny Vitest, jeśli istnieje). Vitest obsługuje rozszerzenia ts/js/json dla tego pliku.

Plik konfiguracyjny obszaru roboczego powinien eksportować domyślnie listę plików lub wzorców glob, które wskazują na twoje projekty. Na przykład, jeśli masz folder z projektami o nazwie packages, możesz zdefiniować obszar roboczy za pomocą następującego pliku konfiguracyjnego:

vitest.workspace.ts

export default ['packages/*'];

Vitest potraktuje każdy folder w packages jako oddzielny projekt, nawet jeśli nie zawiera on pliku konfiguracyjnego Vitest.

WARNING

Vitest nie uzna konfiguracji na poziomie głównym za projekt obszaru roboczego (więc nie uruchomi testów określonych w include), chyba że zostanie to wyraźnie określone w konfiguracji obszaru roboczego.

Możesz również odwoływać się do projektów, wskazując na ich pliki konfiguracyjne:

vitest.workspace.ts

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

Ten wzorzec uwzględni tylko projekty, które posiadają plik vitest.config z sufiksem e2e lub unit przed rozszerzeniem pliku.

WARNING

Jeśli odwołujesz się do plików konfiguracyjnych za pomocą wzorca glob, upewnij się, że nazwa pliku konfiguracyjnego zaczyna się od vite.config lub vitest.config. W przeciwnym razie Vitest go zignoruje.

Możesz również definiować projekty, używając konfiguracji bezpośrednio w pliku obszaru roboczego (inline config). Plik obszaru roboczego obsługuje łączenie obu składni.

vitest.workspace.ts

import { defineWorkspace } from 'vitest/config';

// defineWorkspace zapewnia wygodne podpowiedzi typów (DX)
export default defineWorkspace([
  'packages/*',
  {
    // Użyj "extends", aby połączyć dwie konfiguracje.
    extends: './vite.config.js',
    test: {
      include: ['tests/**/*.{browser}.test.{ts,js}'],
      // zaleca się zdefiniowanie nazwy podczas korzystania z konfiguracji inline
      name: 'happy-dom',
      environment: 'happy-dom',
    },
  },
  {
    test: {
      include: ['tests/**/*.{node}.test.{ts,js}'],
      name: 'node',
      environment: 'node',
    },
  },
]);

WARNING

Wszystkie projekty muszą mieć unikalne nazwy. W przeciwnym razie Vitest zgłosi błąd. Jeśli nie podasz nazwy w konfiguracji inline, Vitest automatycznie przypisze numer. Jeśli nie podasz nazwy w konfiguracji projektu zdefiniowanej za pomocą składni glob, Vitest domyślnie użyje nazwy katalogu.

Jeśli nie korzystasz z konfiguracji inline, możesz po prostu utworzyć mały plik JSON w katalogu głównym:

vitest.workspace.json

["packages/*"]

Projekty w obszarze roboczym nie obsługują wszystkich opcji konfiguracyjnych. Aby zapewnić lepszą kontrolę typów, użyj metody defineProject zamiast defineConfig w plikach konfiguracyjnych projektu:

packages/a/vitest.config.ts

import { defineProject } from 'vitest/config';

export default defineProject({
  test: {
    environment: 'jsdom',
    // "reporters" nie jest obsługiwany w konfiguracji projektu,
    // więc pokaże błąd
    reporters: ['json'],
  },
});

Konfiguracja

Żadna z opcji konfiguracyjnych z pliku konfiguracyjnego na poziomie głównym nie jest dziedziczona przez projekty w obszarze roboczym. Możesz utworzyć współdzielony plik konfiguracyjny i samodzielnie połączyć go z konfiguracją każdego projektu:

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',
    },
  })
);

Ponadto, niektóre opcje konfiguracyjne są niedozwolone w konfiguracji projektu. W szczególności:

• coverage: pokrycie kodu jest wykonywane dla całego obszaru roboczego
• reporters: obsługiwane są tylko reportery na poziomie głównym
• resolveSnapshotPath: respektowany jest tylko resolver na poziomie głównym
• wszystkie inne opcje, które nie mają wpływu na uruchamiacze testów

TIP

Wszystkie opcje konfiguracyjne, które nie są obsługiwane w konfiguracji projektu, są oznaczone symbolem * na stronie "Config".

Pokrycie kodu

Pokrycie kodu dla projektów w obszarze roboczym działa domyślnie. Jeśli masz włączoną opcję all i używasz niestandardowych rozszerzeń plików w niektórych projektach, będziesz potrzebować wtyczki obsługującej to rozszerzenie w głównym pliku konfiguracyjnym.

Na przykład, jeśli masz pakiet, który używa plików Vue i ma własny plik konfiguracyjny, ale niektóre pliki Vue nie są importowane w testach, analiza pokrycia kodu może zakończyć się niepowodzeniem. Dzieje się tak, ponieważ Vitest próbuje przeanalizować nieużywane pliki, opierając się na konfiguracji głównej, a nie na konfiguracji projektu.