Rolldown's build path runs through just, not npm, while its plugin API targets Rollup

Rollup's plugin surface on top of an oxc parser, with esbuild's intended scope

Two projects set the shape of this one. The API and plugin interface target Rollup, and the Credits section names Rich Harris as its creator. The scope does not follow Rollup. The project's own description says it will be more similar to esbuild in scope, and the same credits list names Evan Wallace as esbuild's creator. That combination is the design argument, and it is also the first thing to interrogate, because a Rollup-compatible plugin interface paired with a narrower intended scope means your config's plugin set decides whether the switch works at all. Underneath, napi-rs provides Node.js add-ons in Rust via Node-API and oxc supplies the parser, resolver and sourcemap support, so Rolldown is not doing parsing or module resolution itself. The `examples/` directory is the closest thing to a supported feature list: rollup-plugin-esbuild, par-plugin, styled-components-native, native-magic-string, basic-typescript, basic-vue, watch, hmr-raw, chunk-import-map, isolated-decl, lazy-compilation, bundle-analyzer-demo and yarn-pnp. Anything shaped unlike one of those is unproven.

npm run build at the root prints Use just build and does nothing else

The root package.json is private, named monorepo, described as Rollup in Rust, pinned to packageManager [email protected], and carrying an engines field of `node ^20.19.0 || >=22.12.0`. Its scripts are placeholders by design. `build`, `build:release` and `test` each echo a sentence pointing at just. The consequence for automation is specific: a pipeline that shells out to the root npm scripts gets a sentence on stdout instead of a bundle or a test run, and because the names still read like ordinary entry points, a wrapper that checks only the process exit status has no signal that no work happened. The real recipes live in the justfile at the repository root, and `justfile` is also where the shell choice is fixed, with bash on Unix and PowerShell on Windows. For anyone building this from a clone, the contributing guide at rolldown.rs/contribution-guide/ is the entry point, not the npm script list.

just setup installs four cargo tools before a single crate compiles

The setup target does not compile anything itself. It installs the pnpm workspace first, then the Rust helper binaries, then the submodules and the benchmark input:

  vp install
  cargo install cargo-binstall
  cargo binstall cargo-insta cargo-deny [email protected] typos-cli -y
  just setup-submodule
  just setup-bench

Before that block runs, `just setup` also calls `just setup-vite-plus`, which on Unix is `curl -fsSL https://vite.plus | bash` and on Windows is `irm https://viteplus.dev/install.ps1 | iex`. `just setup-bench` goes on to run `node --import @oxc-node/core/register ./scripts/misc/setup-benchmark-input/index.js`. Price that for a CI image: a Rust toolchain from rust-toolchain.toml, pnpm at the pinned version, a Node meeting the engines floor, and permission to pipe a remote script into a shell. The four cargo binaries are not optional extras either. They are what the repository expects to find on the path before the first test run.

A plain clone leaves the rollup and test262 submodules unfilled

`.gitmodules` sits in the repository root, and the top level also carries `rollup` and `test262` as directories, which is where a test suite gets its reference trees. One recipe fills them:

git submodule update --init

Skip it and snapshot comparisons have nothing to compare against, and the symptom reads as missing test data rather than a missing setup step. Output correctness in this project is snapshot based, and three pieces of the root directory say so: `.insta.yaml` for Rust snapshots, an `update-esbuild-diff` recipe that runs `vp run --filter=scripts esbuild-snap-diff`, and a Node snapshot refresh that runs

just test-node --update

The practical consequence is that a parser or codegen change arrives as a diff a human is expected to read, not as a clean pass. That is a defensible way to run a bundler, but it means review load scales with the size of your change, and a first contribution should expect to defend snapshot churn rather than argue about behaviour.

Five native bindings are named, and Linux arm64 is not among them

Installing Rolldown crosses a native boundary, so the target list matters more here than in a pure JavaScript tool. The badge row at the top of the page links five 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`. Linux on arm64 and any musl based distribution are not in that list, and nothing on the page names a package for them, so on those machines the install has to be checked against the registry rather than assumed to resolve. The wasm32-wasi binding is the fallback for a platform with no native binary, and it comes with the usual cost of compiling in a WebAssembly sandbox. Two other distribution paths are linked from the same header: a pkg.pr.new preview URL for unreleased builds, and a StackBlitz fork of the rolldown starter for trying it without a local toolchain.

print_stdout is denied workspace wide, so diagnostics need a real path

Cargo.toml declares a workspace of every directory under `crates/` plus `tasks/*`, on resolver 3 and edition 2024:

[workspace]
members = ["./crates/*", "tasks/*"]
resolver = "3"

The shared lint table then denies `print_stdout` and `print_stderr` with the comment Must be opt-in, sitting next to denies on `dbg_macro`, `todo`, `unimplemented`, `exit` and `clone_on_ref_ptr`. Two things follow for anyone touching the Rust side. A diagnostic is not a print statement; it has to go through whatever channel the crate exposes, which turns adding a warning into a design question rather than a one line change. And because members are a glob, any folder that appears under `crates/` joins the workspace immediately, so a stray directory changes what cargo builds and what clippy checks. That is convenient for the maintainers and a trap for a fork that only wanted one crate out of the tree.

Vite is the destination, and nothing on the page names a release

The whole positioning is one sentence: Rolldown is intended to serve as the future bundler used in Vite. That is a statement of intent, and nothing after it goes further. No Vite release is named, no flag or experimental mode is mentioned, the word experimental never appears, and there is no migration note for an existing config. The documentation link at the top of the page points at rolldown.rs/guide/getting-started, so the operational detail lives off this repository. For a team, the question is not whether Rolldown will replace Rollup. It is whether the plugins in the current config sit inside the compatible subset, and the repository answers that only by example. Read plainly, this is a foundation being laid for a destination that has not arrived, which makes it a poor dependency for a delivery date and a reasonable one for a build you control end to end.

v1.2.10, v1.2.11 and v1.2.12 landed inside eight days

The repository is not archived and its last push was on 2026-11-02, so this is active work, and the release list shows why that cuts both ways: v1.2.15 on 2026-10-21 and v1.2.16 on 2026-10-29, two patch releases eight days apart. A caret range in your package.json can move under a build that produced numbers you published, so pin an exact version for anything reproducible. The changelog is generated rather than written by hand, with `cliff.toml` at the root and CHANGELOG.md split into CHANGELOG-2024.md and CHANGELOG-2025.md by year, which means commit subjects become release notes and a rushed subject becomes public documentation. Rolldown itself is MIT, and THIRD-PARTY-LICENSE covers code derived from Rollup and esbuild, both MIT. The project belongs to VoidZero Inc., so maintenance is company backed rather than foundation backed and one company's priorities set the roadmap.

Editorial conclusion

Take Rolldown if you own the whole build chain, run a config whose plugins resemble the examples directory, and can pin an exact version. Hold off if you depend on long tail Rollup plugins, run Linux arm64 or musl builds where no binding is named, or need a Vite migration that nothing in this repository documents. Verify first that the plugin you care about has a peer in examples/, because that directory is the only stated evidence of what works and the project promises a future Vite default without naming a release that ships it.

Frequently asked questions

Official sources

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