Usuwanie starych zależności JavaScript: CRA, Moment, jQuery i inne

Większość projektów napisanych w JavaScript posiada kilka zależności, które były oczywistym wyborem przy tworzeniu repozytorium, ale obecnie stanowią tylko ciężar: duże pliki, nierozwiązane luki bezpieczeństwa, nieodpowiednia integracja z nowoczesnymi środowiskami wykonawczymi lub funkcje, które platforma teraz oferuje za darmo. Żadna z nich nie powoduje nagłych problemów, i to właśnie dlatego nadal istnieją. Ten przewodnik przedstawia biblioteki i narzędzia, które są przestarzałe, zamrożone w trybie konserwacyjnym lub stopniowo tracą na znaczeniu, wyjaśnia, dlaczego każde z nich zostało w tyle, oraz wskazuje alternatywy, których należy używać, aby móc planować migracje świadomie, a nie pod presją.

Narzędzia do budowania i tworzenia szkieletów

Create React App

Przez lata Create React App (CRA) był narzędziem służącym do tworzenia projektów React. Na początku 2025 roku zespół React oficjalnie odrzucił go jako punkt wyjścia dla nowych aplikacji, a on sam nie otrzymuje już istotnych aktualizacji, przez co problemy bezpieczeństwa w jego ekosystemie pozostają nierozwiązane. Liczba pobrań tego narzędzia szybko spada, ponieważ zespoły przechodzą na inne rozwiązania.

Podstawowe przyczyny są strukturalne: nikt aktywnie go nie utrzymuje, jego założenia dotyczące pakowania i serwerów deweloperskich są przestarzałe, a alternatywy spełniają nowoczesne wymagania, takie jak renderowanie na serwerze, szybsze budowanie aplikacji oraz lepsze doświadczenie dewelopera bez dodatkowej konfiguracji. Dobrymi zamiennikami są:

• Vite z @vitejs/plugin-react dla typowych aplikacji jednostronicowych
• Next.js, Remix / React Router lub inne pełne frameworki, jeśli aplikacja wymaga routera, konwencji pobierania danych lub kodu po stronie serwera

Parcel lub Rsbuild, jeśli chcesz czegoś lżejszego

Ponieważ aplikacja CRA to przede wszystkim standardowy kod React w połączeniu z ukrytą konfiguracją budowania, migracja jest zazwyczaj znacznie prostsza, niż oczekują zespoły: wymieniasz narzędzie do budowania, przenosisz punkt wejścia HTML oraz konwencje zmiennych środowiskowych, a same komponenty pozostają nietknięte. Jeśli zaczynasz od nowa, przewodnik w naszym przewodniku konfiguracji React i Vite omawia nowe standardy.

Webpack dla nowych projektów

Webpack daleki jest od śmierci. Ogromna liczba aplikacji produkcyjnych nadal jest z nim budowana, i to się w najbliższym czasie nie zmieni. To, co maleje, to jego udział w nowych projektach, głównie z powodu złożoności konfiguracji oraz wolniejszego uruchamiania się w porównaniu z nowszymi narzędziami. Do pracy nad nowymi interfejsami użytkownika Vite jest obecnie standardem, a inne mocne opcje to rozwiązania oparte na Rspack i esbuild. Webpack nadal sprawdza się przy bardzo złożonych istniejących konfiguracjach, ale rzadko powinien być wyborem na początek nowego projektu. Aby zapoznać się z bardziej szczegółowym porównaniem opcji, sprawdź wybór narzędzia do pakowania.

Biblioteki wchłonięte przez platformę

Moment.js

Prawie każdy programista pracujący z JavaScriptem korzystał kiedyś z Moment.js. Jego właściciele od dawna określają go jako projekt z przeszłości, który funkcjonuje w trybie konserwacyjnym. Jest on duży, jego obiekty są domyślnie modyfikowalne (co stanowi częsty źródło błędów, gdy data jest zmieniana w jednym miejscu, a obserwowana w innym), a ponadto nie nadaje się dobrze do optymalizacji.

