English for Rolldown Bundler Developers

Rolldown discussions are shaped by its positioning as Vite’s next-generation bundler, so the vocabulary centers on plugin compatibility, unified pipelines, and what changes for teams currently on Rollup or esbuild under Vite.

Key Vocabulary

Rollup-compatible plugin API — Rolldown’s commitment to supporting the existing Rollup plugin interface, so plugin authors and consumers don’t need to rewrite their integrations. “Our custom asset plugin needed zero changes — Rolldown’s Rollup-compatible plugin API picked it up directly.”

Unified bundler — the goal of replacing Vite’s split dev-time (esbuild) and build-time (Rollup) tooling with a single bundler used consistently across both, eliminating dev/prod behavioral drift. “Half our ‘works in dev, breaks in prod’ bugs came from esbuild and Rollup handling an edge case differently — a unified bundler removes that class of bug entirely.”

Tree-shaking — eliminating unused exports from the final bundle by statically analyzing which code is actually reachable, a core optimization carried over from Rollup’s design philosophy. “Tree-shaking isn’t removing this utility function — check whether it’s being re-exported somewhere in a way that looks like it’s still in use.”

Native bundling — Rolldown’s Rust-based core, delivering a step-change in bundling speed compared to the JavaScript-based Rollup it’s designed to replace. “The full production build finishes in a fraction of the time now that native bundling is doing the resolution and code generation.”

Drop-in replacement — the design intent that switching a Vite project to Rolldown should require little to no configuration change, since it targets compatibility with the existing plugin ecosystem. “We tried it expecting a migration project and it turned out to be close to a drop-in replacement — one flag and the existing config just worked.”

Common Phrases

• “Is this plugin using the Rollup-compatible API directly, or does it rely on a Rollup-specific internal we need to check?”
• “Are we seeing dev/prod parity issues that a unified bundler would actually solve, or is this something else?”
• “Is tree-shaking not kicking in because of a side-effect-full import, or a sideEffects field misconfiguration?”
• “How close to a drop-in replacement was this migration in practice — did anything actually need reconfiguring?”
• “Is native bundling giving us the speedup here, or is the bottleneck actually in a slow plugin hook?”

Example Sentences

Debugging a production-only bug: “This was a classic esbuild-versus-Rollup discrepancy — moving to Rolldown as a unified bundler means dev now behaves exactly like the production build.”

Explaining an architecture choice: “We adopted Rolldown early because the Rollup-compatible plugin API meant we kept our entire existing plugin chain instead of waiting for ecosystem support to catch up.”

Reviewing a pull request: “This import is blocking tree-shaking — mark the module as side-effect-free or restructure the export so the bundler can actually drop the unused parts.”

Professional Tips

• Frame adoption around unified bundler when talking to teams frustrated by dev/prod discrepancies — it’s the strongest argument for switching.
• Say Rollup-compatible plugin API, not just “compatible with Rollup,” to show you understand the specific compatibility surface being targeted.
• Use native bundling to explain speed, distinct from “it’s just faster” — it points to the actual architectural reason.
• Describe a smooth migration as a drop-in replacement only when config genuinely didn’t change — overusing the term undermines credibility when a migration turns out to need real work.

Practice Exercise

1. Explain why a unified bundler removes an entire class of dev/prod bugs.
2. Describe what makes a plugin migration to Rolldown a “drop-in replacement” versus a rewrite.
3. Write a sentence explaining why an import might prevent tree-shaking from removing unused code.