Rolldown, bundler w Rust zamiast Rollupa

Rolldown, bundler w Rust zamiast Rollupa

Rolldown to bundler napisany w Rust, który udostępnia interfejs wtyczek Rollupa i zakres funkcji zbliżony do esbuild. Bieżąca wersja to 1.2.5 z 19 sierpnia 2026 roku, licencja to MIT, a repozytorium rolldown/rolldown ma około 13,9 tysiąca gwiazdek. Od wersji 8 jest domyślnym i jedynym bundlerem w Vite.

Co Rolldown właściwie robi

Zakres jest węższy, niż sugeruje określenie "narzędzie budujące". Rolldown bierze graf modułów, rozwiązuje importy, usuwa nieużywany kod i zapisuje fragmenty wyjściowe. Nie ma serwera deweloperskiego, nie ma podmiany modułów na gorąco w samodzielnym trybie, nie ma uruchamiania testów.

Od Rollupa różni go to, co siedzi w środku bez wtyczek. Transformacja TypeScriptu i JSX jest wbudowana i idzie przez Oxc, razem z obniżaniem składni w dół do ES2015. Rozwiązywanie modułów robi oxc-resolver, zgodny z zachowaniem Node i TypeScriptu, i czyta compilerOptions.paths z pliku wskazanego opcją tsconfig. Mieszany graf modułów ESM i CommonJS działa bez @rollup/plugin-commonjs, według semantyki esbuild. Do tego dochodzą transform.define, transform.inject oraz minifikator z rodziny Oxc.

W praktyce oznacza to, że pięć popularnych wtyczek Rollupa przestaje być potrzebnych: @rollup/plugin-alias zastępuje opcja resolve.alias, @rollup/plugin-node-resolve i @rollup/plugin-commonjs funkcje wbudowane, @rollup/plugin-inject opcja transform.inject, a @rollup/plugin-json obsługa JSON w rdzeniu.

Czego Rolldown nie robi, jest równie ważne przy planowaniu potoku. Nie sprawdza typów, więc tsc --noEmit zostaje osobnym krokiem, tak samo jak przy TypeScript w każdym innym układzie. Nie generuje plików deklaracji; dokumentacja odsyła autorów bibliotek do tsdown, a w rejestrze npm istnieje osobna wtyczka rolldown-plugin-dts w wersji 0.28.2. Nie podstawia wbudowanych modułów Node przy platform: 'browser', co trzeba dołożyć wtyczką rolldown-plugin-node-polyfills. Nie sprawdza stylu kodu, od tego są oxlint i Biome. Nie zarządza pamięcią podręczną monorepozytorium, czym zajmuje się Turborepo.

Wersja, licencja i stan projektu

Numer wersji i deklarowana gotowość rozjeżdżają się przy tej klasie narzędzi tak często, że trzeba to sprawdzić osobno. Tutaj się nie rozjeżdżają, ale kontrakt jest węższy, niż sugeruje słowo "stabilny".

Rolldown 1.0 ukazał się 7 maja 2026 roku i ogłoszenie mówi wprost o stabilności i gotowości produkcyjnej. Zakres ^1.0.0 jest zamrożony: nazwy opcji, typy i sygnatury punktów zaczepienia wtyczek pozostają zgodne wstecz. Wyjątek dotyczy funkcji oznaczonych jako eksperymentalne, a dokumentacja opcji experimental formułuje to bez owijania: te funkcje mogą zmienić zachowanie bez podbicia wersji głównej.

Drugie zastrzeżenie jest istotniejsze dla kogoś, kto wstawia Rolldown w środek potoku budowania. Ogłoszenie 1.0 zapowiada, że kształt wyniku będzie się dalej zmieniał: heurystyki usuwania martwego kodu, podziału na fragmenty i wstawiania stałych będą ulepszane, a domyślne wartości opcji mogą się przesuwać w wydaniach pobocznych. Autorzy piszą, że nie zmienia to zachowania wygenerowanego kodu w czasie działania, i tak trzeba to czytać: interfejs jest zamrożony, liczba i nazwy plików wyjściowych nie.

