Rsbuild - szybki build bez skomplikowanej konfiguracji

W wielu firmach jest plik, którego nikt nie chce dotykać. Nazywa się webpack.config.js, ma kilkaset linii, a osoba, która go napisała, pracuje już gdzie indziej. Działa, więc zostaje. Do dnia, w którym trzeba zaktualizować jedną z bibliotek.

Rsbuild to szybki build bez skomplikowanej konfiguracji: narzędzie, które przygotowuje aplikację frontendową do uruchomienia w przeglądarce i robi to z rozsądnymi ustawieniami od razu. Build to proces, w którym setki plików źródłowych zamieniają się w kilka zoptymalizowanych paczek gotowych do wdrożenia. Rsbuild robi go na Rspacku, bundlerze napisanym w języku Rust, więc szybko.

Konfiguracja builda to koszt, którego nie widać w wycenie

Przez lata standardem był webpack jako narzędzie do budowania aplikacji. Potrafi wszystko, ale niczego nie robi sam. Obsługę TypeScriptu, stylów, obrazków, zmiennych środowiskowych i podziału kodu trzeba skonfigurować ręcznie, zwykle z pomocą kilkunastu dodatkowych pakietów. Na tym zbudowano Create React App, czyli gotowy zestaw, który ukrywał konfigurację webpacka przed programistą. Wygoda kończyła się przy pierwszej nietypowej potrzebie. Wtedy zespół albo „wypakowywał” całą konfigurację do projektu i odtąd utrzymywał ją sam, albo dokładał nakładki w rodzaju CRACO, które modyfikowały ustawienia z zewnątrz.

W obu przypadkach powstaje wiedza, którą ma jedna lub dwie osoby w zespole. Każda aktualizacja zależności zamienia się w dzień szukania, która z trzydziestu opcji przestała działać. To klasyczny dług technologiczny w projekcie: nikt go nie zaciągał świadomie, a spłaca go każdy kolejny sprint.

Do tego dochodzi czas. Duża aplikacja na webpacku potrafi startować w trybie deweloperskim kilkanaście sekund, a zmiana w kodzie pojawia się na ekranie po dwóch, trzech sekundach. Kilkudziesięciu takich przerw dziennie programista już nie zauważa. Firma płaci za nie tak czy inaczej.

Rsbuild, czyli szybki build bez skomplikowanej konfiguracji

Rsbuild powstał w tym samym zespole ByteDance co Rspack i jest jego nakładką. Rspack to silnik, który łączy pliki w paczki. Rsbuild to warstwa nad nim, która wie, jak typowa aplikacja webowa powinna być zbudowana, i ustawia to sama. W praktyce projekt w Rsbuild zaczyna się od kilku linii konfiguracji. Do aplikacji w React dodaje się jedną wtyczkę, do aplikacji w Vue.js inną. Obsługiwane są też Svelte, Solid i Preact. Reszta działa od razu. Pod spodem pracują narzędzia napisane w Rust: Rspack do łączenia modułów, SWC do przekształcania kodu i Lightning CSS do przetwarzania stylów. Programista nie musi ich znać ani konfigurować. Musi wiedzieć tylko, że są.

Projekt jest otwarty, rozwijany aktywnie i szybko zyskuje użytkowników. Według zapowiedzi Rsbuild 2.0 z kwietnia 2026 r. liczba tygodniowych pobrań wzrosła ponad piętnastokrotnie od wersji 1.0, a sama paczka ma dziś 4 zależności zamiast 13. Mniej zależności to mniej aktualizacji i mniej miejsc, w których coś może się zepsuć.

Co Rsbuild robi od razu, a co trzeba dopisać

Większość rzeczy, które w webpacku wymagają osobnego pakietu i kilku linii konfiguracji, w Rsbuild działa po instalacji. Należą do nich:

