Espace de travail

Exemple de projet

GitHub - Essayer en ligne

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

Définition d'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/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 qui contient vos projets, vous pouvez définir un espace de travail avec la configuration suivante :

vitest.workspace.ts

export default ['packages/*'];

Vitest considérera chaque dossier du répertoire packages comme un projet distinct, même s'il n'y a pas de fichier de configuration dans ce dossier.

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 spécifié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 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 en ligne. 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 bonne expérience de développement (DX) pour la saisie semi-automatique
export default defineWorkspace([
  'packages/*',
  {
    // ajoutez "extends" pour fusionner deux configurations ensemble
    extends: './vite.config.js',
    test: {
      include: ['tests/**/*.{browser}.test.{ts,js}'],
      // il est recommandé de définir un nom lors de l'utilisation de configurations en ligne
      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 en ligne, Vitest attribuera un numéro. 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 en ligne, vous pouvez simplement créer un petit fichier JSON à la racine de votre projet :

vitest.workspace.json

["packages/*"]

Les projets d'espace de travail ne prennent pas en charge l'ensemble des options de configuration. Pour une meilleure sécurité de type, utilisez la méthode defineProject plutôt que 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'],
  },
});

Exécution des tests

Pour exécuter les tests dans l'espace de travail, définissez un script dans votre package.json racine :

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

Les tests peuvent alors être exécutés à l'aide de votre gestionnaire de paquets :

npm

npm run test

yarn

yarn test

pnpm

pnpm run test

bun

bun test

Si vous devez exécuter les tests uniquement dans un seul projet, utilisez l'option CLI --project :

npm run test --project e2e

TIP

L'option CLI --project peut être utilisée plusieurs fois pour filtrer plusieurs projets :

npm run test --project e2e --project unit

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 du 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. En particulier :

• coverage : la couverture est effectué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 signe * sur la page "Config".

Couverture

La couverture des projets d'espace de travail fonctionne par défaut. Toutefois, si vous avez l'option all activée et que vous utilisez des extensions non conventionnelles dans certains de vos projets, vous devrez avoir un plugin qui gère cette extension dans votre fichier de configuration racine.

Par exemple, si vous avez un package qui utilise des fichiers Vue et qu'il a son propre fichier de configuration, mais que certains des fichiers ne sont pas importés dans vos tests, la couverture échouera lors de l'analyse de l'utilisation des fichiers inutilisés, car elle se basera sur la configuration racine et non sur celle du projet.