Rspack, bundler w Rust zgodny z API Webpacka

Rspack, bundler w Rust zgodny z API Webpacka

Rspack to bundler z rdzeniem w Rust, którego konfiguracja celowo powtarza konfigurację Webpacka 5. Wersja 2.1.10 ukazała się 13 sierpnia 2026 roku, licencja to MIT, a projekt rozwija ByteDance. Zgodność jest wysoka, lecz nie pełna, i to właśnie luki w niej decydują, czy migracja zajmie dzień, czy kilka tygodni.

Co to jest i skąd się wzięło

Bundler bierze moduły źródłowe projektu, buduje z nich graf zależności i wypisuje pliki wynikowe dla przeglądarki albo dla Node. Rspack robi dokładnie to samo co Webpack, tyle że graf, transformacje i minifikacja dzieją się w kodzie natywnym. Warstwa konfiguracji, wtyczek i loaderów pozostaje w JavaScripcie, więc z punktu widzenia autora konfiguracji plik rspack.config.mjs wygląda jak webpack.config.js sprzed migracji.

Powód powstania projektu jest opisany w dokumentacji bez owijania. W ByteDance duże aplikacje monolityczne budowały się po dziesięć minut, a w skrajnych przypadkach po pół godziny, zimny start trybu deweloperskiego zajmował kilka minut. Zespół przyjął, że próg akceptowalności dla polecenia uruchamiającego serwer deweloperski to kilkanaście sekund, i zamiast projektować nowy interfejs konfiguracji, przepisał rdzeń pod istniejący. To odróżnia Rspack od Turbopacka, który zaczął od nowej architektury i nowej konfiguracji.

Chronologia jest istotna przy ocenie dojrzałości. Pierwsza paczka 0.0.1 trafiła na npm 6 kwietnia 2022 roku. Wersja 1.0 ukazała się 28 sierpnia 2024 roku i dopiero od niej dokumentacja mówi o gotowości produkcyjnej. Wersja 2.0 wyszła 22 kwietnia 2026 roku, a bieżąca gałąź stabilna to 2.1.x, przy czym w rejestrze widnieje już znacznik rc wskazujący na 2.2.0-rc.0 z 21 sierpnia 2026 roku. Kto nie może jeszcze przejść na dwójkę, ma osobny znacznik latest-v1 wskazujący na 1.7.12.

Repozytorium web-infra-dev/rspack ma około 12,9 tysiąca gwiazdek, 841 rozgałęzień i 139 otwartych zgłoszeń. Dla porównania skali użycia: @rspack/core notuje około 7,2 miliona pobrań tygodniowo, webpack około 46,4 miliona. Te liczby trzeba czytać ostrożnie, bo pobrania z npm w dużej mierze pochodzą z zależności przechodnich w potokach ciągłej integracji, a nie z liczby projektów.

Wersja, licencja i sposób dystrybucji

Licencję sprawdziłem w trzech miejscach i wynik jest zgodny, co przy audycie zależności bywa rzadkością. Plik LICENSE w gałęzi głównej repozytorium zawiera tekst MIT z notą Copyright (c) 2022-present Bytedance Inc and its affiliates. Pole license w rejestrze npm dla @rspack/core@2.1.10 ma wartość MIT. Opublikowana paczka waży około 361 kilobajtów, zawiera 322 pliki, w tym package/LICENSE z tym samym tekstem MIT, oraz realny kod w katalogu dist. To nie jest atrapa rezerwująca nazwę.

Jedna rzecz wymaga uwagi przy skanerze licencji. Katalog compiled w paczce zawiera wbudowane kopie kilku zależności, każda z własnym plikiem licencyjnym: @rspack/lite-tapable, @swc/types, connect-next, http-proxy-middleware, tinypool, watchpack oraz webpack-sources. Skaner, który czyta tylko package.json najwyższego poziomu, tych plików nie zobaczy, choć są one w dostarczanym artefakcie.

Sposób dystrybucji binariów to element, który potrafi zepsuć instalację w zamkniętym środowisku. Sam @rspack/core ma dokładnie jedną zależność zwykłą, @rspack/binding w tej samej wersji, i dwie zależności równorzędne: @swc/helpers w zakresie ^0.5.23 oraz @module-federation/runtime-tools w zakresie ^0.24.1 || ^2.0.0. Cała maszyneria natywna siedzi dopiero w @rspack/binding, który deklaruje 14 zależności opcjonalnych: trzynaście paczek z binariami per platforma i jedną z budowaniem WebAssembly.

