Erreurs courantes

Impossible de trouver le module ‘./relative-path’

Si vous recevez une erreur indiquant que le module ne peut pas être trouvé, cela peut signifier plusieurs choses différentes :

1. Vous avez mal orthographié le chemin. Assurez-vous que le chemin est correct.
1. Il est possible que vous comptiez sur baseUrl dans votre tsconfig.json. Vite ne prend pas en compte tsconfig.json par défaut, vous devrez donc peut-être installer vite-tsconfig-paths vous-même, si vous comptez sur ce comportement.

import { defineConfig } from 'vitest/config'
import tsconfigPaths from 'vite-tsconfig-paths'

export default defineConfig({
  plugins: [tsconfigPaths()]
})

Ou réécrivez votre chemin pour ne pas être relatif à la racine :

import helpers from 'src/helpers'
import helpers from '../src/helpers'

1. Assurez-vous de ne pas avoir d’aliases relatifs. Vite les considère comme relatifs au fichier où l’importation a lieu au lieu de la racine.

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    alias: {
      '@/': './src/', // [!code --]
      '@/': new URL('./src/', import.meta.url).pathname, // [!code ++]
    }
  }
})

Impossible de moquer “./mocked-file.js” car il est déjà chargé

Cette erreur se produit lorsque la méthode vi.mock est appelée sur un module qui a déjà été chargé. Vitest lance cette erreur car cet appel n’a aucun effet puisque les modules mis en cache sont préférés.

N’oubliez pas que vi.mock est toujours hoisté - cela signifie que le module a été chargé avant que le fichier de test ne commence à s’exécuter - très probablement dans un fichier de configuration. Pour corriger l’erreur, supprimez l’importation ou videz le cache à la fin d’un fichier de configuration - attention, le fichier de configuration et votre fichier de test feront référence à des modules différents dans ce cas.

import { vi } from 'vitest'
import { sideEffect } from './mocked-file.js'

sideEffect()

vi.resetModules()

Échec de la terminaison du worker

Cette erreur peut survenir lorsque fetch de NodeJS est utilisé avec le paramètre par défaut pool: 'threads'. Ce problème est suivi sur l’issue Timeout abort can leave process(es) running in the background #3077.

Comme solution, vous pouvez passer à pool: 'forks' ou pool: 'vmForks'.

vitest.config.js
CLI

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    pool: 'forks',
  },
})

vitest --pool=forks

Segfaults et erreurs de code natif

L’exécution de modules NodeJS natifs dans pool: 'threads' peut entraîner des erreurs cryptiques provenant du code natif.

Segmentation fault (core dumped)
thread '<unnamed>' panicked at 'assertion failed
Abort trap: 6
internal error: entered unreachable code

Dans ces cas, le module natif n’est probablement pas construit pour être sûr pour les threads multiples. Comme solution, vous pouvez passer à pool: 'forks', qui exécute les cas de test dans plusieurs node:child_process au lieu de plusieurs node:worker_threads.

vitest.config.js
CLI

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    pool: 'forks',
  },
})

vitest --pool=forks