Strona główna / Artykuły / Vite 8 połączył swoje narzędzia do pakowania w Rolldown – co się zepsuło

Vite 8 połączył swoje narzędzia do pakowania w Rolldown – co się zepsuło

Vite 8 domyślnie używa trybu Rolldown zarówno w środowisku rozwojowym, jak i produkcyjnym. Problemy z integracją z prawdziwym CJS, pułapki przy migracji fragmentów kodu oraz lista kontrolna przed zaufaniem do pozytywnego wyniku CI.

1296 słów

Przez lata Vite potajemnie używał dwóch różnych narzędzi do pakowania – jednego podczas rozwoju, a drugiego przy publikowaniu aplikacji. Rolldown kończy tę podziałność. Zyski w szybkości są rzeczywiste, podobnie jak lista problemów.

Wiele zespołów zna objawy, nie wskazując przyczyny: serwer lokalny pokazuje status zielony, a w środowisku produkcyjnym czerwony, i przyczyną nie jest błąd pisowni. Silnik wykonywania modułów w fazie rozwoju oraz narzędzia do ich pakowania do środowiska produkcyjnego nie zgadzały się co do pewnego szczególnego przypadku. W Vite ten konflikt miał charakter strukturalny: esbuild przetwarzał pliki podczas rozwoju, Rollup budował aplikację do produkcji, a połączenie tych narzędzi było na tyle dobre, że różnice pozostawały niewidoczne – dopóki tak nie stało się już nie.

Vite 8 eliminuje ten problem dzięki jednemu narzędziu typu Rust – Rolldownowi. Wyniki testów wydają się imponujące, podobnie jak lista aplikacji, które przestały działać, gdy lata specyficznych zachowań obu narzędzi nagle straciły swoje ukrycie. Znajomość obu stron pozwala na aktualizację bez nieoczekiwanych problemów.

Co zmieniło się w Vite 8

Decyzja o użyciu dwóch silników była rozsądna w 2020 roku. Stworzenie od zera narzędzia do pakowania kodu to praca trwająca lata. esbuild szybko się rozwijał, natomiast Rollup już posiadał ekosystem pluginów. Połączenie ich w jedno rozwiązanie wydawało się pragmatyczne. Jednak stworzyło to trwałe ryzyko: dwa narzędzia interpretujące te same źródła w różny sposób, szczególnie jeśli chodzi o współpracę z CommonJS – niezręczny most pomiędzy modułami require() a nowoczesnym ESM.

Rolldown to rozwiązanie tego problemu w ramach jednego silnika. Implementacja w języku Rust, API pluginów wzorowane na Rollupie (większość pluginów nadal funkcjonuje), wersja 1.0 stabilna od 7 maja 2026 roku z zamkniętym API przeznaczonym do użycia w produkcji. Sam Vite 8 osiągnął stabilność 12 marca 2026 roku i ustanowił Rolldown jako standard bez konieczności wyboru innej opcji. Przetwarzanie i minifikacja kodu, które wcześniej odbywały się za pomocą esbuild, teraz są realizowane przez Oxc – kolejne narzędzie z serii Rust stworzone przez VoidZero (ta sama firma co Rolldown).

Tytuł: wersje produkcyjne mogą być uruchamiane 10–30 razy szybciej niż klasyczny Rollup. Tryb rozwojowy to mniej znana historia. „Tryb pełnego pakietu” pakuje aplikację w fazie rozwoju w taki sam sposób jak wersja produkcyjna, zamiast dostarczać surowe pliki ESM pojedynczo. Wstępne dane wskazują na około 3 razy szybszy start aplikacji, o około 40% szybsze pełne ładowanie oraz mniej więcej 10 razy mniej żądań sieciowych. Duże bazy kodu już wcześniej miały problemy z nierozpakowanym ESM podczas rozwoju; to zamienia tę sytuację.

Korzyść strukturalna jest prostsza: jeden silnik dla obu trybów. Stare błędy typu „interoperacyjność w rozwoju ≠ interoperacyjność w produkcji” stają się niemożliwe, ponieważ nie ma już drugiego narzędzia do pakowania, z którym mogłyby istnieć różnice.

Co tak naprawdę się zepsuło

