Workspace
Vitest fournit un support intégré pour les monorepos via un fichier de configuration d’espace de travail. Vous pouvez créer un espace de travail pour définir les configurations de votre projet.
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 si vous en avez un). Vitest prend en charge les extensions ts
/js
/json
pour ce fichier.
Le fichier de configuration d’espace de travail doit avoir une exportation par défaut avec une liste de fichiers ou de motifs globaux faisant référence à vos projets. Par exemple, si vous avez un dossier nommé packages
contenant vos projets, vous pouvez définir un espace de travail avec ce fichier de configuration :
export default [ 'packages/*']
Vitest considérera chaque dossier dans packages
comme un projet distinct, même s’il n’a pas de fichier de configuration à l’intérieur.
Vous pouvez également référencer des projets avec leurs fichiers de configuration :
export default [ 'packages/*/vitest.config.{e2e,unit}.ts']
Ce motif inclura uniquement les projets avec un fichier vitest.config
qui inclut e2e
et unit
avant l’extension.
Vous pouvez également définir des projets avec une configuration en ligne. Le fichier d’espace de travail prend en charge l’utilisation des deux syntaxes en même temps.
import { defineWorkspace } from 'vitest/config'
// defineWorkspace fournit une belle indication de typeexport 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 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', } }])
Si vous ne dépendez pas de configurations en ligne, vous pouvez simplement créer un petit fichier json dans votre répertoire racine :
[ "packages/*"]
Les projets d’espace de travail ne prennent pas en charge toutes les propriétés de configuration. Pour une meilleure sécurité typée, utilisez la méthode defineProject
au lieu de defineConfig
dans les fichiers de configuration de projet :
// @errors: 2769import { defineProject } from 'vitest/config'
export default defineProject({ test: { environment: 'jsdom', // "reporters" n'est pas supporté dans une configuration de projet, // donc cela affichera une erreur reporters: ['json'] }})
Exécution des tests
Pour exécuter des tests dans l’espace de travail, définissez un script dans votre package.json
racine :
{ "scripts": { "test": "vitest" }}
Les tests peuvent maintenant être exécutés en utilisant votre gestionnaire de paquets :
npm run test
yarn test
pnpm run test
bun test
Si vous devez exécuter des tests uniquement dans un projet unique, utilisez l’option CLI --project
:
npm run test --project e2e
yarn test --project e2e
pnpm run test --project e2e
bun test --project e2e
Configuration
Aucune des options de configuration n’est héritée du fichier de configuration de niveau racine. Vous pouvez créer un fichier de configuration partagé et le fusionner avec la configuration du projet vous-même :
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 également utiliser l’option extends
à la place pour hériter de votre configuration de niveau racine.
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'], }, },])
De plus, certaines options de configuration ne sont pas autorisées dans une configuration de projet. Notamment :
coverage
: la couverture est effectuée pour l’ensemble de l’espace de travailreporters
: seuls les reporters de niveau racine peuvent être pris en chargeresolveSnapshotPath
: seul le résolveur de niveau racine est respecté- toutes les autres options qui n’affectent pas les exécuteurs de tests
Couverture
La couverture pour les projets d’espace de travail fonctionne directement. Mais si vous avez l’option all
activée et utilisez des extensions non conventionnelles dans certains de vos projets, vous aurez besoin d’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 en essayant d’analyser l’utilisation des fichiers non utilisés, car elle repose sur la configuration racine plutôt que sur la configuration du projet.