Wydania wychodzą gęsto. Wersje od 1.2.0 do 1.2.5 ukazały się między 15 lipca a 19 sierpnia 2026 roku, czyli mniej więcej co tydzień. Ostatnia zmiana w gałęzi głównej pochodzi z 21 sierpnia 2026 roku, repozytorium ma około tysiąca rozgałęzień, 256 otwartych zgłoszeń i 131 otwartych propozycji zmian.

Licencja wygląda tak samo z trzech niezależnych stron, co przy narzędziach tej klasy nie jest regułą. Plik LICENSE w repozytorium i w opublikowanej paczce zawiera pełny tekst MIT z notą "Copyright (c) 2024-present VoidZero Inc. & Contributors". Pole license w rejestrze npm ma wartość MIT. Rozpakowana paczka rolldown@1.2.5 zawiera dokładnie pięć pozycji: LICENSE, README.md, THIRD-PARTY-LICENSE, katalog bin i katalog dist, w sumie około 839 kilobajtów samego JavaScriptu. Plik THIRD-PARTY-LICENSE to teksty MIT Rollupa z 2017 roku i esbuild z 2020 roku, od Evana Wallace'a, bo fragmenty obu projektów zostały przepisane. Nie ma tu podziału licencji, progu przychodowego ani daty przekształcenia. Całość jest permisywna, wraz z prawem do redystrybucji.

Kod natywny leży poza tą paczką. Rolldown deklaruje piętnaście zależności opcjonalnych z binariami, przypiętych dokładnie do 1.2.5, po jednej na platformę. Sam binarny pakiet @rolldown/binding-darwin-arm64 zajmuje po rozpakowaniu 17 070 467 bajtów, czyli około 17,1 megabajta, więc realna instalacja to nie 839 kilobajtów, tylko blisko 18 megabajtów na jedną platformę. Instalacja z pominięciem zależności opcjonalnych nie da działającego programu.

W rejestrze wisi 29 wersji oznaczonych jako wycofane, wszystkie z komunikatem legacy versions, a najstarsza z nich, 0.1.0, pochodzi z 1 stycznia 2017 roku, czyli sprzed powstania obecnego projektu. Nazwa została po starszym, niezwiązanym pakiecie. Na znaczniku latest nie wisi żadna wersja wycofana, wskazuje on na 1.2.5. Pole engines wymaga Node w wersji ^20.19.0 || >=22.12.0, dokładnie tak samo jak Vite 8.

Osobna sprawa to wydanie Rolldowna jako biblioteki Rust. Dokumentacja podaje trzy zasady i wszystkie są odstraszające: crate'y nie trzymają się semantycznego wersjonowania i mogą wprowadzać zmiany łamiące w dowolnym wydaniu, dokumentacja dla nich nie powstaje, a zgłoszenia dotyczące wyłącznie ich są zamykane. Punktem odniesienia jest pakiet npm.

Wariantu płatnego nie ma i nie ma cennika do sprawdzenia. VoidZero, firma stojąca za projektem, sprzedaje osobny produkt o nazwie Vite+, będący w fazie beta, a jej strona główna nie publikuje żadnych cen w surowym HTML. Na tej samej stronie wisi ogłoszenie o przejściu VoidZero do Cloudflare, co przy narzędziu w rdzeniu potoku budowania jest informacją o właścicielu, a nie o funkcjach.

Rolldown, rolldown-vite i Vite 8

Trzy nazwy krążą razem i mieszają się w opisach z 2025 roku. To trzy różne pakiety w rejestrze npm i tylko jeden z nich warto dziś instalować świadomie.

Pakiet rolldown to samodzielny bundler, opisywany w tym tekście, w wersji 1.2.5. Instalujesz go, gdy budujesz bibliotekę albo pakujesz kod bez Vite.

