Rolldown: a Rust bundler that keeps the Rollup plugin API

What Rolldown solves, and who it is actually for

The README describes Rolldown as a JavaScript and TypeScript bundler written in Rust, intended to serve as the future bundler used in Vite, providing Rollup-compatible APIs and a plugin interface while being "more similar to esbuild in scope". That sentence carries the whole positioning. The problem Rolldown addresses is not that JavaScript lacks bundlers. It is that Vite currently runs two of them: esbuild for development and Rollup for production builds. Two bundlers mean two module graphs, two sets of resolution rules, and plugin authors writing against whichever one their hook happens to fire in. Rolldown's answer is one Rust bundler that keeps Rollup's API surface, so the production path and the plugin model do not have to be rewritten from scratch.

The audience follows from that. If you maintain a Rollup config with a stack of community plugins, you are the target reader. If you write Vite plugins and have ever needed to know which bundler a given hook runs under, you are the target reader. If you are starting a project from nothing and have no existing build to preserve, Rolldown is a reasonable default but not an urgent one, because the compatibility promise buys you nothing you were not already using. And if your build is webpack with a shelf of loaders, none of this applies to you at all: Rolldown implements the Rollup plugin contract, not webpack's loader and plugin system, and there is no bridge in the repository for that.

The Rollup-compatible API is the design decision, not the Rust rewrite

Writing a bundler in Rust is the least interesting thing about Rolldown, since esbuild already demonstrated the approach. The consequential choice is the API. A Rollup plugin is an object with hooks: resolveId, load, transform, and the rest, each returning a value or a promise. Rolldown implements that interface rather than inventing a new one, which means an existing plugin can in principle be loaded unchanged. The README names the dependencies that make this practical: napi-rs for Node.js add-ons in Rust via Node-API, and oxc for the underlying parser, resolver, and sourcemap support. Those two names explain the architecture. The bundling logic, module graph, and tree shaking live in Rust crates; the JavaScript-facing side is a Node-API binding; and the parsing and resolution work is delegated to oxc rather than hand-written.

The repository layout matches that story. The crates/ directory holds the Rust workspace, packages/ holds the npm packages, and the README's badge list names platform-specific binding packages: @rolldown/binding-darwin-arm64, @rolldown/binding-darwin-x64, @rolldown/binding-linux-x64-gnu, @rolldown/binding-win32-x64-msvc, and @rolldown/binding-wasm32-wasi. That is the standard native-addon distribution model: the main package resolves a prebuilt binary for the current platform, with a WebAssembly fallback for platforms without one. The practical consequence is that installs are not pure JavaScript, and the wasm32-wasi binding is the escape hatch rather than the default. The examples/ directory is worth reading before you trust the compatibility claim, because it is where the project demonstrates which plugin patterns it actually supports. It contains directories such as examples/rollup-plugin-esbuild/, examples/par-plugin/, examples/native-magic-string/, and examples/basic-typescript/. The presence of a dedicated example for running a Rollup plugin under Rolldown tells you compatibility is a tested surface, not an assumption.

Installing Rolldown and running a first build

The README points to the documentation at rolldown.rs for getting started, and the repository's root package.json declares the Node.js requirement as ^20.19.0 || >=22.12.0. Check that before anything else, because the native binding will not load on an older runtime.

Install the package from npm:

npm install rolldown

Because it is a native addon, your package manager will pull the binding package matching your platform alongside it. If you are on a platform without a prebuilt binary, the wasm32-wasi binding is the fallback the README lists.

The repository's own scripts show how the project builds and tests itself rather than how a consumer configures a build. The root package.json routes build and test through just, and the justfile defines the recipes those scripts point at:

just build
just test-node
just roll

The justfile's roll recipe chains the Rust, Node.js, and repository checks in one go, and test-update refreshes snapshots for both test suites. For a consumer, the equivalent first step is to take a Rollup configuration you already have and run it against Rolldown, then work through which plugins load. The repository ships examples/rollup-plugin-esbuild/ for exactly that kind of check, alongside examples/basic-typescript/ and examples/basic-vue/ for the two framework-adjacent cases most teams will hit first.

Where the compatibility promise runs out