Zarządzanie datami w języku natywnym uległo poprawie, a małe, niezmienne biblioteki realizują ten zadanie z lepszą wydajnością. Oto Twoje opcje, mniej więcej w kolejności preferencji:

• Intl.DateTimeFormat do formatowania z uwzględnieniem ustawień lokalnych
• Temporal – nowa wbudowana API do obsługi dat i czasu, na którą programiści czekali lata; jest stopniowo wprowadzana w różnych środowiskach i przeglądarkach; sprawdź aktualne wsparcie dla Twoich celów przed jej użyciem
• date-fns, Luxon lub Day.js, jeśli nadal jest to konieczne

Jeśli Moment nadal znajduje się w twoim drzewie zależności, umów termin migracji. Samo zmniejszenie rozmiaru pliku jest często znaczne.

jQuery

W latach 2010. jQuery rozwiązywał poważne problemy pomiędzy przeglądarkami. W przypadku nowego kodu obecnie jest to prawie nigdy uzasadnione, ponieważ standaryzowane API DOM, fetch oraz frameworki komponentowe pokrywają wszystko to, co kiedyś musiał on załatwiać. Zwykły JavaScript z querySelector, classList, addEventListener oraz wbudowanym fetch radzi sobie z większością prostych operacji na DOM, a React, Vue, Svelte lub Solid przejmują kontrolę, gdy potrzebne są interfejsy oparte na komponentach. Stare bazy kodowe będą używać jQuery przez lata, i to w porządku, ale użycie go w zupełnie nowym projekcie jest sygnałem ostrzegawczym.

Lodash i Underscore

Przed ES2015 Lodash był niemal obowiązkowy. Obecnie większość jego narzędzi ma odpowiedniki w języku: metody tablic takie jak map, filter i reduce, Object.entries, opcjonalne łączenie wartości, spajanie wartości nullowych i wiele innych. Trudno uzasadnić włączanie całej biblioteki, a nawet jej dużych części, tylko po to, by użyć kilku funkcji. Należy zacząć od samego języka i dodawać specjalistyczne narzędzia wyłącznie tam, gdzie wbudowana API rzeczywiście zawodzi – na przykład w kwestiach głębokiego porównywania wartości lub odcinania sygnałów. Nasz artykuł na temat wbudowanych funkcji, które zastępują zależności od narzędzi pomocniczych przedstawia konkretne przykłady takich zastąpień.

Testowanie i sieci

Enzyme

Przez długi czas enzym był dominującym narzędziem do testowania komponentów React, ale nigdy dobrze nie przystosował się do React 18 oraz jego funkcji współbieżnych, w wyniku czego jego popularność gwałtownie spadła. Ponieważ enzym zachęcał do testowania wewnętrznych elementów komponentu (stanu, metod instancji, płytkich drzew renderowania), migracja polega częściowo na zmianie sposobu myślenia. React Testing Library, rekomendowane zarówno przez społeczność, jak i zespół React, testuje natomiast to, co widzi i robi użytkownik. Należy je łączyć z Vitest lub Jest jako narzędziem do wykonywania testów.

request i node-fetch v2

request został oficjalnie uznany za przestarzały już dawno temu i nie otrzymuje już poprawek bezpieczeństwa, więc wszelkie nadal używanie go stanowi otwarte zagrożenie. Liczba pobierania node-fetch v2 również gwałtownie spadła, ponieważ Node.js 18 i nowsze włączają globalną funkcję fetch (w wersjach początkowych była oznaczona jako eksperymentalna, więc sprawdź jej zachowanie w swojej wersji Node). Używaj wbudowanej funkcji fetch, która teraz działa w nowoczesnych wersjach Node oraz we wszystkich aktualnych przeglądarkach. Jeśli potrzebujesz powtórzeń prób, interceptorów lub bardziej zaawansowanego przepływu danych, rozważ użycie bibliotek takich jak undici, ky lub got.