• obsługa TypeScriptu i składni JSX bez dodatkowych kompilatorów,
• style w CSS i CSS Modules, czyli style przypisane do jednego komponentu, a Sass i Less przez oficjalne wtyczki,
• obrazki, czcionki i inne pliki statyczne,
• zmienne środowiskowe dla wersji testowej i produkcyjnej,
• serwer deweloperski z podmianą zmienionego kodu bez przeładowania strony (HMR),
• podział kodu na mniejsze paczki i usuwanie nieużywanych fragmentów.

Dwa ostatnie punkty mają bezpośredni wpływ na użytkownika. Code splitting sprawia, że przeglądarka pobiera tylko kod potrzebny na danym ekranie. Rsbuild ustawia go domyślnie według sprawdzonych zasad, a zespół może je zmienić, jeśli ma dobry powód.

Rsbuild nie uruchamia za to testów ani nie sprawdza jakości kodu. Do tego zespół Rsbuild rozwija osobne narzędzia, Rstest do testów i Rslint do analizy kodu, ale można też zostać przy dotychczasowych, takich jak Jest czy ESLint. Nie sprawdza też typów w TypeScripcie, tylko je usuwa. Kontrolę typów warto więc uruchamiać osobno, na przykład przy każdej zmianie w repozytorium. Rsbuild ma też system wtyczek zgodny z wieloma wtyczkami webpacka i Rspacka. Gdy projekt potrzebuje czegoś nietypowego, zwykle istnieje gotowe rozwiązanie. Z Rsbuildem działa również Storybook do budowania i dokumentowania komponentów, co ma znaczenie w projektach z własną biblioteką interfejsu.

Liczby: Rsbuild, Vite i webpack na tym samym projekcie

Zespół Rstack utrzymuje publiczne porównanie narzędzi do budowania, w którym te same aplikacje buduje się różnymi narzędziami. Autorami są twórcy Rsbuilda, więc wyniki warto czytać ostrożnie. Ich zaletą jest to, że kod testów jest otwarty, a wyniki obejmują też kategorie, w których Rsbuild przegrywa.

Dla aplikacji w React z 5 tysiącami komponentów wyniki wyglądają tak. Serwer deweloperski startuje w Rsbuild w około 1 sekundę, w Vite 8 w 3,8 sekundy, w webpacku w 12,6 sekundy. Zmiana w kodzie pojawia się na ekranie po 120 milisekundach w Rsbuild, 144 w Vite i 2,7 sekundy w webpacku. W budowaniu wersji produkcyjnej bez pamięci podręcznej najszybszy jest Vite: 1,3 sekundy wobec 2,1 sekundy w Rsbuild i 13,1 sekundy w webpacku. Z włączoną pamięcią podręczną Rsbuild i Vite są prawie równe. Rozmiar plików po kompresji różni się o kilka procent i przy takiej skali nie ma znaczenia dla użytkownika.

Z tych liczb wynika jeden praktyczny wniosek. Rsbuild i Vite są dziś w tej samej lidze, a różnica między nimi to ułamki sekund. Różnica między każdym z nich a webpackiem to rząd wielkości. Firma z aplikacją na webpacku zyska na przejściu na którekolwiek z nich, a to, które wybrać, zależy od innych czynników niż czas. Krótszy build to też mniej minut płaconych za maszyny w potoku CI/CD, który buduje aplikację przy każdej zmianie.

Rsbuild a Vite: czym się naprawdę różnią

Vite jako narzędzie do budowania frontendu jest dziś najpopularniejszym wyborem dla nowych projektów. Ma ogromny ekosystem wtyczek, a na nim opierają się frameworki takie jak Nuxt czy SvelteKit. Jeśli zespół zna Vite i jest z niego zadowolony, nie ma powodu go zmieniać.

Rsbuild ma przewagę w dwóch sytuacjach. Pierwsza to projekty, które przychodzą z webpacka. Rsbuild rozumie wiele wtyczek i loaderów webpacka, więc część dotychczasowych rozwiązań można przenieść zamiast szukać odpowiedników. Przy przejściu na Vite trzeba zwykle przepisać cały proces budowania. Druga to Module Federation, czyli mechanizm, dzięki któremu kilka niezależnie wdrażanych aplikacji współdzieli komponenty w przeglądarce. Firmy z architekturą mikrofrontendów zbudowaną na webpacku mają w Rsbuild najkrótszą drogę do szybszego builda.

Twórcy Rsbuild podkreślają jeszcze jedną różnicę. Rsbuild używa tego samego bundlera podczas pracy programisty i przy budowaniu wersji produkcyjnej, więc aplikacja zachowuje się w obu miejscach tak samo. Vite do wersji 7 używał do tego dwóch różnych narzędzi. Od wersji 8 i przejścia na Rolldown ta różnica w dużej mierze zniknęła.

Przejście z Create React App na Rsbuild

Create React App nie jest już rozwijany. W lutym 2025 r. zespół React ogłosił wycofanie Create React App i zalecił przejście na framework albo na narzędzie do budowania, wymieniając wśród nich Vite, Parcel i Rsbuild. Projekty, które zostały na CRA, z czasem dostają coraz więcej ostrzeżeń o przestarzałych zależnościach.

Dla takich aplikacji Rsbuild jest wygodnym celem, bo ma oficjalny przewodnik migracji z Create React App. Przejście wygląda zwykle tak:

1. Usunięcie pakietu react-scripts, a jeśli projekt go używa, także CRACO.
2. Instalacja Rsbuild z wtyczką do React i utworzenie krótkiego pliku konfiguracji.
3. Wskazanie szablonu HTML i ustawienie folderu wynikowego na „build”, żeby nie zmieniać procesu wdrożenia.
4. Obsługa zmiennych środowiskowych z prefiksem REACT_APP_, które w Rsbuild domyślnie mają prefiks PUBLIC_.
5. Przeniesienie nietypowych ustawień z CRACO na wtyczki Rsbuild i sprawdzenie aplikacji w testach.

Prosta aplikacja bez nadpisanej konfiguracji przechodzi zwykle w jeden, dwa dni robocze, łącznie ze sprawdzeniem wersji produkcyjnej. Projekt z rozbudowanym CRACO, własnymi wtyczkami Babela i kilkoma środowiskami to raczej od tygodnia do trzech. Najwięcej czasu zajmują nie same ustawienia, tylko nietypowe rozwiązania, o których nikt już nie pamięta.

Jeśli migracja ma objąć więcej niż sam build, na przykład aktualizację Reacta, bibliotek i sposobu wdrażania, lepiej zaplanować ją jako jeden projekt migracji aplikacji do nowych technologii. Kilka mniejszych zmian robionych osobno trwa w sumie dłużej.

Kiedy Rsbuild nie jest dobrym wyborem

Nie przy aplikacjach na Next.js. Framework Next.js ma własny proces budowania. Od wersji 16 Next.js domyślnie korzysta z Turbopacka rozwijanego przez Vercel. Podobnie jest z Nuxtem czy Astro, które opierają się na Vite. W takich projektach bundler przychodzi razem z frameworkiem i nie ma sensu go podmieniać. Nie wtedy, gdy aplikacja potrzebuje renderowania po stronie serwera, trasowania i pobierania danych w jednym pakiecie. Rsbuild buduje aplikację, ale nie jest frameworkiem. Do sklepu internetowego czy serwisu, w którym liczy się SEO, lepiej od razu wybrać framework, który ma te funkcje wbudowane. Nie ma też sensu przepisywać projektu, który działa dobrze na Vite. Zysk będzie niewielki, a koszt zmiany realny.

Rsbuild sprawdza się najlepiej w aplikacjach, które działają w przeglądarce po zalogowaniu, takich jak panele administracyjne czy platformy SaaS. Tam SEO nie ma znaczenia, a kod rośnie latami. Dobrze pasuje też do monorepo z wieloma aplikacjami, gdzie jedna konfiguracja obsługuje kilka projektów, a zestaw narzędzi Rstack ma osobne narzędzie, Rslib, do budowania bibliotek współdzielonych.

Wybór narzędzia do budowania to mała część tworzenia aplikacji webowych, ale wraca przy każdej aktualizacji.