Migracja nie była bezkosztowa, a ukrywanie tego faktu nie pomaga tym, którzy planują aktualizację.

Strogsze zasady interoperacyjności CommonJS uszkodziły paczki. Niejednoznaczne eksporty w formacie CJS są obsługiwane inaczej niż w starym zestawie esbuild+Rollup. Bez pola module.exports.__esModule oraz bez właściwości default, Rolldown może powiązać import z całym obiektem module.exports zamiast domyślnie wybrać wartość, jak to robił bardziej tolerancyjny stack:

// This used to just work under Vite 7 (esbuild + Rollup)
import DOMPurify from 'dompurify';
DOMPurify.sanitize(input);
// Under Rolldown's stricter CJS interop, this can throw:
// TypeError: e is not a function
// because the import resolved to the whole exports object,
// not the function you expected

Zagrożająca właściwość tej klasy: narzędzia CI zazwyczaj jej nie wykrywają. jsdom lub symulowane testy rzadko uruchamiają prawdziwy plik produkcyjny. Błędy pojawiają się, gdy przeglądarka ładuje wygenerowany plik. Ustawienie legacy.inconsistentCjsInterop: true w Vite przywraca stare, bardziej tolerancyjne zachowanie, podczas gdy szukasz odpowiedniej zależności.

manualChunks został uznany za przestarzały na rzecz advancedChunks. Ta zamiana nie polega na prostym wyszukiwaniu i zastępowaniu. Zespoły napotkały błąd ReferenceError: Cannot access 'x' before initialization spowodowany skutkami ubocznymi związanymi z kolejnością fragmentów po ich ponownym grupowaniu, a przynajmniej jeden raport opisał 575 fragmentów przy domyślnym mechanizmie Rolldown przed ręczną regulacją.

// Old, now-deprecated approach
build: {
  rollupOptions: {
    output: {
      manualChunks: {
        vendor: ['react', 'react-dom'],
      },
    },
  },
}
// Rolldown's replacement - more powerful, but a real migration
build: {
  rolldownOptions: {
    output: {
      advancedChunks: {
        groups: [
          { name: 'vendor', test: /node_modules/, priority: 100 },
        ],
      },
    },
  },
}

Zdokumentowany przypadek: biblioteka Cloudflare’s @cloudflare/style-provider (hybrydowa ESM+CJS) napotkała błąd createRenderer is not a function, ponieważ Rolldown wygenerował anonimowego, niedostępnego inicjalizatora dla części w formacie CJS. Poprawka polegała na powiązaniu tego pakietu z jego wersją CJS w konfiguracji Vite — zwykła wersja CJS działająca poprzez interfejs Rolldown była bezproblemowa, natomiast hybrydowa forma nie.

Kod aplikacji spoza niej: wbudowane połączenie Rolldown z językiem Rust nie udało się załadować w StackBlitz WebContainers, co sparaliżowało wiele szablonów do testowania w przeglądarce, dopóki projekty nie przełączyły się na Vite 7, podczas gdy twórcy oprogramowania pracowali nad rozwiązaniem problemu.

Listwa kontrolna bezpieczniejszej migracji

Zespoły, które zakończyły proces migracji, skupiają się na konkretnych krokach, a nie tylko na „aktualizacji i modlitwie”.

Tajemnicze błędy typu „Vite 7 działa, Vite 8 nie”: najpierw spróbuj użycia experimental: { enableNativePlugin: false }. Wtyczki napisane w języku Rust są teraz domyślnie włączone; ich wyłączenie naprawia spore ilość niejasnych problemów.

Zanim uruchomisz aplikację w produkcji, załaduj prawdziwy plik bundle w rzeczywistej przeglądarce. jsdom nie wykryje klas interfejsu CJS, chyba że uruchomisz zbudowany plik.

Rozpatruj zmianę z manualChunks na advancedChunks jako osobny projekt wymagający własnego testowania. Błędy związane z kolejnością fragmentów kodu wydają się nieistniejące, dopóki nie zostanie uruchomiony określony ścieżka.

Zmniejsz ryzyko za pomocą rolldown-vite (Vite 7 + przeglądanie Rolldown) wobec twojej bazy kodu przed przejściem na Vite 8.

