Przestrzeń robocza

Przykładowy projekt

GitHub - Przetestuj online

Vitest oferuje wbudowane wsparcie dla monorepo za pomocą pliku konfiguracyjnego przestrzeni roboczej. Możesz utworzyć przestrzeń roboczą, aby zdefiniować konfiguracje dla poszczególnych projektów.

Definiowanie przestrzeni roboczej

Przestrzeń robocza powinna zawierać plik vitest.workspace lub vitest.projects w katalogu głównym projektu (w tym samym folderze, co plik konfiguracyjny Vitest, jeśli go używasz). Vitest obsługuje rozszerzenia .ts, .js i .json dla tego pliku.

Plik konfiguracyjny przestrzeni roboczej powinien eksportować domyślnie tablicę plików lub wzorców glob, które wskazują na twoje projekty. Na przykład, jeśli masz folder o nazwie packages, który zawiera twoje projekty, możesz zdefiniować przestrzeń roboczą za pomocą następującego pliku konfiguracyjnego:

vitest.workspace.ts

export default ['packages/*'];

Vitest potraktuje każdy folder w packages jako osobny projekt, nawet jeśli w danym folderze nie ma pliku konfiguracyjnego Vitest.

WARNING

Vitest nie uzna konfiguracji na poziomie głównym za projekt przestrzeni roboczej (więc nie uruchomi testów określonych w include), chyba że zostanie ona jawnie uwzględniona w konfiguracji przestrzeni roboczej.

Możesz również odwoływać się do projektów za pomocą ich plików konfiguracyjnych:

vitest.workspace.ts

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

Ten wzorzec uwzględni tylko projekty, których plik vitest.config zawiera segmenty e2e i unit przed rozszerzeniem pliku.

WARNING

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

Możesz również definiować projekty za pomocą konfiguracji wbudowanych (inline). Plik przestrzeni roboczej obsługuje łączenie obu składni.

vitest.workspace.ts

import { defineWorkspace } from 'vitest/config';

// defineWorkspace zapewnia wygodne podpowiedzi typów
export default defineWorkspace([
  'packages/*',
  {
    // dodaj "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 wbudowanych
      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 wbudowanej, Vitest 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 wbudowanych, możesz po prostu utworzyć mały plik JSON w katalogu głównym:

vitest.workspace.json

["packages/*"]

Projekty przestrzeni roboczej nie obsługują wszystkich właściwości 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 zostanie wyświetlony błąd
    reporters: ['json'],
  },
});

Uruchamianie testów

Aby uruchomić testy w przestrzeni roboczej, zdefiniuj skrypt w głównym pliku package.json:

{
  "scripts": {
    "test": "vitest"
  }
}

Teraz testy można uruchomić za pomocą menedżera pakietów:

npm

npm run test

yarn

yarn test

pnpm

pnpm run test

bun

bun test

Jeśli chcesz uruchomić testy tylko w jednym projekcie, użyj opcji CLI --project:

npm run test --project e2e

TIP

Opcja CLI --project może być używana wielokrotnie, aby odfiltrować kilka projektów:

npm run test --project e2e --project unit

Konfiguracja

Żadne opcje konfiguracyjne nie są dziedziczone z pliku konfiguracyjnego na poziomie głównym. Możesz utworzyć współdzielony plik konfiguracyjny i samodzielnie połączyć go z konfiguracją 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łej przestrzeni roboczej
• reporters: obsługiwane są tylko reportery na poziomie głównym
• resolveSnapshotPath: uwzględniany jest tylko resolver na poziomie głównym
• wszystkie inne opcje, które nie wpływają na uruchamianie testów

TIP

Wszystkie opcje konfiguracyjne, które nie są obsługiwane w konfiguracji projektu, mają obok siebie ikonę * na stronie "Config".

Pokrycie kodu

Pokrycie kodu dla projektów przestrzeni roboczej działa od razu. Jeśli masz włączoną opcję all i używasz niestandardowych rozszerzeń plików w niektórych projektach, będziesz potrzebować wtyczki, która obsługuje to rozszerzenie w głównym pliku konfiguracyjnym.

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