rollup

Rollup is a JavaScript module bundler that compiles small, discrete modules written with the standardized ES module syntax into larger bundles suitable for libraries, applications, and browsers. Unlike bundlers built around CommonJS interop, Rollup treats ES modules as a first-class citizen, which lets it perform aggressive static analysis and tree-shaking to strip out code that is never used.

It is invoked through a CLI or a JavaScript/programmatic API, and produces output in ES, CommonJS, AMD, UMD, IIFE, or SystemJS formats through a set of pluggable finalisers. A hook-based plugin architecture (resolveId, load, transform, renderChunk, and more) lets authors extend module resolution and code generation without modifying Rollup’s core, and this same plugin interface is what powers Vite’s production build step.

Under the hood, Rollup builds a dependency graph of every module reached from the configured entry points, determines which exports are actually used, and only includes code that affects the program’s observable behavior. Recent versions offload parsing to a native Rust binary (via NAPI) or a WebAssembly fallback for platforms without native bindings, trading a Rust toolchain dependency for substantially faster parsing on large codebases.

What You Get

• A CLI (rollup) and a JavaScript/TypeScript API (rollup() + RollupBuild) for building and watching bundles
• Tree-shaking driven by static ES module analysis rather than heuristic dead-code elimination
• Multiple output formats from one build: ES, CommonJS, AMD, UMD, IIFE, and SystemJS
• A hook-based plugin system (resolveId, load, transform, renderChunk, generateBundle, and more) for extending resolution, transformation, and code generation
• Code-splitting with automatic and manual chunking, including dynamic import() support
• Built-in watch mode for incremental rebuilds during development
• Native Rust (NAPI) parsing with a WebAssembly fallback for platforms without prebuilt binaries

Common Use Cases

• Publishing a library - authors bundle a package’s ES module source into ESM and CommonJS builds so consumers on either module system can import or require it
• Powering another build tool - Vite and similar tools use Rollup’s plugin API directly as their production bundler, rather than reimplementing bundling
• Shipping a browser bundle - a single <script>-ready IIFE or UMD file is produced from a modular application source tree
• Building JavaScript plugins/extensions - projects that need a single self-contained file (a CLI tool, a browser extension script, a Rollup plugin itself) bundle their multi-file source into one artifact
• Enforcing dead-code elimination - projects that care about minimal output size choose Rollup specifically for its ES-module-native tree-shaking over less aggressive bundlers

Under The Hood

Architecture

Rollup’s core builds a dependency graph in Graph (src/Graph.ts), which uses a ModuleLoader to resolve and parse every module reachable from the configured entry points into Module/ExternalModule instances, tracking execution order and circular dependencies. A Bundle (src/Bundle.ts) then partitions the included modules into Chunk objects via getChunkAssignments, resolving shared dependencies and manual/automatic chunking rules, before handing each chunk to a finalisers implementation (src/finalisers/{es,cjs,amd,iife,umd,system}.ts) that renders it into the requested output format. A PluginDriver runs plugin hooks (resolveId, load, transform, renderChunk, generateBundle, and others) at each stage, which is the same extension surface Vite builds its production pipeline on top of. What breaks if this core changes: the finaliser and plugin-hook contracts are Rollup’s most load-bearing public surface, since third-party plugins and downstream tools like Vite depend on their exact shapes.

Tech Stack

The package is TypeScript compiled to a dual ESM/CommonJS dist/ output, with @types/estree as its only runtime dependency and a large devDependency set (ESLint 9 flat config, Vitest/Mocha for tests, acorn plus custom AST tooling) supporting the build. Parsing is offloaded to a native binary written in Rust (rust/bindings_napi), built with NAPI-RS and distributed as per-platform optional dependencies, with a WebAssembly build (rust/bindings_wasm) as a fallback for platforms lacking a prebuilt native binary — an unusual hybrid JS/Rust architecture among JavaScript bundlers. AST data crosses the JS/Rust boundary via a shared buffer format (bufferToAst.ts, getAstBuffer.ts) rather than JSON serialization, which keeps that handoff fast.

Code Quality

The test suite is extensive and organized by concern (test/function, test/form, test/chunking-form, test/sourcemaps, test/incremental, test/hooks, test/browser, test/leak, test/typescript), run through Mocha with a dedicated memory-leak check and a TypeScript type-check pass (test:typescript) in addition to normal unit tests. Linting spans eslint.config.mjs for JS/TS, cargo fmt/cargo clippy for the Rust bindings, and Prettier for Markdown, all wired into CI (ci:lint, ci:test:all) alongside noUnusedLocals/noUnusedParameters strict TypeScript compiler options. Error paths run through a centralized logs.ts/getRollupError module producing structured, coded errors rather than ad hoc throws.

API Design The public API is a single rollup() function returning a RollupBuild with generate/write/close methods, plus a watch() entry point for incremental builds — a small, consistent surface for a tool with this much internal complexity. Plugin authors implement a documented set of named hooks with a stable calling convention (returning null/undefined to defer, a value to short-circuit), and the same hook names are used identically across the CLI config file and the JS API, which keeps the learning curve to one mental model rather than two. Extensive docs (docs/javascript-api, docs/plugin-development, docs/command-line-interface) and interactive migration guides lower the ramp-up cost further.