Jeśli jakaś kluczowa zależność nie jest jeszcze gotowa do użycia w Rolldown, pozostanie przy Vite 7 dla tej budowy to słuszna decyzja — lepsza niż wymyślanie kruchych rozwiązań pod presją terminu.

Kto powinien się spodziewać problemów

Standardowe zależności ESM oraz lekkie/domyślne dzielenie na fragmenty: aktualizacje zazwyczaj przebiegają gładko, a sama zgodność jest już wystarczającym powodem do przejścia. Niestandardowe manualChunks, hybrydowe pakiety CJS/ESM lub nietypowe środowiska (przestrzenie testowe przeglądarki, WebContainers): uwzględnij czas migracji i przetestuj produkt w przeglądarce. Te błędy przechodzą testy CI bez problemów i pojawiają się tylko u rzeczywistych użytkowników w rzeczywistych plikach.

Ważniejsza lekcja

Kiedy dwa systemy, które wcześniej tylko maskowały swoje braki, łączą się w jeden, nagle ujawniają się wcześniej niewidoczne szwy. To nie oznacza, że fuzja była błędem. Równowaaga między środowiskiem deweloperskim a produkcyjnym to rzeczywisty ulepszenie strukturalne, a wskaźniki szybkości działania pozostają na wysokim poziomie. Oznacza to, że „usunęliśmy rozbieżności” oraz „fala konkretnych, łatwo do znalezienia błędów pojawi się podczas przejścia” to ten sam fakt, tylko w różne dni kalendarzowe. Skeptycyzm wobec Rolldown jest błędną postawą; sceptycyzm wobec zielonego CI bez pakietu produkcyjnego ładowanego przez przeglądarkę jest właściwy.

Co umieścić w zgłoszeniu migracji

Napisz o tym ulepszeniu jako o zmianie inżynieryjnej z kryteriami akceptacji, a nie jako o podwyższeniu wersji zależności.

Zaproponowane kryteria:

  1. Budowa wersji produkcyjnej powinna zostać ukończona przy użyciu Rolldown z tymi samymi zasobami publicznymi, jakich oczekujemy.
  • Krytyczne ścieżki użytkownika są testowane w rzeczywistym przeglądarce przy użyciu zbudowanego pakietu (a nie tylko testów jednostkowych).
  • Znane hybrydowe zależności CJS są albo przemieniane w aliasy, albo aktualizowane, albo objęte opcją legacy.inconsistentCjsInterop wraz z określonym właścicielem i datą wygaśnięcia.
  • Strategia dzielenia na fragmenty jest wyraźnie sprawdzana: albo przyjmuje się domyślne ustawienia Rolldown po zmierzeniu liczby żądań, albo przenosi się manualChunks na advancedChunks przy użyciu dedykowanego etapu testowania.
  • Środowiska, które nie mogą załadować natywnych powiązań (na przykład niektóre hosty WebContainer), mają udokumentowane rozwiązania lub workarounds.
  • Jeśli jakikolwiek kryterium nie zostanie spełnione, należy pozostać przy Vite 7 lub rolldown-vite aż do jego spełnienia. Wprowadzanie szybszego narzędzia pakowania, które powoduje problemy w produkcji, nie stanowi poprawy wydajności.

    Dlaczego błędy parowości wydają się osobiste

    Rozwijający ufają lokalnemu serwerowi. Gdy lokalny serwer oraz wersja produkcyjna przestaną ze sobą kłócić się, błędy, które wcześniej ukrywały się w tych konfliktach, pojawiają się w jednym miejscu. Może to sprawiać wrażenie, jakby mechanizm Rolldown „wprowadził” awarie, które od zawsze istniały w wyniku niejednoznaczności CJS lub struktur chunków. Określenie tego wzorca zmniejsza panikę – nie ścigasz przypadkowych regresji, lecz ujawniasz problemy, które era podwójnego silnika próbowała ukryć.

    Zachowaj liczby dotyczące szybkości. Zachowaj projekt oparty na jednym silniku. Po prostu nie myl zielonego zestawu jednostek z dowodem na to, że stworzony artefakt działa poprawnie.

    Literatura pokrewna