rollup/plugins: the official plugin monorepo for Rollup bundles

What rollup/plugins is, and the gap it fills

Rollup itself ships as a bundler with a small core. Anything beyond reading ES modules and writing a bundle arrives through plugins, and before this repository existed those plugins were scattered across individual author accounts with uneven release habits. rollup/plugins collects the ones the project treats as load-bearing. The README describes the selection as plugins Rollup considers critical to everyday use, plugins the organization has adopted maintenance of, and plugins the project recommends to its users.

The audience is narrow and specific: engineers who already build with Rollup and need a second thing to happen during the build. Resolving a bare import from node_modules, turning a CommonJS dependency into something Rollup can tree-shake, reading a .json or .yaml file as a module, minifying the output. Each of those is a package in /packages, and the README table names them: alias, auto-install, babel, beep, buble, commonjs, data-uri, dsv, dynamic-import-vars, eslint, esm-shim, graphql, html, image, inject, json, legacy, multi-entry, node-resolve, replace, run, strip, sucrase, swc, terser, typescript, url, virtual, wasm, yaml, plus pluginutils under a separate heading for utility functions commonly used by Rollup plugins.

If you use Vite, webpack, esbuild or a framework CLI, this repository is not your dependency. It is the upstream that some of those tools wrap.

Monorepo layout: one repository, thirty independent npm packages

The architecture is a pnpm workspace, not a runtime. pnpm-workspace.yaml sits at the root, all plugin packages live in /packages, and shared code lives in /shared and /util alongside a /scripts directory for repository tooling. Each package publishes separately under the @rollup/plugin- prefix, so installing node-resolve does not pull in terser or typescript.

That separation matters for upgrade cost. A monorepo with independent versioning means one plugin can release a breaking change without dragging the rest along, and the root package.json shows the tooling that holds it together: eslint, prettier, ava and vitest for tests, husky and lint-staged for pre-commit hooks, @dot/versioner for the release script. The root package is marked private, so npm install @rollup/plugins is not the path to anything useful.

The preinstall script is worth noting because it is unusual. It runs node scripts/disallow-npm.js, which means the workspace expects pnpm and actively blocks npm as the installer for the repository itself. Contributors who habitually type npm install at the root will be stopped rather than silently producing a broken node_modules tree.

Installing a plugin and using it in a real build

You do not install the repository. You install one package from it. The README's own contributing section is about working inside the monorepo, so the commands below stay at the workspace level where the repository files support them.

To work on the repository, install pnpm globally as the README instructs, then install the workspace dependencies. The preinstall guard runs on the second command and rejects npm.

npm install pnpm -g
pnpm install

Adding a dependency to a single plugin package uses pnpm's filter flag, with the plugin name after the packages path. The README gives this exact form, using the beep package as the example:

pnpm --filter ./packages/<name> add <package>

Publishing follows the same naming convention. The argument is the portion of the package name after @rollup/plugin-, so beep rather than @rollup/plugin-beep:

pnpm publish <name> [flags]

For consuming a plugin in your own project, the README does not reproduce per-plugin install lines at the top level; each package directory has its own README with the options that package accepts. The root README's plugin table is the index. Read the table entry that matches your need, then open that package's README before writing configuration, because the top-level document describes the workspace and the contributing flow rather than plugin options.

Where the repository stops being the right answer

The README does not document rollback, deprecation policy, or a support window for any package, and that silence is the main practical limitation. If a plugin release breaks your build, the repository gives you no stated procedure for reverting beyond pinning the previous version in your own lockfile.

There is also a naming collision that will mislead anyone arriving from search. The word plugin is generic, and this repository has nothing to do with editor extensions, Minecraft server mods, browser add-ons or audio effects. A reader looking for how to use plugins in a DAW or a game platform is in the wrong place entirely, and the repository's own README will not correct that misreading because it assumes you already know what Rollup is.

A third boundary: some plugins here are thin adapters over another compiler. babel, swc, sucrase and buble all compile source, and the choice among them is a decision about your toolchain rather than about this repository. Picking one from the list because it appears in the table is not a reason to pick it.

How it differs from Vite, esbuild and webpack plugin ecosystems

The closest comparison is not another plugin but another bundler. Vite uses Rollup for production builds and exposes its own plugin API that is largely compatible with Rollup's, so a Rollup plugin often works inside a Vite config. The difference in approach is who owns the plugin surface. Vite ships a large set of behaviors as built-in defaults and expects plugins mainly for framework integration and asset handling. Rollup ships almost nothing as a default and expects you to assemble the pipeline.

esbuild takes the opposite route again: it bundles its own transformer, minifier and resolver into one binary, so there is no node-resolve package to install and no commonjs package to add. You get fewer decisions and less control over the individual stages.

Webpack's ecosystem is a separate registry with its own loader and plugin distinction, where loaders transform files and plugins hook the compiler. Rollup collapses both roles into the plugin interface, which is why a single package here can both resolve a module and transform its contents. If you want a bundler that makes most of these choices for you, this repository is not the lever you are looking for.

Maintenance, licence and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-05-29. The README gives no release cadence, no support commitment and no LTS statement for individual packages. Treat adoption as depending on the specific package you pick rather than on the repository as a whole.

The licence is MIT at the repository root, which is permissive and imposes no copyleft obligation on your bundle. That is a statement about the licence file, not legal advice; if your organization has a policy on third-party dependencies, the relevant document is the LICENSE file plus whatever each published package declares.

Upgrade cost is where the monorepo design helps and hurts. Independent versioning means you upgrade node-resolve without touching terser, which keeps the blast radius small. It also means there is no single version number that tells you the whole set is compatible with your Rollup version, and the root README does not publish a compatibility matrix. The preinstall guard against npm is another migration detail: a contributor moving from npm to this workspace has to change habits before anything builds.

Editorial conclusion

Adopt individual packages from this repository when you need Rollup to resolve node_modules, convert CommonJS, import JSON or YAML, or minify output; the README lists node-resolve, commonjs, json, yaml and terser among the plugins it calls critical to everyday Rollup use. Do not clone the monorepo expecting an application, and do not treat it as a plugin registry for editors, Minecraft servers or DAWs. Before wiring a plugin into a build, check the README inside packages/<name> for the options that package actually accepts, since the top-level README documents the workspace and contributing flow rather than per-plugin configuration.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. rollup/plugins on GitHub