Espace de travail

Exemple de projet

GitHub - Essayer en ligne

Vitest permet de définir plusieurs configurations de projet au sein d'un seul processus Vitest. Cette fonctionnalité est particulièrement utile pour les configurations de monorepo, mais peut également être utilisée pour exécuter des tests avec différentes configurations, telles que resolve.alias, plugins, ou test.browser, entre autres.

Définir un espace de travail

Un espace de travail doit inclure un fichier vitest.workspace ou vitest.projects dans son répertoire racine (situé dans le même dossier que votre fichier de configuration racine, ou dans votre répertoire de travail si ce fichier n'existe pas). Vitest prend en charge les extensions ts, js et json pour ce fichier.

DÉNOMINATION

Veuillez noter que cette fonctionnalité est nommée workspace, et non workspaces (sans "s" à la fin).

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

vitest.workspace.ts

export default ['packages/*'];

Vitest traitera chaque dossier dans packages comme un projet distinct, même s'il ne contient pas de fichier de configuration. Depuis Vitest 2.1, si ce motif glob correspond à n'importe quel fichier, il sera considéré comme une configuration Vitest, même s'il n'a pas vitest dans son nom.

WARNING

Vitest ne traite pas le fichier vitest.config racine comme un projet d'espace de travail, à moins qu'il ne soit explicitement spécifié dans la configuration de l'espace de travail. Par conséquent, la configuration racine n'influencera que les options globales telles que reporters et coverage.

Vous pouvez également faire référence à des projets via 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 ou unit avant son extension.

Vous pouvez également définir des projets en utilisant la configuration inline. Le fichier d'espace de travail prend en charge les deux syntaxes simultanément.

vitest.workspace.ts

import { defineWorkspace } from 'vitest/config';

// defineWorkspace améliore l'expérience développeur (DX) grâce à l'inférence de type.
export default defineWorkspace([
  // correspond à tous les dossiers et fichiers à l'intérieur du dossier `packages`
  'packages/*',
  {
    // ajoute "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 générera une erreur. Si un nom n'est pas fourni dans la configuration inline, Vitest attribuera un numéro. Pour les configurations de projet définies avec la syntaxe glob, Vitest utilisera par défaut la propriété "name" dans le fichier package.json le plus proche ou, à défaut, le nom du dossier.

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

vitest.workspace.json

["packages/*"]

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

packages/a/vitest.config.ts

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

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

Exécution des tests

Pour exécuter des tests à l'intérieur de l'espace de travail, définissez un script dans votre fichier package.json à la racine :

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

Maintenant, les tests peuvent être exécutés avec votre gestionnaire de paquets :

npm

npm run test

yarn

yarn test

pnpm

pnpm run test

bun

bun test

Si vous avez besoin d'exécuter des tests uniquement dans un seul projet, utilisez l'option 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

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

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

Configuration

Aucune des options de configuration n'est héritée de la configuration racine. Vous pouvez créer un fichier de configuration partagé et le fusionner 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',
    },
  })
);

Au niveau de defineWorkspace, vous pouvez utiliser l'option extends pour hériter de votre configuration racine. Toutes les options seront fusionnées.

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

Certaines options de configuration ne sont pas permises dans une configuration de projet. Les plus notables :

• coverage : la couverture est effectuée pour l'ensemble de l'espace de travail
• reporters : seuls les reporters de niveau racine peuvent être pris en charge
• resolveSnapshotPath : seul le résolveur racine est respecté
• toutes les autres options qui n'affectent pas les lanceurs de tests

TIP

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