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 :
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 :
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.
Si vous ne dépendez pas de configurations en ligne, vous pouvez simplement créer un petit fichier json dans votre répertoire racine :
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 :
Exécution des tests
Pour exécuter des tests dans l’espace de travail, définissez un script dans votre package.json
racine :
Les tests peuvent maintenant être exécutés en utilisant votre gestionnaire de paquets :
Si vous devez exécuter des tests uniquement dans un projet unique, utilisez l’option CLI --project
:
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 :
Au niveau de defineWorkspace
, vous pouvez également utiliser l’option extends
à la place pour hériter de votre configuration de niveau racine.
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.