Passer au contenu

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 type
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 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: 2769
import { 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 :

Fenêtre de terminal
npm run test

Si vous devez exécuter des tests uniquement dans un projet unique, utilisez l’option CLI --project :

Fenêtre de terminal
npm run 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 travail
  • reporters: seuls les reporters de niveau racine peuvent être pris en charge
  • resolveSnapshotPath: 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.