rollup/plugins: thirty-odd packages, one pnpm monorepo, and an npm guard in preinstall

The list mixes three categories of maintenance, not one

The repository's own framing is the first thing to read, because it explains why the list looks uneven. It houses plugins that Rollup considers critical to everyday use, plugins which the organization has adopted maintenance of, and plugins that the project simply recommends to its users. That is three different relationships to the same namespace, and it means the badge-free table gives you no signal about who actually maintains a given entry or how often it moves. A plugin taken over from someone else will have a different history from one written in house, and a recommended plugin is only listed because it fills a gap. The scope covers compile steps such as babel, buble, sucrase, swc, and typescript, resolvers such as node-resolve and commonjs, asset loaders for image, url, data-uri, yaml, json, graphql, dsv, and wasm, and output concerns including terser, html, and legacy.

The npm guard in preinstall is the workspace's real enforcement

The root manifest contains a `preinstall` script pointing at `node scripts/disallow-npm.js`, which is a much clearer statement of intent than any prose about package managers. In a pnpm workspace, an accidental `npm install` at the root produces a tree that looks plausible and resolves workspaces incorrectly, so the guard fails the install before it happens. Everything else in the tooling follows from the same decision. The repository is a monorepo that uses pnpm for dependency management, and getting started requires installing pnpm globally first:

$ npm install pnpm -g

The manifest pins pnpm itself as a devDependency at ^8.7.5 alongside a `pnpm-lock.yaml` and a `pnpm-workspace.yaml`, and a `.nvmrc` sits at the root to pin the Node version for contributors. One more entry is worth noting for anyone reading the toolchain: TypeScript is requested as `catalog:`, a pnpm workspace protocol rather than a version, so the actual version is defined once in the workspace catalog and shared by every package.

Publishing is driven by a versioner, not by hand-written versions

Releases come from a script rather than from a maintainer editing version fields. The `package:release` script invokes `versioner` with a strip pattern that removes the scope and an optional `plugin-` prefix, for example `^@.+/(plugin-)?`, and a target, so the tool derives the next version from commit history rather than from a hand-written number. The plugin-specific instructions are short because the shared script does the work: adding a dependency to one plugin is `pnpm --filter ./packages/<name> add <package>`, where `<name>` is the plugin name as in `@rollup/plugin-beep`, and publishing is `pnpm publish <name> [flags]` with `<name>` being the portion after `@rollup/plugin-`. The described publish flow gathers commits from the last release tag and then determines the next appropriate version, so the changelog content comes from commit history at the same moment the number is chosen.

Both ava and vitest are declared as test runners

The devDependencies list two test frameworks at full major versions, `ava` at ^4.3.3 and `vitest` at ^4.0.2, alongside `nyc` for coverage and a `codecov-lite` wrapper. There is also an `ava` configuration block in the same manifest that narrows which files the runner picks up, excluding fixtures, helpers, recipes, and `types.ts` by pattern. Having both declared is not necessarily a conflict, since packages can each use whichever they need and the exclusion patterns read like a legacy carry-over from an ava-only setup, but it does mean the test story is not described in one place on this page. Coverage is submitted through a `ci:coverage:submit` script pointing at a local `scripts/codecov` file, and the page carries both a CircleCI badge and a codecov badge pointing at the master branch, so the continuous integration configuration for the collection lives outside this repository.

Linting is four prettier targets plus one eslint pass

Style enforcement is split into four separate commands that each write rather than check, which is worth knowing before you run them. `lint:docs` runs prettier over `.github` markdown, every `README.md`, and every `CHANGELOG.md` across the repo. `lint:json` covers `.github` yml files, nested tsconfig files, the root tsconfig variants, and `pnpm-workspace.yaml`. `lint:package` formats every `package.json`, using `prettier-plugin-package` so the field ordering stays canonical across thirty-odd manifests. `lint:js` is the only non-writing pass besides the combined check, running eslint with a cache across the `packages`, `scripts`, `shared`, and `util` directories for `.js`, `.ts`, and `.mjs` extensions, and there is a separate `fix:js` that adds `--fix`. The composite `lint` script runs them in sequence as docs, json, package, js, with the json stage marked no-bail. TypeScript configuration is split across `tsconfig.base.json` and `tsconfig.eslint.json`.

Two small plugins show what the long tail looks like

Two entries in the table are worth reading as a pair because they show the range the collection covers. `beep` system beeps on errors and warnings, which is a plugin whose entire job is a side effect, and it exists in the same namespace as `image` and `wasm`. `virtual` loads virtual modules from memory, which is the plugin authors reach for when the module they need does not exist on disk. Between them they bracket the collection: one is a developer-experience plugin with no effect on output, the other is a load hook for content that never touches the filesystem. A third entry sits in its own table rather than the main one, `pluginutils`, described as a set of utility functions commonly used by Rollup plugins, which is shared infrastructure rather than a build step and would not appear in a bundler configuration.

Ownership and release state are both visible in the tree

Three things in the repository root say more about how this is run than the plugin table does. First, there is a `CODEOWNERS` file, so plugin ownership is expressed in the repository itself rather than in a wiki. Second, there are no GitHub releases for this repository at all, which follows from the shape of the project: each plugin is published separately to npm, so there is no single artefact whose version could be tagged, and version history is per package rather than central. Third, the last push to the default branch `master` was 2026-05-29, and the tree still carries `.husky/` for git hooks, a `.charlie/` directory, a `shared/` directory for code used across packages, a `util/` directory, and a `scripts/` directory holding the tooling the package scripts call, including the npm guard and the codecov wrapper. The default branch is `master` even though the npm scope is `@rollup`.

Editorial conclusion

Take these plugins when you are bundling with Rollup and want the plugins the project itself maintains rather than an assortment of community equivalents, and install them one at a time since each is its own package. Check three things first. There are no GitHub releases, so there is no tag to track and no changelog to read at the top level; version history lives per package. The workspace requires pnpm and the root manifest actively blocks npm with a preinstall script, so a contributor who installs with npm gets stopped rather than a subtly broken tree. And the plugin list mixes three different kinds of thing, from modules Rollup considers critical to everyday use through plugins the organisation has taken over from other maintainers, so maintenance quality is not uniform across the thirty-odd entries.

Frequently asked questions

Official sources

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