Rollup-compatible is a claim about an interface, not about behaviour under load. The README says Rolldown provides Rollup-compatible APIs and a plugin interface, and the credits section states the project is heavily inspired by Rollup and esbuild. It does not claim that every plugin works, and the repository does not carry a published compatibility matrix. That gap is the real risk. Plugins that only use the documented hooks and return plain values are the likely survivors. Plugins that reach into Rollup internals, patch the module graph, or depend on the exact shape of an internal object are the likely casualties, and a plugin author's use of those internals is rarely documented in the plugin's own README.

The second limitation is scope. The README says Rolldown will be "more similar to esbuild in scope" than to Rollup. esbuild deliberately does not implement the full Rollup plugin surface, and it does not do the kind of build orchestration Vite layers on top. Read that line as a boundary: Rolldown is a bundler, not a build system, and the parts of a Vite build that are not bundling are not Rolldown's job. The third is the native binding itself. A prebuilt binary per platform means a wasm fallback path exists for a reason, and that path is not the one most users exercise. If your CI runs on an unusual architecture, verify the binding resolves before you plan a migration around it.

Rolldown against Rollup and esbuild

The honest comparison is with Rollup, because Rolldown is copying its API on purpose. Rollup is JavaScript, has years of plugin ecosystem behind it, and its behaviour is the reference implementation that Rolldown is measured against. Rolldown is Rust with a Node-API binding, delegates parsing and resolution to oxc, and exists to be the single bundler inside Vite rather than a second one alongside esbuild. The difference in approach is not just language. Rollup's plugin model grew organically around a JavaScript runtime; Rolldown inherits that model but implements it across a language boundary, which is why the plugin surface is the compatibility target and the internals are not.

Against esbuild the split is clearer. esbuild is fast and deliberately narrow, with its own plugin API and no ambition to be Rollup-compatible. Rolldown takes the opposite bet: accept the Rollup plugin contract, absorb the cost of crossing the Node-API boundary, and get the speed from Rust anyway. If you have no Rollup plugins to preserve, esbuild's simpler model is the easier one to reason about. If you have a Vite build with a plugin stack, Rolldown's whole reason for existing is that stack. The repository's own examples/rollup-plugin-esbuild/ is the clearest statement of intent: rather than asking you to choose, it demonstrates running the esbuild plugin inside Rolldown.

Maintenance, licence, and what an upgrade costs

The repository is not archived. The last push was on 2026-08-26, the same day as the v1.2.6 release, and v1.2.5 and v1.2.4 landed on 2026-08-19 and 2026-08-12. That cadence is visible in the repository's own tooling: the root package.json declares [email protected] as the package manager, and the justfile defines a roll target that chains roll-rust, roll-node, roll-repo, and update-esbuild-diff, plus test-update targets that refresh snapshots for both the Rust and Node.js test suites. The update-esbuild-diff recipe runs a script filtered to the scripts package. That is a project that tracks esbuild's behaviour as a moving reference, which is a maintenance commitment in itself.

For a consumer, the upgrade cost is mostly the native binding. Because the bundler ships as platform-specific packages, upgrading Rolldown means fetching a new binary per platform, and any consumer on the wasm32-wasi fallback is on a different code path from everyone else. The licence is MIT, and the README is explicit that the project also contains code derived or copied from Rollup and esbuild, both MIT, with those licences listed in THIRD-PARTY-LICENSE. MIT is permissive and imposes no source-disclosure obligation on your own code, but the third-party notice file is part of the distribution and should travel with whatever you ship. That is a description of what the repository states, not legal advice; if the derived-code question matters to your organisation, read THIRD-PARTY-LICENSE directly.

Editorial conclusion

Adopt Rolldown if your build is already Rollup-shaped and you want to find out which of your plugins survive the move, or if you are tracking where Vite's bundler is heading. Do not adopt it as a drop-in replacement for a webpack pipeline with loaders, or for a build whose plugins reach into Rollup internals. Verify first: run your existing Rollup configuration against it and check each plugin and the emitted chunk graph against your current output. The repository is not archived and the last push was on 2026-08-26, with v1.2.6 released the same day.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes