Migracja React do Vite idzie źle w chwili, gdy zamienia się w redesign. Najbezpieczniejsza wersja wymienia fundament builda i dev środowiska pod aplikacją, zachowując jej widoczne zachowanie dokładnie takim samym. Szybsze lokalne buildy są warte sporo, ale tylko wtedy, gdy produkcja przez cały czas pozostaje nudna.
Kiedy pojawia się problem
Frontend zwykle sam ogłasza, że się zestarzał. Dev server długo startuje i przeładowuje. Narzędzie builda jest na starej, wolnej ścieżce, jak legacy Webpack albo Create React App, która nie dostaje już dużo uwagi. Upgrade jednej zależności kaskaduje w zmiany konfiguracji, których nikt nie chce wziąć na siebie. Nowe osoby tracą dzień na setup środowiska. Aplikacja wciąż działa, ale każda interakcja z buildem spowalnia zespół, a ten podatek się kumuluje.
Typowe tryby awarii
Łączenie migracji z redesignem. Zmiana builda i refactor komponentów naraz sprawiają, że regresji nie da się przypisać. Gdy coś pęka, nie wiesz, czy to nowy build, czy nowy kod.
Niedocenianie założeń builda. Zmienne środowiskowe, ścieżki assetów, narzędzia testowe, konfiguracja TypeScript, zachowanie proxy, target deploymentu i komendy CI to miejsca, gdzie naprawdę mieszkają niespodzianki migracji. Łatwo o nich zapomnieć właśnie dlatego, że są niejawne.
Pomijanie przejścia kompatybilności. Routing, formularze, flow autoryzacji, ekrany admina, analityka, feature flags i statyczne assety często zachowują się subtelnie inaczej po zmianie builda. Bez świadomego sprawdzenia te różnice trafiają do użytkowników.
Ufanie lokalnemu sukcesowi. Szybki lokalny build, który nie przeszedł realną ścieżką deploymentu, dowodzi niewiele. Ciekawe awarie pojawiają się w CI i w preview produkcyjnym.
Kontrolowane podejście
Najpierw wypisz założenia builda
Zanim cokolwiek zmienisz, spisz zmienne środowiskowe, ścieżki assetów, narzędzia testowe, ustawienia TypeScript, reguły proxy, target deploymentu i komendy CI. Ta lista to realna powierzchnia migracji, a jej uwidocznienie usuwa większość niespodzianek.
Przenieś build, zamroź zachowanie
Najpierw wymień fundament builda i trzymaj widoczne zachowanie stabilnym. Powstrzymaj się od refactoru, gdy build jest w ruchu. Dopiero gdy aplikacja działa na nowym fundamencie, zacznij porządkować stare wzorce, jako osobny, reviewowalny krok.
Zrób świadome przejście kompatybilności
Przejdź przez routing, formularze, autoryzację, ekrany admina, analitykę, feature flags, statyczne assety i preview deploymentu. Traktuj każde jako punkt checklisty, nie założenie. To tu migracja zasługuje na miano bezpiecznej.
Weryfikuj realnym pipeline’em
Potwierdź, że build zachowuje się w CI i w preview zbliżonym do produkcji, nie tylko na maszynie dewelopera. Ścieżka deploymentu jest częścią migracji, nie dodatkiem.
Checklista operacyjna
- Założenia builda są spisane przed startem migracji.
- Build jest migrowany osobno od jakiegokolwiek refactoru komponentów.
- Routing, autoryzacja, formularze i ekrany admina są zweryfikowane po przełączeniu.
- Zmienne środowiskowe i ścieżki assetów rozwiązują się identycznie na produkcji.
- Komendy CI i preview deploymentu przechodzą na nowym buildzie.
- Widoczne zachowanie jest niezmienione, gdy ogłaszasz migrację za skończoną.
Bezpieczna droga naprzód
Migruj build normalnym procesem release, trzymaj diff skupiony na narzędziach, a nie na funkcjach, i dowieź, gdy przejście kompatybilności i CI zgodnie potwierdzą, że nic widocznego dla użytkownika się nie zmieniło. Nagrodą jest frontend łatwiejszy do uruchomienia, testowania i zmiany, osiągnięty bez zmuszania zespołu do pełnego rewrite.
Ta praca jest częścią modernizacji i rescue infrastruktury i stoi obok checklisty modernizacji Rails, gdy backend niesie własny dług. Łączy się z naszymi szerszymi usługami, a strona proof ujmuje to samo ostrożne, inkrement po inkremencie, delivery. Jeśli wolny albo kruchy frontend blokuje Twój zespół, napisz, co się psuje.