Pakiet rolldown-vite był tymczasowym wariantem Vite z podmienionym bundlerem, opublikowanym w maju 2025 roku jako zapowiedź techniczna, żeby zebrać zgłoszenia przed właściwą podmianą. Rozwój zatrzymał się na wersji 7.3.1 z 9 stycznia 2026 roku. Istotniejsze jest to, czego nie widać w numerze: wszystkie 92 wersje tego pakietu są w rejestrze oznaczone jako wycofane, a komunikat przy 7.3.1 brzmi, że pakiet służy wyłącznie do migracji z Vite 7 na Vite 8. Do nowego projektu nie ma po co po niego sięgać.

Pakiet vite od wersji 8.0.0 z 12 marca 2026 roku ma Rolldown jako bundler domyślny i jedyny, bez flagi włączającej. Warto prześledzić daty, bo mówią więcej niż deklaracje: Vite 8.0.0 miał w zależnościach rolldown w wersji 1.0.0-rc.9, czyli stabilne Vite 8 wyszło osiem tygodni przed stabilnym Rolldownem i przez ten czas miliony projektów budowały się na kandydacie do wydania. Bieżące Vite 8.2.2 z 20 sierpnia 2026 roku deklaruje rolldown w zakresie ~1.2.4.

Z tego zakresu wynika praktyczna pułapka. Rolldown jest zwykłą zależnością Vite, a nie zależnością równorzędną, więc instalując Vite dostajesz konkretną kopię bundlera. Dodanie rolldown do devDependencies obok Vite 8.2.2 zadziała bez konfliktu tylko dla 1.2.4 i 1.2.5, bo tyle dopuszcza ~1.2.4. Przypięcie 1.1.x da w drzewie dwie kopie bundlera i dwa komplety binariów natywnych, a wtyczki nadal będą wykonywane przez tę, którą wybrało Vite. Sam Rolldown nie deklaruje żadnych zależności równorzędnych. Robią to za to wtyczki wokół niego: rolldown-plugin-dts w wersji 0.28.2 wymaga rolldown w zakresie ^1.2.0, więc nie zadziała na gałęzi 1.1.

Zgodność z Rollupem i jej granice

Dokumentacja mówi o interfejsie "prawie w pełni zgodnym", a to sformułowanie jest bezużyteczne bez wykazu. Wykaz istnieje i jest krótki.

Nieobsługiwane punkty zaczepienia to trzy pozycje. Z fazy budowania odpada shouldTransformCachedModule. Z fazy generowania wyniku odpadają resolveImportMeta i renderDynamicImport. Każdy ma otwarte zgłoszenie w repozytorium, odpowiednio 4389, 1010 i 4532.

W kontekście wtyczki brakuje trzech rzeczy, które Rollup udostępnia: nie ma cache, nie ma setAssetSource i nie ma getWatchFiles. Reszta jest na miejscu, łącznie z this.meta, emitFile, load, resolve, parse, getModuleIds, getModuleInfo i addWatchFile.

Cztery różnice zachowania kosztują więcej niż brakujące punkty zaczepienia, bo nie wywołują błędu, tylko cichą zmianę wyniku. Po pierwsze, każde wyjście jest generowane osobno, więc punkt outputOptions wywołuje się przed punktami fazy budowania, odwrotnie niż w Rollupie, a same punkty budowania wykonują się dla każdego wyjścia. Po drugie, closeBundle wywołuje się wyłącznie wtedy, gdy przynajmniej raz wywołano generate() albo write(). Po trzecie, w trybie obserwowania zmian punkt options wywołuje się raz, przy tworzeniu obserwatora, a nie przy każdym przebudowaniu. Po czwarte, writeBundle jest domyślnie sekwencyjny, więc wtyczki ustawiające sequential: true niczego już tym nie zmieniają.

Piąta różnica dotyczy map źródeł i psuje budowanie od razu. Rollup nie sprawdza mapy wtyczki względem jej własnych pól sources i names; odwzorowanie wskazujące na nieistniejące źródło jest po cichu pomijane. Rolldown sprawdza każdy indeks przy konwersji do reprezentacji wewnętrznej, więc mapa akceptowana przez Rollupa potrafi przerwać budowanie komunikatem:

Failed to convert json sourcemap to struct
Reference to non-existing source at position 1

Osobna pułapka dotyczy wtyczek działających w punkcie transform. Wewnętrzna transformacja TypeScriptu i JSX do JavaScriptu zachodzi po tych punktach, a nie przed nimi, więc wtyczka dostaje kod ze składnią TypeScriptu. Wyjścia są dwa: this.parse z opcją lang, albo funkcja transform z rolldown/utils, przy czym ta druga kosztuje dodatkowe przetworzenie.

Odsyłacze do plików mają nowy przedrostek. Emitowane zasoby referuje się przez import.meta.ROLLDOWN_FILE_URL_referenceId, a import.meta.ROLLUP_FILE_URL_referenceId jest przyjmowany jako alias zgodności.

Czy istnieje oficjalna lista niedziałających wtyczek, taka jak wykaz ośmiu wtyczek Webpacka utrzymywany przy Rspacku? Nie w tej formie. Jest zgłoszenie numer 819 zatytułowane "[Tracking] Rollup Plugin Compat Status", ale zostało otwarte w kwietniu 2024 roku i zamknięte jako niezaplanowane, a jego treść jest dziś myląca: wymienia resolveFileUrl i this.meta jako nieobsługiwane, choć dokumentacja wersji 1.2.5 opisuje oba jako działające, i mówi o minifikacji jako pracy w toku, choć opcja output.minify jest udokumentowana. Jedyny aktualny wykaz niezgodności to sekcje "Unsupported Hooks" i "Notable Differences from Rollup" na stronie Plugin API. Brak utrzymywanej listy wtyczek to realna luka: sprawdzenie własnego zestawu wtyczek spada na Ciebie.

Po co to komu, skoro jest esbuild

Odpowiedź nie brzmi "bo szybciej". Brzmi "bo jeden potok zamiast dwóch".

Vite do wersji 7 włącznie miało podzieloną pracę. esbuild wstępnie pakował zależności i przekształcał TypeScript oraz JSX w trybie deweloperskim, a Rollup budował paczkę produkcyjną. Dawało to dwa parsery, dwa mechanizmy rozwiązywania modułów, dwa systemy wtyczek i warstwę kodu spinającego całość. Konsekwencją była cała klasa zgłoszeń "działa lokalnie, psuje się po zbudowaniu", bo kod w trybie deweloperskim przechodził przez inne narzędzie niż kod produkcyjny. Wtyczki napisane pod Rollupa nie brały udziału we wstępnym pakowaniu zależności, a wtyczki esbuild nie brały udziału w budowaniu produkcyjnym.

Rolldown zastępuje oba narzędzia jednym. To jest sedno, a przyspieszenie jest efektem ubocznym wyboru języka. Dla zespołu, który utrzymuje własne wtyczki, znaczy to tyle, że jeden zestaw punktów zaczepienia obsługuje obie fazy.

Zostaje pytanie, dlaczego nie samo esbuild w obu rolach. Powód jest ekosystemowy: esbuild ma własny, wąski interfejs wtyczek i mniej kontroli nad podziałem na fragmenty, a wtyczki Vite od lat pisze się pod interfejs Rollupa. Rolldown bierze interfejs wtyczek z Rollupa, zakres funkcji z esbuild i dokłada rzeczy, których żaden z nich nie ma, w tym ręczne dzielenie na fragmenty w stylu webpacka przez output.codeSplitting.groups.

Liczby wypada podać z zaznaczeniem źródła, bo pochodzą od autorów. Benchmark z repozytorium rolldown/benchmarks, uruchamiany na maszynie ubuntu-latest, z danymi opisanymi datą 21 grudnia 2025 roku, pakuje 19 tysięcy modułów, czyli 10 tysięcy komponentów React w JSX i 9 tysięcy plików JavaScript z zestawu iconify, z minifikacją i mapami źródeł. Wyniki: Rolldown 1,61 sekundy, esbuild 1,70 sekundy, Rspack 4,07 sekundy, para Rollup plus esbuild 40,10 sekundy. To około 25 razy szybciej od układu, który Vite miało wcześniej, i około 5 procent szybciej od esbuild. Dokumentacja podaje w innym miejscu przedział od 10 do 30 razy szybciej od samego Rollupa, i te dwie liczby opisują różne konfiguracje, więc nie należy ich mylić. Ogłoszenie 1.0 przytacza dodatkowo skrócenie czasu budowania o 57 procent w Ramp, do 38 procent w Mercedes-Benz.io i o 64 procent w Beehiiv, bez publicznej metodyki, więc traktuj je jako deklaracje dostawcy.

Konfiguracja i uruchomienie

Plik konfiguracyjny nazywa się rolldown.config z rozszerzeniem js, mjs, cjs, ts, mts albo cts i leży w katalogu głównym. Domyślnie jest wczytywany przez spakowanie go samym Rolldownem, co odpowiada ustawieniu configLoader: 'bundle'. Wariant native importuje plik wprost i wymaga środowiska, które samo poradzi sobie z TypeScriptem, czyli Node 22.18 lub nowszego, Bun, Deno albo zarejestrowanego mechanizmu ładowania. Dokumentacja zapowiada, że native stanie się kiedyś wartością domyślną.

# instalacja z przypięciem dokładnej wersji
npm install --save-dev --save-exact rolldown

# budowanie na podstawie pliku konfiguracyjnego
npx rolldown -c

# konfiguracja TypeScript wczytana bez pakowania
npx rolldown -c rolldown.config.ts --configLoader native

# tryb obserwowania zmian
npx rolldown -c --watch

# minifikacja wlaczona z wiersza polecen
npx rolldown -c --minify

# wylaczenie flagi logicznej: prefiks --no-, nigdy wartosc "false"
npx rolldown -c --no-codeSplitting

# ustawienie pola zagniezdzonego notacja z kropka
npx rolldown -c --codeSplitting.minSize 30000

# zmienne przekazane do pliku konfiguracyjnego przez process.env
npx rolldown -c --environment INCLUDE_DEPS,BUILD:production

W trybie obserwowania zmian wiersz poleceń ustawia zmienne środowiskowe ROLLDOWN_WATCH oraz ROLLUP_WATCH, ale wtyczka powinna sprawdzać this.meta.watchMode, bo to działa niezależnie od sposobu uruchomienia.

Poniżej konfiguracja z polami sprawdzonymi w dokumentacji wersji 1.2.5.

import { defineConfig } from 'rolldown'

export default defineConfig({
  input: 'src/main.ts',
  platform: 'browser',
  tsconfig: './tsconfig.json',
  transform: {
    define: { IS_PROD: 'true' },
    decorator: { legacy: true }
  },
  optimization: {
    inlineConst: { mode: 'smart', pass: 1 },
    pifeForModuleWrappers: true
  },
  checks: {
    circularDependency: true,
    cannotCallNamespace: true
  },
  output: {
    dir: 'dist',
    format: 'esm',
    minify: true,
    codeSplitting: {
      minSize: 20000,
      groups: [
        { name: 'react-vendor', test: /node_modules[\\/]react/, priority: 20 },
        { name: 'vendor', test: /node_modules/, priority: 10 },
        { name: 'common', minShareCount: 2, minSize: 10000, priority: 5 }
      ]
    }
  }
})

Opcja platform przyjmuje node, browser albo neutral i domyślnie jest ustawiana na node dla formatu cjs, a na browser dla pozostałych. Opcja optimization.inlineConst domyślnie ma wartość { mode: 'smart', pass: 1 }, czyli wstawia stałe tylko w warunkach, operatorach trójargumentowych i wyrażeniach logicznych. Opcja optimization.pifeForModuleWrappers jest domyślnie włączona i owija opakowania modułów w nawiasy, żeby silnik V8 kompilował je wcześnie, kosztem niewielkiego wzrostu rozmiaru.

