Generator vitest.config.js
Szybkie testy dla projektów Vite
-
1Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku. -
2Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce. -
3Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.
return "Wynik gotowy w 0.1s";
}
Oceń to narzędzie:
Powiązane narzędzia
Inne narzędzia, które mogą Ci się przydaćGenerator konfiguracji Vitest
Vitest to nowoczesny framework testów zbudowany na Vite. Dzieli z nim konfigurację, więc aliasy, transformacje i pluginy działają identycznie w testach i kodzie.
Najważniejsze opcje
| Opcja | Znaczenie |
|---|---|
| environment | node, jsdom lub happy-dom |
| globals | opis, it, expect bez importu |
| setupFiles | pliki wykonywane przed testami |
| coverage.provider | v8 (szybki) lub istanbul |
Przykład
Konfiguracja z environment: 'jsdom' i globals: true pozwala testować komponenty bez ręcznego importowania funkcji testowych.
Uruchamianie
npx vitest— tryb obserwacji.npx vitest run— jednorazowe uruchomienie (CI).npx vitest --coverage— raport pokrycia.
Jak działa generator vitest.config.js
Generator zbiera opcje wybrane w formularzu i składa z nich obiekt konfiguracji, który trafia do pliku eksportowanego przez defineConfig z pakietu vitest/config. Wynikowy plik zapisujesz w katalogu głównym projektu, obok package.json — Vitest wykrywa go automatycznie przy starcie, bez potrzeby podawania ścieżki w komendzie.
Kluczowa jest kolejność wczytywania. Vitest stoi na Vite, więc najpierw czyta vite.config, a potem vitest.config — i ten drugi ma priorytet. Dzięki temu nie duplikujesz pluginów, aliasów ani ustawień resolve: sekcja test: opisuje wyłącznie to, co dotyczy testów, a reszta pipeline'u działa identycznie jak w buildzie i w trybie deweloperskim.
Wewnątrz sekcji test: umieszczasz ustawienia środowiska (environment), globalnych funkcji (globals), plików startowych (setupFiles) oraz pokrycia (coverage). Kolejność kluczy w obiekcie nie ma znaczenia, a rozszerzenie pliku możesz zmienić z .js na .ts, jeśli chcesz korzystać z podpowiedzi typów. Flagi przekazane w wierszu poleceń nadpisują wartości z pliku tylko na czas danego uruchomienia, więc konfiguracja ustala zachowanie domyślne, a nie jedyne możliwe.
Przykład: od decyzji do gotowego pliku
- Wybierz środowisko. Projekt zawiera testy komponentów, więc zaznaczasz environment: jsdom. Testy czystej logiki mogą działać w node — nadpiszesz je pojedynczo komentarzem @vitest-environment na górze pliku.
- Włącz globals. Ustawiasz globals: true, żeby describe, it i expect były dostępne bez importu. W projekcie z TypeScript dopisujesz vitest/globals do tablicy types w tsconfig, inaczej edytor podkreśli te funkcje.
- Wskaż setupFiles. Podajesz tablicę z jednym elementem, np. ./test/setup.js — to miejsce na matchery DOM i globalne mocki współdzielone przez wszystkie pliki testowe.
- Skonfiguruj pokrycie. Wybierasz coverage.provider: v8 i dodajesz do coverage.exclude katalog testów oraz pliki konfiguracyjne, żeby nie zaniżały raportu.
- Ustaw raportowanie. Zostawiasz reporters z jednym wpisem domyślnym dla pracy lokalnej; w pipeline podmieniasz go na format czytelny dla CI.
- Zapisz i uruchom. Zapisujesz plik jako vitest.config.js i odpalasz testy z flagą --coverage.
Wynikiem jest sekcja test z czterema kluczami najwyższego poziomu: environment, globals, setupFiles i coverage. Pokrycie zobaczysz w procentach dopiero po uruchomieniu — sam plik go nie liczy, tylko definiuje sposób pomiaru.
Mapowanie ustawień na klucze w pliku
| Ustawienie w generatorze | Klucz w vitest.config.js | Kiedy warto włączyć |
|---|---|---|
| environment | test.environment: node, jsdom lub happy-dom | node dla logiki, jsdom lub happy-dom dla komponentów i DOM |
| globals | test.globals | gdy chcesz pisać describe i it bez importu w każdym pliku |
| setupFiles | test.setupFiles | gdy potrzebujesz wspólnych matcherów, polyfilli lub mocków |
| provider pokrycia | test.coverage.provider | v8 dla szybkości, istanbul gdy zależy Ci na dokładniejszym mapowaniu |
| wykluczenia pokrycia | test.coverage.exclude | gdy raport mają zaniżać pliki konfiguracyjne i same testy |
| aliasy | resolve.alias (dziedziczone z Vite) | gdy kod używa skrótów importu, np. @/ |
| reporters | test.reporters | gdy wynik ma być czytelny maszynowo w CI |
| include i exclude testów | test.include, test.exclude | gdy testy leżą poza domyślnymi katalogami |
Praktyczne wskazówki
- Trzymaj aliasy w jednym miejscu. Jeśli kod używa skrótów importu, zdefiniuj je w resolve.alias w vite.config — Vitest odziedziczy mapowanie, więc nie powielasz tej samej listy w dwóch plikach.
- Nie mieszaj konfiguracji testów z produkcyjną. Do vitest.config wkładaj tylko sekcję test:; wszystko, co zmienia build, zostaw w vite.config, bo sekcja test nie wpływa na wynikowy bundle.
- Rozważ plik .ts zamiast .js. Typ defineConfig podpowiada dostępne opcje i wyłapuje literówki w nazwach kluczy. Jeśli projekt nie używa TypeScript, plik .js jest w pełni wystarczający.
- Ustawiaj środowisko per plik, gdy to możliwe. Przy environment: node nadpisz je komentarzem @vitest-environment jsdom tylko w testach, które naprawdę potrzebują DOM, zamiast przełączać cały projekt na cięższe środowisko.
- Nie ustawiaj progów pokrycia na starcie. Najpierw uruchom testy z flagą --coverage i zobacz realny raport, a dopiero potem dodaj coverage.thresholds — inaczej pipeline będzie czerwony od pierwszego commita.
Czego narzędzie nie uwzględnia
- Nie scala konfiguracji z vite.config. Generator tworzy tylko plik testowy. Jeśli w Vite masz pluginy zmieniające transformacje, musisz sam sprawdzić, czy działają w testach i czy nie wymagają warunkowego wyłączenia.
- Nie dobiera wersji Vitest. Nazwy i kształt opcji zmieniają się między majorami. Wygenerowany plik zakłada aktualne API i w starszym projekcie może wymagać ręcznej korekty.
- Nie wykrywa obecności innego runnera. Jeśli w repozytorium jest konfiguracja Jest, a skrypty w package.json wskazują na Jest, sam plik vitest.config.js nie przełączy narzędzia — trzeba zmienić skrypty.
- Nie weryfikuje ścieżek ani struktury projektu. Wpisany setupFiles czy własny include to Twoja deklaracja. Gdy plik nie istnieje albo katalog jest inny, błąd pojawi się dopiero przy uruchomieniu testów.
Najczęstsze pytania
Czym Vitest różni się od Jest?
Jest szybszy w projektach Vite, bo używa tego samego pipeline'u. Interfejs API jest zbliżony, co ułatwia migrację.
jsdom czy happy-dom?
happy-dom jest lżejszy i szybszy, ale jsdom jest bardziej kompletny. Dla większości testów komponentów wystarczy happy-dom.
Czy globals są zalecane?
Ułatwiają pisanie, ale wymagają konfiguracji typów w TypeScript. Bez nich importujesz funkcje jawnie — to bardziej przewidywalne.
Jak wygenerować plik vitest.config.js?
Zaznacz opcje w generatorze, skopiuj wynik i zapisz go w katalogu głównym projektu, obok package.json. Vitest wykrywa ten plik automatycznie, więc nie musisz podawać ścieżki w komendzie.
Czy vitest.config.js może być plikiem TypeScript?
Tak, wystarczy zmienić rozszerzenie na .ts — defineConfig z vitest/config jest typowany. Przy pliku .js pamiętaj o zgodności z polem type w package.json, jeśli używasz składni import i export.
Czym różni się vitest.config.js od vite.config.js?
Vitest czyta oba pliki, ale konfiguracja Vitest ma priorytet. Sekcja test: istnieje wyłącznie w pliku Vitest, natomiast plugins, resolve.alias i define są wspólne dla Vite i testów.
Jak ustawić alias @ w Vitest?
Najczęściej nie ustawia się go osobno — dodaj resolve.alias w vite.config, a Vitest odziedziczy mapowanie. Osobny wpis w vitest.config ma sens tylko wtedy, gdy testy mają widzieć inne ścieżki niż build.
Jak włączyć raport pokrycia w Vitest?
Ustaw coverage.provider na v8 albo istanbul i uruchom testy z flagą --coverage. Sam plik nie tworzy progu — dopisz coverage.thresholds, jeśli chcesz blokować zmiany poniżej ustalonego procentu pokrycia.