Workspace

Vitest prend en charge nativement les monorepositories grâce à un fichier de configuration d'espace de travail. Vous pouvez créer un espace de travail pour définir les configurations de vos projets.

Définir un espace de travail

Un espace de travail doit avoir un fichier vitest.workspace ou vitest.projects à sa racine (dans le même dossier que votre fichier de configuration principal, si vous en avez un). Vitest prend en charge les extensions .ts, .js et .json pour ce fichier.

Le fichier de configuration de l'espace de travail doit exporter par défaut une liste de fichiers ou de motifs globaux qui référencent vos projets. Par exemple, si vous avez un dossier nommé packages contenant vos projets, vous pouvez définir un espace de travail avec le fichier de configuration suivant :

vitest.workspace.ts

export default ['packages/*'];

Vitest considérera chaque dossier du répertoire packages comme un projet distinct, même s'il ne contient pas de fichier de configuration.

WARNING

Vitest ne considérera pas la configuration racine comme un projet d'espace de travail (et n'exécutera donc pas les tests spécifiés dans include) à moins qu'elle ne soit explicitement mentionnée dans cette configuration.

Vous pouvez également référencer des projets en utilisant leurs fichiers de configuration :

vitest.workspace.ts

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

Ce motif n'inclura que les projets dont le fichier vitest.config contient e2e et unit avant l'extension.

WARNING

Si vous référencez des fichiers de configuration avec un motif glob, assurez-vous que leur nom commence par vite.config ou vitest.config. Sinon, Vitest les ignorera.

Vous pouvez également définir des projets avec une configuration inline. Le fichier d'espace de travail prend en charge l'utilisation simultanée des deux syntaxes.

vitest.workspace.ts

import { defineWorkspace } from 'vitest/config';

// defineWorkspace offre une expérience d'autocomplétion agréable
export default defineWorkspace([
  'packages/*',
  {
    // ajoutez "extends" pour fusionner deux configurations
    extends: './vite.config.js',
    test: {
      include: ['tests/**/*.{browser}.test.{ts,js}'],
      // il est recommandé de définir un nom lorsque vous utilisez des configurations inline
      name: 'happy-dom',
      environment: 'happy-dom',
    },
  },
  {
    test: {
      include: ['tests/**/*.{node}.test.{ts,js}'],
      name: 'node',
      environment: 'node',
    },
  },
]);

WARNING

Tous les projets doivent avoir des noms uniques. Sinon, Vitest lèvera une erreur. Si vous ne fournissez pas de nom dans la configuration inline, Vitest attribuera un numéro automatiquement. Si vous ne fournissez pas de nom dans une configuration de projet définie avec la syntaxe glob, Vitest utilisera le nom du répertoire par défaut.

Si vous n'utilisez pas de configurations inline, vous pouvez simplement créer un fichier JSON minimal dans votre répertoire racine :

vitest.workspace.json

["packages/*"]

Les projets d'espace de travail ne prennent pas en charge toutes les options de configuration. Pour une meilleure sécurité de typage, utilisez la méthode defineProject au lieu de defineConfig dans les fichiers de configuration de projet :

packages/a/vitest.config.ts

import { defineProject } from 'vitest/config';

export default defineProject({
  test: {
    environment: 'jsdom',
    // "reporters" n'est pas pris en charge dans une configuration de projet,
    // cela générera donc une erreur
    reporters: ['json'],
  },
});

Configuration

Aucune des options de configuration n'est héritée du fichier de configuration racine. Vous pouvez créer un fichier de configuration partagé et le fusionner vous-même avec la configuration de chaque projet :

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

De plus, certaines options de configuration ne sont pas autorisées dans une configuration de projet. Notamment :

• coverage : la couverture est gérée pour l'ensemble de l'espace de travail.
• reporters : seuls les reporters définis au niveau racine sont pris en charge.
• resolveSnapshotPath : seul le résolveur défini au niveau racine est pris en compte.
• toutes les autres options qui n'affectent pas les exécuteurs de tests.

TIP

Toutes les options de configuration qui ne sont pas prises en charge dans une configuration de projet sont signalées par le symbole * sur la page "Config".

Couverture

La couverture des projets d'espace de travail fonctionne sans configuration supplémentaire. Cependant, si vous avez l'option all activée et que vous utilisez des extensions de fichiers non conventionnelles dans certains de vos projets, vous devrez avoir un plugin qui gère ces extensions dans votre fichier de configuration racine.

Par exemple, si vous avez un package qui utilise des fichiers Vue et qu'il possède son propre fichier de configuration, mais que certains de ces fichiers ne sont pas importés dans vos tests, la couverture échouera en essayant d'analyser l'utilisation des fichiers non utilisés. Cela est dû au fait que l'analyse se base sur la configuration racine plutôt que sur celle du projet.