Inne elementy wartych śledzenia

Kilka innych zmian również zasługuje na umieszczenie na liście aktualizacji:

• Zgodnie z harmonogramem wydań, ESLint 9.x osiągnie koniec swojego cyklu życia w sierpniu 2026 roku; zaplanuj przejście na wersję v10 i sprawdź dokładne daty na stronie ESLint.

SDK AWS dla JavaScripta wersja v2 przekroczyła okres wsparcia. Przejdź na modułowe klienty wersji v3 dostępne pod @aws-sdk/*, które umożliwiają również import tylko tych klientów, których używasz.

Stare narzędzia takie jak vue-cli i Nuxt 2 są praktycznie już przestarzałe.

Node.js nadal usuwa wbudowane funkcje oraz starsze API w miarę modernizacji środowiska wykonawczego, dlatego przed każdym aktualizacją do nowszej wersji przeczytaj oficjalną listę funkcji usuwanych.

Środowiska wykonawcze takie jak Bun dostarczają więcej funkcjonalności w sposób wbudowany, co dodatkowo zmniejsza potrzebę używania wielu małych pakietów pomocniczych.

Procedura utrzymywania zależności w aktualnym stanie

Jednorazowa zamiana tych bibliotek nie wystarczy; celem jest wyrobienie nawyku, który zapobiega gromadzeniu się kolejnych przestarzałych zależności.

1. Regularnie sprawdzaj plik package.json i uruchamiaj polecenia npm outdated oraz npm audit, aby móc zauważyć ewentualne odchylenia.

Należy preferować wbudowane funkcje platformy, gdy tylko staną się stabilne i będą szeroko wspierane w docelowych środowiskach.

Należy obserwować komunikaty o wycofywaniu funkcji publikowane przez React, Node.js, ESLint oraz administratorów kluczowych bibliotek.

Sytuację „nadal działa” należy traktować jako tymczasową. Ciągłe aktualizacje bezpieczeństwa i wsparcie ekosystemu przeważają nad wygodą pozostawienia wszystkiego bez zmian.

Dla nowych projektów należy domyślnie używać nowoczesnych narzędzi: Vite, wbudowanego fetch, Temporal tam, gdzie jest to możliwe, oraz najnowszych głównych wersji frameworków.

Korzystny kompromis, który należy mieć na uwadze: nie każda zależność z przeszłości wymaga natychmiastowej przepracowania. Stabilne narzędzie wewnętrzne wykorzystujące jQuery lub Webpack może wymagać większych nakładów na migrację, niż kiedykolwiek przyniesie oszczędności. Należy ustalać priorytety według stopnia ekspozycji na zewnętrzne wpływy. Najpierw należy zająć się tym, co nie jest utrzymywane i ma dostęp do sieci, danych wprowadzanych przez użytkownika lub procesu budowania (request, CRA, AWS SDK v2); dalej idą biblioteki o dużej wielkości, takie jak Moment i Lodash; natomiast czysto stylistyczna modernizacja może poczekać.

Główne wnioski

• Pakiety przestarzałe i nieutrzymywane stanowią przede wszystkim problem bezpieczeństwa, a dopiero potem problem wydajności, dlatego migracje należy klasyfikować według poziomu ryzyka.
• Wiele dawnych standardów (Moment, Lodash, jQuery, request) zostało wchłoniętych przez język, DOM lub środowisko wykonawcze, dzięki czemu zamienniki są mniejsze od oryginalnych zależności.

Migracje narzędzi takich jak CRA na Vite zazwyczaj dotyczą konfiguracji, a nie kodu aplikacji.

Rегулярna audytacja oraz użycie nowoczesnych narzędzi przy nowych projektach pomagają utrzymać tę listę krótką w przyszłości.