Obszar roboczy (Workspace)

Przykładowy projekt

GitHub - Wypróbuj online

Vitest umożliwia definiowanie wielu konfiguracji projektów w ramach jednego procesu Vitest. Funkcja ta jest szczególnie przydatna w konfiguracjach monorepo, ale może być również używana do uruchamiania testów z różnymi ustawieniami, takimi jak resolve.alias, plugins lub test.browser i inne.

Definiowanie obszaru roboczego

Obszar roboczy musi zawierać plik vitest.workspace lub vitest.projects w swoim katalogu głównym (znajdującym się w tym samym folderze co główny plik konfiguracyjny lub katalog roboczy, jeśli taki plik nie istnieje). Vitest obsługuje rozszerzenia ts, js i json dla tego pliku.

NAZEWNICTWO

Zwróć uwagę, że ta funkcja nazywa się workspace, a nie workspaces (bez "s" na końcu).

Plik konfiguracyjny obszaru roboczego musi mieć domyślny eksport zawierający listę plików lub wzorców globowych odwołujących się do projektów. Na przykład, jeśli masz folder o nazwie packages, który zawiera twoje projekty, możesz zdefiniować obszar roboczy za pomocą następującego pliku konfiguracyjnego:

vitest.workspace.ts

export default ['packages/*'];

Vitest będzie traktować każdy folder w packages jako oddzielny projekt, nawet jeśli nie ma w nim pliku konfiguracyjnego. Od Vitest 2.1, jeśli ten wzorzec glob pasuje do jakiegokolwiek pliku, zostanie on uznany za konfigurację Vitest, nawet jeśli w jego nazwie nie ma vitest.

WARNING

Vitest nie traktuje głównego pliku vitest.config jako projektu obszaru roboczego, chyba że zostanie to wyraźnie określone w konfiguracji obszaru roboczego. W konsekwencji, główna konfiguracja będzie wpływać tylko na opcje globalne, takie jak reporters i coverage.

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 będzie zawierał tylko projekty z plikiem vitest.config, którego nazwa zawiera e2e lub unit przed rozszerzeniem.

Możesz również definiować projekty za pomocą konfiguracji w linii. Plik obszaru roboczego obsługuje obie składnie jednocześnie.

vitest.workspace.ts

import { defineWorkspace } from 'vitest/config';

// defineWorkspace zapewnia wygodne podpowiedzi typów
export default defineWorkspace([
  // pasuje do każdego folderu i pliku wewnątrz folderu `packages`
  '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 używania konfiguracji w linii
      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 nazwa nie zostanie podana w konfiguracji w linii, Vitest przypisze numer. Dla konfiguracji projektów zdefiniowanych przy użyciu wzorców globowych, Vitest domyślnie użyje właściwości "name" z najbliższego pliku package.json lub, jeśli taki plik nie istnieje, nazwy folderu.

Jeśli nie używasz konfiguracji w linii, możesz utworzyć mały plik JSON w katalogu głównym:

vitest.workspace.json

["packages/*"]

Projekty obszaru roboczego nie obsługują wszystkich właściwości konfiguracyjnych. Dla lepszego bezpieczeństwa typów, użyj metody defineProject zamiast defineConfig w plikach konfiguracyjnych projektu:

packages/a/vitest.config.ts

// @errors: 2769
import { defineProject } from 'vitest/config';

export default defineProject({
  test: {
    environment: 'jsdom',
    // "reporters" nie jest obsługiwane w konfiguracji projektu,
    // więc zostanie wyświetlony błąd
    reporters: ['json'],
  },
});

Uruchamianie testów

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

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

Teraz testy można uruchomić za pomocą narzędzia do zarządzania pakietami:

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

npm run test --project e2e

yarn

yarn test --project e2e

pnpm

pnpm run test --project e2e

bun

bun test --project e2e

TIP

Opcja CLI --project może być używana wielokrotnie do filtrowania wielu projektów:

npm

npm run test --project e2e --project unit

yarn

yarn test --project e2e --project unit

pnpm

pnpm run test --project e2e --project unit

bun

bun test --project e2e --project unit

Konfiguracja

Żadna z opcji konfiguracyjnych nie jest dziedziczona z głównego pliku konfiguracyjnego. 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',
    },
  })
);

Na poziomie defineWorkspace możesz użyć opcji extends, aby dziedziczyć z głównej konfiguracji. Wszystkie opcje zostaną połączone.

vitest.workspace.ts

import { defineWorkspace } from 'vitest/config';

export default defineWorkspace([
  {
    extends: './vitest.config.ts',
    test: {
      name: 'unit',
      include: ['**/*.unit.test.ts'],
    },
  },
  {
    extends: './vitest.config.ts',
    test: {
      name: 'integration',
      include: ['**/*.integration.test.ts'],
    },
  },
]);

Niektóre opcje konfiguracyjne nie są dozwolone w konfiguracji projektu. Najważniejsze z nich to:

• coverage: pokrycie kodu jest obliczane dla całego obszaru roboczego
• reporters: dostępni są tylko reporterzy na poziomie głównym
• resolveSnapshotPath: uwzględniana jest tylko ścieżka snapshotów na poziomie głównym
• wszystkie pozostałe opcje niezwiązane z uruchamianiem testów

TIP

Wszystkie opcje konfiguracyjne, które nie są obsługiwane w konfiguracji projektu, są oznaczone znakiem * w przewodniku "Konfiguracja".