Wewnątrz Vite ten sam zestaw opcji przekazuje się przez build.rolldownOptions.

import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rolldownOptions: {
      output: {
        codeSplitting: {
          groups: [{ name: 'vendor', test: /node_modules/ }]
        }
      }
    }
  }
})

Filtry punktów zaczepienia to mechanizm, którego Rollup nie ma, i przy większych projektach jest istotny dla czasu budowania. Wtyczka deklarująca filtr po id, code albo moduleType nie przechodzi granicy Rust do JavaScriptu dla modułów, które filtr odrzuca. Wtyczkę bez własnych filtrów można opakować funkcją withFilter.

import fs from 'node:fs'
import path from 'node:path'
import { defineConfig } from 'rolldown'
import { withFilter } from 'rolldown/filter'
import yaml from '@rollup/plugin-yaml'

function svgAssetPlugin() {
  return {
    name: 'svg-asset',
    resolveId: {
      filter: { id: /\.svg$/ },
      handler(source, importer) {
        return path.resolve(path.dirname(importer), source)
      }
    },
    load: {
      filter: { id: /\.svg$/ },
      handler(id) {
        const referenceId = this.emitFile({
          type: 'asset',
          name: path.basename(id),
          source: fs.readFileSync(id)
        })
        return `export default import.meta.ROLLDOWN_FILE_URL_${referenceId};`
      }
    }
  }
}

export default defineConfig({
  plugins: [
    svgAssetPlugin(),
    withFilter(yaml(), { transform: { id: /\.yaml$/ } })
  ]
})

Porównanie z Rollupem, esbuild i Rspackiem

Wersje w nagłówkach tabeli pochodzą ze znaczników latest w rejestrze npm na 22 sierpnia 2026 roku.

Tabela nie rozstrzyga wyboru, bo rozstrzyga go zwykle ekosystem wtyczek, którego już używasz. Jeśli to wtyczki Rollupa albo Vite, Rolldown jest naturalną ścieżką. Jeśli to wtyczki Webpacka, patrz na Rspack.

Typowe błędy

Pierwszy dotyczy minifikacji. Opcja output.minify ma domyślnie wartość 'dce-only', czyli usuwa martwy kod, ale nie skraca identyfikatorów. Zbudowanie projektu poleceniem npx rolldown -c bez jawnego ustawienia tej opcji daje wynik większy, niż się spodziewasz, i łatwo z tego wyciągnąć błędny wniosek o skuteczności narzędzia.

Drugi to wyłączanie flag logicznych w wierszu poleceń. Zapis --minify false kończy się błędem, bo wartość jest odczytywana jako łańcuch "false". Poprawny zapis to --no-minify, zgodnie z konwencją Rollupa.

Trzeci to dokładanie rolldown do projektu, który już ma Vite 8, żeby "mieć nowszą wersję". Zakres ~1.2.4 w Vite 8.2.2 dopuszcza tylko 1.2.4 i 1.2.5; wszystko poza nim daje dwie kopie bundlera w drzewie zależności i dwa komplety binariów natywnych, a Vite i tak użyje swojej.

Czwarty to wtyczka w punkcie transform, która parsuje otrzymany kod jako czysty JavaScript. Dostanie TypeScript albo JSX, bo transformacja wewnętrzna idzie po tym punkcie.

Piąty to wtyczka bez filtrów punktów zaczepienia w projekcie z tysiącami modułów. Każdy moduł przechodzi wtedy granicę Rust do JavaScriptu, a zysk z natywnego bundlera topnieje. Opakowanie funkcją withFilter po stronie konsumenta zajmuje jedną linię.

Szósty to zakładanie, że closeBundle wykona się zawsze. Wykona się tylko wtedy, gdy wywołasz generate() albo write() przynajmniej raz, więc kod sprzątający oparty na tym punkcie potrafi się nie uruchomić przy nietypowym użyciu interfejsu programistycznego.