Instalacja z flagą pomijającą zależności opcjonalne nie da działającego bundlera, bo zostanie sama warstwa JavaScript bez rdzenia. Na platformie spoza listy dokumentacja każe zainstalować ręcznie @rspack/binding-wasm32-wasi, który jest wolniejszy, ale przenośny. Jeśli firma trzyma lustro rejestru npm z filtrem na paczki opcjonalne, trzeba je odblokować przed pierwszym uruchomieniem, inaczej diagnoza błędu zajmie więcej czasu niż sama migracja.

Wymaganie środowiska w polu engines brzmi ^20.19.0 || >=22.12.0. Node 18 wypadł w wersji 2.0 i nie jest to ostrzeżenie, tylko twarde odrzucenie. Jako środowisko uruchomieniowe dokumentacja wymienia także Deno i Bun.

Co zmieniła wersja 2.0

Skok majora z 22 kwietnia 2026 roku niesie długą listę zmian łamiących zgodność. Poniżej te, które realnie dotykają istniejących konfiguracji, wypisane z notatek wydania, a nie z pamięci.

Paczka przeszła na czysty ESM. Pole type w package.json ma wartość module, a kompilacja CommonJS została usunięta. Mapa exports udostępnia tylko cztery wejścia: ., ./hot/*, ./hot/*.js, ./package.json oraz ./module. Wtyczka albo skrypt budujący, który robił require('@rspack/core'), przestanie działać i wymaga przepisania na import. To jest najczęstsza przyczyna zaskoczenia po podbiciu wersji.

Obsługa CSS jest domyślnie włączona, więc projekt polegający wcześniej na jawnym przełączniku eksperymentalnym dostanie inne zachowanie bez zmiany konfiguracji. Sekcja experiments.rspackFuture zniknęła, a opcja bundlerInfo przeniosła się do output. Opcja incremental awansowała z experiments na poziom główny konfiguracji i, co ważne, jest niezależna od cache, więc cache: false jej nie wyłącza.

Zmieniły się wartości domyślne, które łatwo przeoczyć: chunkLoadingGlobal to teraz rspackChunk, hotUpdateGlobal to rspackHotUpdate, domyślna nazwa polityki trustedTypes to rspack, resolve.roots startuje jako pusta tablica, exportsPresence domyślnie zgłasza błędy, rozszerzenie .wasm wypadło z domyślnej listy rozszerzeń JavaScript, a warunek importu webpack zniknął z domyślnych warunków dla CSS. Zmieniła się też domyślna wartość devtool.

Usunięto kilka rzeczy bez zamiennika w tej samej postaci: experiments.SubResourceIntegrityPlugin, experiments.parallelLoader, experiments.lazyCompilationMiddleware, experiments.outputModule, output.charset, opcje profile oraz stats.profile, przestarzały WarnCaseSensitiveModulesPlugin, opcję sri w HtmlRspackPlugin, metodę getHooks we wtyczkach, a także optimization.removeAvailableModules. Wbudowany kompilator JavaScript przestał czytać plik .swcrc. ProgressPlugin dostaje teraz jeden obiekt z informacjami zamiast listy argumentów. @rspack/dev-server stał się opcjonalną zależnością równorzędną, więc trzeba go zainstalować świadomie.

Warto tu jedno zastrzeżenie. W trakcie prac nad 2.0 pojawiła się zmiana włączająca verbatimModuleSyntax w builtin:swc-loader domyślnie, ale została cofnięta przed wydaniem. Kto czyta surową listę zmian, zobaczy oba wpisy i może wyciągnąć błędny wniosek.

Gdzie kończy się zgodność z Webpackiem

To jest część, dla której czyta się taki tekst. Dokumentacja Rspacka podaje, że spośród pięćdziesięciu najczęściej pobieranych wtyczek Webpacka ponad 85 procent działa albo ma odpowiednik. Tabela zgodności w repozytorium wymienia 56 pozycji i rozkłada je tak:

Osiem pozycji oznaczonych jako niezgodne to critters-webpack-plugin, @ngtools/webpack, @storybook/react-docgen-typescript-plugin, last-call-webpack-plugin, git-revision-webpack-plugin, @cypress/webpack-preprocessor, @intlify/unplugin-vue-i18n oraz webpack-remove-empty-scripts. Ta lista mówi więcej niż procent zgodności. Projekt na Angularze korzystający z @ngtools/webpack nie przejdzie na Rspack przez podmianę bundlera. Projekt z generowaniem dokumentacji komponentów Reacta w Storybooku straci wtyczkę do wyciągania typów. Zestaw testów end to end z preprocesorem Webpacka w Cypressie wymaga innej ścieżki.

Trzy pozycje częściowo zgodne to webpack-assets-manifest, add-asset-html-webpack-plugin i html-webpack-harddisk-plugin, przy czym dwie ostatnie wymagają obecności html-webpack-plugin, który sam w sobie jest zgodny.

Po stronie konfiguracji zgodność też ma dziury. Rspack nie obsługuje resolve.plugins, więc tsconfig-paths-webpack-plugin zastępuje się polem resolve.tsConfig. Interfejs wiersza poleceń nie przyjmuje opcji --progress, --color, --bail ani --output-pathinfo, a ich pozostawienie kończy się błędem Unknown option jeszcze zanim konfiguracja zostanie wczytana. Odpowiednik --color ustawia się przez stats.colors.

Największa różnica strukturalna dotyczy pamięci podręcznej. Kształt opcji jest inny i przepisanie ich jeden do jednego nie zadziała.

// rspack.config.mjs
import path from 'node:path'

export default {
  cache: {
    // w Webpacku byłoby type: 'filesystem'
    type: 'persistent',
    // w Webpacku obiekt z kluczami, tutaj płaska tablica ścieżek
    buildDependencies: [
      path.join(import.meta.dirname, 'rspack.config.mjs'),
      path.join(import.meta.dirname, 'package.json'),
      path.join(import.meta.dirname, 'tsconfig.json')
    ],
    name: 'client',
    version: '1',
    // w Webpacku było to pole snapshot na najwyższym poziomie
    snapshot: {
      immutablePaths: [path.join(import.meta.dirname, 'constant')],
      managedPaths: [path.join(import.meta.dirname, 'node_modules')],
      unmanagedPaths: []
    },
    storage: {
      type: 'filesystem',
      // odpowiednik cache.cacheDirectory z Webpacka
      directory: path.join(import.meta.dirname, 'node_modules/.cache/test'),
      // odpowiednik cache.cacheLocation z Webpacka
      location: path.join(import.meta.dirname, 'node_modules/.cache/test/client')
    }
  },
  // osobna decyzja, cache: false tego nie wyłącza
  incremental: true
}

Wartości cache: false, cache: true i cache: { type: 'memory' } przechodzą wprost. Dopiero pamięć podręczna na dysku wymaga przepisania.

Z loaderami jest lepiej niż z wtyczkami. Dokumentacja mówi o zgodności z niemal wszystkimi loaderami społeczności i to się pokrywa z praktyką, bo interfejs loadera jest prostszy niż interfejs wtyczki. Wyjątkiem jest vue-loader dla Vue 3, który zastępuje się paczką rspack-vue-loader z włączoną opcją experimentalInlineMatchResource. Osobna kategoria to loadery, które opłaca się porzucić, bo rdzeń robi to szybciej.

// rspack.config.mjs
const isDev = process.env.NODE_ENV === 'development'

export default {
  module: {
    rules: [
      {
        test: /\.(?:js|mjs|jsx|ts|tsx)$/,
        exclude: [/[\\/]node_modules[\\/]/],
        use: [
          {
            // zamiast babel-loader z presetami typescript i react
            loader: 'builtin:swc-loader',
            options: {
              detectSyntax: 'auto',
              jsc: {
                transform: {
                  react: {
                    runtime: 'automatic',
                    development: isDev,
                    refresh: isDev
                  }
                }
              }
            }
          }
        ]
      },
      // zamiast file-loader
      { test: /\.(png|jpe?g|gif)$/i, type: 'asset/resource' },
      // zamiast raw-loader
      { test: /^BUILD_ID$/, type: 'asset/source' }
    ]
  }
}

Jeżeli korzystasz z zewnętrznego swc-loader, zmienia się wyłącznie nazwa loadera na builtin:swc-loader, opcje zostają te same. W przypadku paczek z rodziny unplugin, które publikują osobne wejścia dla każdego bundlera, trzeba zamienić import z /webpack na /rspack, na przykład unplugin-auto-import/rspack.

Wbudowane wtyczki Webpacka mają w Rspacku odpowiedniki o tych samych nazwach i parametrach, dostępne przez eksport rspack. Kilka pozycji ma jednak własną nazwę.

// rspack.config.mjs
import { rspack } from '@rspack/core'

export default {
  plugins: [
    new rspack.DefinePlugin({ 'process.env.NODE_ENV': JSON.stringify('production') }),
    // zamiast copy-webpack-plugin
    new rspack.CopyRspackPlugin({ patterns: [{ from: 'public' }] }),
    // zamiast mini-css-extract-plugin
    new rspack.CssExtractRspackPlugin({ filename: '[name].[contenthash].css' }),
    new rspack.HtmlRspackPlugin({ template: './src/index.html' })
  ],
  optimization: {
    minimizer: [
      // zamiast terser-webpack-plugin
      new rspack.SwcJsMinimizerRspackPlugin(),
      // zamiast css-minimizer-webpack-plugin
      new rspack.LightningCssMinimizerRspackPlugin()
    ]
  }
}

Jawne ustawienie optimization.minimizer wyłącza domyślne minifikatory Rspacka, więc na liście trzeba zostawić oba, dla JavaScriptu i dla CSS. Pominięcie drugiego to typowa przyczyna nagłego wzrostu rozmiaru arkuszy stylów po migracji.

Poza wtyczkami do podmiany są też paczki pomocnicze.

Rsbuild, Rslib, Rspress i Rsdoctor

Ten sam zespół wydaje kilka narzędzi z tym samym przedrostkiem i mylenie ich jest nagminne. Rozróżnienie jest proste, gdy raz się je zapamięta.

@rspack/core w wersji 2.1.10 to sam bundler, bez opinii na temat tego, jak ma wyglądać projekt. Konfiguracja jest pełna i długa, dokładnie jak w Webpacku. @rsbuild/core w wersji 2.1.13 z 13 sierpnia 2026 roku to nakładka na Rspack z gotowymi ustawieniami, obsługą TypeScriptu, CSS, obrazów i serwera deweloperskiego bez pisania reguł. Dokumentacja Rspacka wprost poleca Rsbuild do zakładania nowych projektów, a gołego Rspacka do sytuacji, w których potrzebna jest kontrola nad każdym elementem grafu. To jest praktyczna rada, która ginie w większości tekstów o Rspacku.

@rslib/core w wersji 0.23.2 z 3 lipca 2026 roku służy do budowania bibliotek, a nie aplikacji, i sam opisuje się jako narzędzie oparte na Rsbuild. Numer wersji poniżej jedynki jest tu sygnałem, że interfejs może się jeszcze zmieniać. Rspress to generator dokumentacji, przy czym trzeba uważać na nazwę paczki: rspress w rejestrze npm ma wersję 1.47.2 i opis mówiący wprost, że to wycofane narzędzie wiersza poleceń dla wersji pierwszej, a bieżąca dwójka mieszka pod nazwą @rspress/core w wersji 2.0.19. Rsdoctor to analizator kompilacji, podłączany do Rspacka przez @rsdoctor/rspack-plugin w wersji 1.6.3. Wszystkie te paczki są na licencji MIT.

# nowy projekt, ścieżka zalecana dla większości przypadków
npx -y create-rsbuild --dir my-app --template react

# nowy projekt na gołym Rspacku, gdy potrzebna jest pełna konfiguracja
npx -y create-rspack --dir my-app --template react

# migracja istniejącego projektu z Webpacka
npm add -D @rspack/core @rspack/cli @rspack/dev-server

# sprawdzenie, co w projekcie wciąż importuje webpack
grep -rn "require('webpack" src build scripts

# analiza kompilacji
npm add -D @rsdoctor/rspack-plugin

Skrypty w package.json zmieniają się w sposób mechaniczny, z zastrzeżeniem o niewspieranych opcjach wiersza poleceń.

{
  "scripts": {
    "dev": "rspack dev",
    "build": "rspack build --mode production",
    "preview": "rspack preview"
  }
}

Rspack, Vite i esbuild, czyli trzy różne modele

Porównanie ma sens tylko wtedy, gdy zaczniemy od modelu pracy, bo to on decyduje o wyniku, a nie język implementacji.

Vite w trybie deweloperskim nie pakuje aplikacji. Serwuje moduły natywne przeglądarce i przekształca pojedyncze pliki na żądanie, więc czas startu jest w dużej mierze niezależny od wielkości projektu. Rspack pakuje zawsze, tak jak Webpack, tylko robi to w kodzie natywnym i z przyrostową rekompilacją przy podmianie modułu. Konsekwencja jest taka, że przy bardzo dużej aplikacji Vite wystartuje szybciej, a Rspack da to samo zachowanie w trybie deweloperskim i produkcyjnym, bez klasy błędów widocznych tylko po zbudowaniu paczki.

esbuild to inny przypadek. Jest szybszy od obu, ale jego zakres funkcji jest węższy: dokumentacja Rspacka wskazuje brak podmiany modułów na gorąco oraz brak odpowiednika optimization.splitChunks. W praktyce esbuild bywa cegiełką wewnątrz większego narzędzia, a nie samodzielnym bundlerem aplikacji z rozbudowanym dzieleniem paczek.

Liczby pobrań w ostatnim wierszu są mocno zaburzone przez zależności przechodnie, esbuild jest wciągany przez dziesiątki narzędzi, a Vite przez frameworki. Nie traktuj ich jako miary popularności wśród ludzi.

Kryterium wyboru jest więc dość ostre. Masz istniejącą konfigurację Webpacka, której nie chcesz przepisywać, i zależy ci na czasie budowania? Rspack. Zaczynasz od zera i nie masz starych zobowiązań? Vite albo Rsbuild, w zależności od tego, po której stronie ekosystemu wolisz siedzieć. Budujesz małą bibliotekę albo narzędzie, gdzie liczy się goła szybkość, a dzielenie paczek nie występuje? esbuild.

Typowe błędy przy migracji

Kilka pułapek powtarza się w niemal każdym przejściu i wszystkie mają wspólny mianownik, czyli założenie, że skoro konfiguracja jest zgodna, to zgodne jest wszystko.

Pierwsza to pozostawienie opcji wiersza poleceń. Skrypt z --progress --color przestanie działać z komunikatem Unknown option, zanim ktokolwiek spojrzy na konfigurację, a komunikat nie podpowiada, że chodzi o zgodność bundlerów.

Druga to przepisanie cache jeden do jednego. Wartość type: 'filesystem' nie istnieje w Rspacku, buildDependencies ma inny kształt, a snapshot zmienił miejsce. Do tego incremental jest niezależne od cache, więc próba wyłączenia wszystkich mechanizmów ponownego użycia przez samo cache: false niczego nie wyłączy do końca.

Trzecia to require w kodzie narzędziowym. Paczka jest czystym ESM od wersji 2.0, więc własna wtyczka albo skrypt budujący, który ładował @rspack/core przez require, wywali się przy pierwszym uruchomieniu. Ten sam problem dotyczy wtyczek społeczności, które nie zostały jeszcze zaktualizowane.

Czwarta to zapomnienie o drugim minifikatorze. Podanie samego SwcJsMinimizerRspackPlugin w optimization.minimizer wyłącza domyślne minifikatory, w tym ten dla CSS, i arkusze stylów wyjeżdżają nieskompresowane.

Piąta to niedoszacowanie starych paczek pomocniczych. Dokumentacja wymienia webpack-node-externals i node-polyfill-webpack-plugin jako przykłady, gdzie potrzebna jest nowsza wersja, bo starsze opierają się na wewnętrznych elementach Webpacka. Zanim uznasz paczkę za niezgodną, sprawdź, czy nie wystarczy jej podnieść.

Szósta to usunięcie zależności webpack zbyt wcześnie. Dopóki jakikolwiek loader, wtyczka albo skrypt importuje webpack lub webpack/lib/*, paczka musi zostać w projekcie jako zależność zgodności. Sprzątanie robi się na końcu, nie na początku.

Wady, ryzyka i kiedy nie warto

Ekosystem jest mniejszy niż w Webpacku i to nie jest kwestia procentu w tabeli, tylko ogona. Popularne wtyczki są pokryte, ale im bardziej niszowa potrzeba, tym większa szansa, że trafisz na paczkę bez odpowiednika i będziesz musiał napisać własną. Osiem pozycji oznaczonych jako niezgodne w oficjalnej tabeli to zbiór, który każdy powinien przejrzeć przed decyzją, bo jedna pozycja z tej listy potrafi zablokować migrację.

Zależność od jednej firmy jest realna. Rspack, Rsbuild, Rslib, Rspress i Rsdoctor pochodzą z tego samego zespołu w ByteDance. Kod jest na MIT, więc nikt niczego nie zabierze, ale tempo rozwoju, priorytety i wsparcie dla nowych funkcji zależą od decyzji jednego pracodawcy. To inny profil ryzyka niż przy Webpacku, którego utrzymanie jest rozproszone, i inny niż przy Vite z fundacją wokół projektu.

Binaria natywne per platforma to koszt operacyjny. Czternaście paczek opcjonalnych oznacza więcej rzeczy do zlustrzenia w prywatnym rejestrze, większy rozmiar warstw obrazu kontenerowego przy nieuważnym budowaniu i osobną ścieżkę awaryjną na WebAssembly dla platform spoza listy. Ten sam kompromis dotyczy zresztą innych narzędzi natywnych, na przykład Biome czy oxlint.

Tempo zmian też ma cenę. Między wydaniem 1.0 w sierpniu 2024 a 2.0 w kwietniu 2026 minęło niecałe dwadzieścia miesięcy, a lista zmian łamiących zgodność w dwójce jest długa. Kto trzyma kilkanaście projektów w monorepozytorium spiętym Turborepo, musi liczyć się z tym, że kolejny major wymusi podobną rundę poprawek.

Rspack nie sprawdza typów. Tak jak Webpack ze swc-loader albo esbuild-loader, transformuje TypeScript przez wycinanie typów, więc tsc --noEmit zostaje w potoku albo dokłada się ts-checker-rspack-plugin, zamiennik dla fork-ts-checker-webpack-plugin. To samo dotyczy lintowania, które trzeba uruchomić osobno.

Kiedy nie warto sięgać po Rspack? Gdy projekt nie ma konfiguracji Webpacka do uratowania, bo wtedy płacisz za zgodność, z której nie skorzystasz. Gdy zależysz od którejś z niezgodnych wtyczek i nie masz budżetu na obejście. Gdy budowanie i tak trwa kilkanaście sekund, bo oszczędność będzie niemierzalna wobec ryzyka. I gdy zespół nie ma nikogo, kto rozumie konfigurację Webpacka na tyle, żeby zdiagnozować różnicę w zachowaniu, bo komunikaty błędów z warstwy natywnej bywają mniej czytelne niż te z czystego JavaScriptu.

FAQ

Czy istniejąca konfiguracja Webpacka zadziała bez zmian?

Zwykle nie w stu procentach. Zmiana nazwy pliku na rspack.config.js i podmiana importów wbudowanych wtyczek załatwia większość, ale trzeba osobno przepisać cache, usunąć niewspierane opcje wiersza poleceń, zastąpić resolve.plugins polem resolve.tsConfig i sprawdzić wtyczki społeczności w oficjalnej tabeli zgodności.

Czy wtyczki napisane dla Webpacka działają w Rspacku?

Część tak, część wymaga odpowiednika. W tabeli zgodności na 56 wymienionych pozycji 28 działa bez zmian, 5 zastąpił rdzeń, 12 ma dedykowany zamiennik, 3 działają częściowo, a 8 nie działa wcale. Loadery są pokryte znacznie lepiej niż wtyczki, bo ich interfejs jest prostszy.

Rspack czy Rsbuild?

Rsbuild do nowych projektów, bo daje gotową konfigurację dla TypeScriptu, CSS i serwera deweloperskiego. Goły Rspack wtedy, gdy migrujesz istniejącą konfigurację Webpacka albo potrzebujesz kontroli nad każdym elementem procesu budowania. Rsbuild jest zbudowany na Rspacku, więc nie jest to wybór między konkurentami.

Co zepsuła wersja 2.0?

Najbardziej dotkliwe jest przejście na czysty ESM i porzucenie Node 18. Poza tym CSS włączony domyślnie, incremental przeniesione na poziom główny i niezależne od cache, zmienione wartości domyślne chunkLoadingGlobal, hotUpdateGlobal, resolve.roots, exportsPresence i devtool, usunięcie kilku opcji z sekcji experiments oraz koniec czytania pliku .swcrc.

Czy Rspack sprawdza typy TypeScriptu?

Nie. Typy są wycinane bez weryfikacji, więc kontrola typów zostaje po stronie tsc --noEmit albo ts-checker-rspack-plugin. To standardowe zachowanie bundlerów opartych na SWC i esbuild, nie osobliwość Rspacka.

Co się stanie przy instalacji bez zależności opcjonalnych?

Nie dostaniesz działającego bundlera. Rdzeń natywny jest publikowany jako 14 paczek opcjonalnych @rspack/binding-*, po jednej na platformę plus wariant WebAssembly. Instalacja z pominięciem zależności opcjonalnych zostawi samą warstwę JavaScript, a w zamkniętym rejestrze trzeba te paczki zlustrzeć osobno.