Spis treści
1. Dlaczego Vite 8 miało znaczenie
CRXJS działa dokładnie tam, gdzie semantyka rozszerzeń spotyka się z wnętrznościami Vite: manifest, emitowanie content scriptów, ładowanie dev servera, HMR i output produkcyjny. Kiedy Vite 8 przesunęło bundling w stronę Rolldown, to był dokładnie taki typ zmiany, który potrafi wyciągnąć każde słabe założenie w pluginie.
Dokumentacja Extension.js uchwyciła jeden widoczny failure mode: [crx:manifest-post] Content script fileName is undefined. To był użyteczny sygnał, bo wskazywał prawdziwą granicę integracji: CRXJS musiał utrzymać extension-specific output, gdy Vite zmieniało się pod spodem.
To jest maintenance, którym warto się chwalić: konkretny, publiczny i mierzalny. Zespół nie poprzestał na zmianie zakresu wersji. Upgrade zamienił się w joby CI, fixture kompatybilności, regresje E2E, poprawki HMR i lokalne narzędzia, które ułatwią obsługę następnej zmiany w Vite.
2. Co zostało dowiezione
Na 19 czerwca 2026 opublikowana paczka to @crxjs/vite-plugin@2.7.0. Jej peer dependency akceptuje vite@^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0 || ^8.0.0. Aktualny workflow CI podpiera to jobami compatibility i E2E dla Vite 3, 6, 7 i 8 na Ubuntu oraz Windows.
Opublikowane wsparcie
Aktualna paczka npm jawnie obejmuje Vite 8 w zakresie peer dependency.
Matryca CI
Aktualny workflow uruchamia compat i E2E na Vite 3, 6, 7 oraz 8 dla Ubuntu i Windows.
Pokrycie E2E
Matryca sprawdza zachowanie rozszerzenia w przeglądarce, nie tylko instalację paczki albo typy.
Workflow maintainerów
Lokalny runner matrycy pozwala odtworzyć te same ścieżki Vite-major przed releasem.
Tak wygląda prawdziwy upgrade w open-source build toolu: metadane release, matryca CI, browser-level E2E i lokalne narzędzia, dzięki którym maintainerzy mogą odtworzyć te same ścieżki kompatybilności przed publikacją.
3. Historia upgradu
Najlepsze w tej pracy jest to, że wszystko widać publicznie. Można przejść historię pull request po pull requeście: najpierw umożliwić matrycę, potem dodać nowy major Vite, pozwolić CI znaleźć dziwne przypadki, a następnie zamienić te przypadki w testy.
Skonsolidowano testy wersji Vite w matrycowym CI
Zamiast osobnych pakietów testów kompatybilności powstał jeden przepływ matrycowy dla Vite 3, 6 i 7 na Ubuntu oraz Windows.
Dodano wsparcie Vite 8 beta i testy CI
Dodano pokrycie Vite 8.0.0 beta przed stabilnym wydaniem i rozszerzono zakres peer dependency.
Przetestowano plugin na Vite 3, 6, 7 i 8
Uruchomiono testy E2E i kompatybilności na Vite 3, 6, 7 i 8 dla Ubuntu oraz Windows.
Dopuszczono originy rozszerzeń w dev CORS
Obsłużono ostrzejsze domyślne CORS w dev serverze Vite dla originów chrome-extension:// i moz-extension://.
Przyspieszono runner E2E dla Vite
Usunięto stałe waity, rozgrzano profile Chromium i zaraportowano redukcję czasu o 31,9% na mierzonym fixture.
Dodano lokalny runner matrycy Vite
Pozwoliło to odtwarzać lokalnie te same ścieżki kompatybilności, które uruchamia CI, bez ręcznej zmiany wersji zależności.
Dodano HMR dla content scriptów w świecie MAIN
Dodano HMR dla manifest-declared content scriptów z world: MAIN oraz test regresji E2E.
Scalono waity gotowości file writera
Naprawiono ponowne obliczanie gotowości i późne waity HMR, z pokryciem unit oraz E2E.
Obsłużono self importy React Refresh w HMR content scriptów
Naprawiono przypadek Vite 8 i React plugin 5.2.0, gdzie wygenerowane self importy mogły blokować przekazanie payloadu HMR.
To jest wzorzec, którym warto się chwalić: każdy PR przesuwał niepewność do automatyzacji. Regresja CORS dostała pokrycie unit. HMR dla content scriptów w świecie MAIN dostał regresję E2E. Self importy React Refresh dostały skupiony test Vite 8. Następny maintainer nie musi pamiętać incydentu. CI go pamięta.
4. Dlaczego testy E2E mają znaczenie
Bugi w toolingach do rozszerzeń rzadko wyglądają jak czyste porażki unit testów. Wyglądają jak popup zatrzymany na loading page, content script bez reloadu, service worker importujący z zablokowanego originu albo profil przeglądarki płacący koszt startu na każdym fixture.
Dlatego workflow pluginu Vite ma znaczenie: nie kończy się na lintowaniu i unit testach. Aktualne CI uruchamia testy kompatybilności oraz E2E na Vite 3, 6, 7 i 8 dla Ubuntu oraz Windows. Runner E2E odpala Chromium przez XVFB na Linuxie i waliduje rzeczywiste zachowanie rozszerzenia.
Przyspieszenie nie było kosmetyką
PR #1177 usunął redundantny stały wait, rozgrzał pusty profil Chromium i zaraportował redukcję o 31,9% na mierzonym fixture. Szybsze testy E2E zmieniają zachowanie projektu: maintainerzy uruchamiają je częściej, regresje są tańsze do złapania, a kompatybilność przestaje być specjalną ceremonią.
To jest prawdziwe przyspieszenie developmentu. Nie slogan. Krótsza pętla od "Vite coś zmieniło" do "jest reproducer, fix i test regresji".
5. Co udowadnia matryca OS
Aktualny workflow pluginu CRXJS Vite wymienia Ubuntu i Windows dla jobów unit/output, compatibility i E2E. Ta matryca jest powodem do dumy, bo Windows to miejsce, w którym tooling do rozszerzeń najczęściej obrywa przez ścieżki, kopiowanie plików, line endingi i timing systemu plików.
PR #1008, duży PR odblokowujący Windows, wprost omawiał macOS jako możliwe 1:1 dopasowanie do workflow projektu Vite. Decyzja była wtedy pragmatyczna: macOS zachowywał się jak Ubuntu dla istotnych przypadków, a Windows miał realne różnice w ścieżkach, kopiowaniu plików, snapshotach i HMR, które wymagały pierwszorzędnego pokrycia.
Precyzyjna wersja jest więc też mocniejsza: CRXJS dziś dowodzi matrycy Vite 3/6/7/8 na Ubuntu i Windows, włącznie z browser-level E2E. To jest trudna praca cross-platform, która realnie poprawia niezawodność projektu dla zespołów.
6. Publiczne dowody
Ta praca jest publiczna, dokładnie tak jak powinna wyglądać infrastruktura open-source. Jeśli chcesz ocenić stan CRXJS na Vite 8, zacznij od metadanych release, workflow CI i zmergowanych pull requestów.
Potrzebujesz toolingu do rozszerzeń, który przeżywa upgrade?
Budujemy rozszerzenia przeglądarkowe i pipeline CI wokół nich. Gdy Vite, Chrome albo Manifest V3 zmieniają coś pod spodem, wiemy gdzie szukać i jak zamknąć fix w testach.