Siódmy to instalacja z pominięciem zależności opcjonalnych. Bez pakietu @rolldown/binding-* dla swojej platformy dostaniesz pakiet JavaScript bez silnika. Na platformach spoza listy prekompilowanych binariów zostaje wariant Wasm, instalowany osobno przez npm install --cpu wasm32 --os wasip1-threads.

Ósmy to sięgnięcie po crate Rust zamiast po pakiet npm, w przekonaniu, że to ta sama rzecz z tymi samymi gwarancjami. Nie jest: crate'y nie trzymają się semantycznego wersjonowania, nie mają dokumentacji, a dotyczące ich zgłoszenia są zamykane.

FAQ

Czy Rolldown 1.x nadaje się do produkcji?

Tak, i to jest deklaracja autorów z ogłoszenia wersji 1.0 z 7 maja 2026 roku, nie domysł. Dokumentacja nie zawiera ostrzeżenia przed użyciem produkcyjnym, README w opublikowanej paczce też nie. Kontrakt ma jednak zakres: zamrożone są nazwy opcji, typy i sygnatury punktów zaczepienia wtyczek, natomiast heurystyki podziału na fragmenty i domyślne wartości opcji mogą się zmieniać w wydaniach pobocznych, a funkcje oznaczone jako eksperymentalne mogą zmienić zachowanie bez podbicia wersji głównej.

Czym różni się rolldown od rolldown-vite?

rolldown to samodzielny bundler w wersji 1.2.5. rolldown-vite był tymczasowym wariantem Vite z podmienionym bundlerem, wydanym w maju 2025 roku jako zapowiedź techniczna; zatrzymał się na 7.3.1 i wszystkie 92 wersje w rejestrze npm są oznaczone jako wycofane, z komunikatem kierującym do migracji na Vite 8. W Vite 8 Rolldown jest bundlerem domyślnym i jedynym, bez żadnej flagi.

Czy moje wtyczki Rollupa zadziałają bez zmian?

Większość tak, ale wykaz wyjątków jest konkretny. Nie działają trzy punkty zaczepienia: shouldTransformCachedModule, resolveImportMeta i renderDynamicImport. W kontekście wtyczki brakuje cache, setAssetSource i getWatchFiles. Do tego dochodzi pięć różnic zachowania, w tym generowanie każdego wyjścia osobno i ostrzejsza walidacja map źródeł. Utrzymywanej listy niedziałających wtyczek nie ma; zgłoszenie 819 jest zamknięte i nieaktualne.

Czy Rolldown zastępuje esbuild w Vite całkowicie?

W Vite 8 tak: Rolldown przejął zarówno wstępne pakowanie zależności, jak i budowanie produkcyjne, a esbuild zszedł w tym pakiecie do roli opcjonalnej zależności równorzędnej, deklarowanej w zakresie ^0.27.0 || ^0.28.0. Poza Vite esbuild pozostaje osobnym narzędziem o innym interfejsie wtyczek i bywa lepszym wyborem tam, gdzie liczy się wyłącznie transformacja pojedynczych plików.

Czy Rolldown wygeneruje pliki deklaracji TypeScriptu?

Nie sam z siebie. Dokumentacja kieruje autorów bibliotek do narzędzia tsdown, a w rejestrze npm jest osobna wtyczka rolldown-plugin-dts w wersji 0.28.2, która wymaga rolldown w zakresie ^1.2.0. Sprawdzanie typów nadal wymaga osobnego uruchomienia kompilatora TypeScriptu.

Ile miejsca zajmuje instalacja?

Pakiet rolldown@1.2.5 to około 839 kilobajtów samego JavaScriptu, ale silnik leży w osobnym pakiecie z binarium dla Twojej platformy. Wariant @rolldown/binding-darwin-arm64 w tej samej wersji zajmuje po rozpakowaniu 17 070 467 bajtów, czyli około 17,1 megabajta, więc realnie licz blisko 18 megabajtów na platformę. Przy obrazach kontenerów budowanych od zera to widoczna pozycja.