Why generate both ESM and CJS output?

Publishing both lets consumers use whichever module system their own project uses: modern bundlers and Node's native `import` can use the ESM build directly, while older tooling or plain `require()` callers use the CJS build. This "dual package" approach is still common for widely-consumed libraries.

Why mark dependencies as external instead of bundling them?

For a library (as opposed to an application), bundling your dependencies into the output would duplicate code the consumer's own project likely already has, bloat the published package, and can cause subtle bugs from multiple copies of the same dependency (e.g. two React instances). Marking them `external` leaves `import`/`require` calls for those packages in the output, to be resolved by the consumer's own node_modules.

What does exports: "named" do on the CJS output?

It tells Rollup to export multiple named bindings via `module.exports.foo = ...` rather than assuming a single default export, matching how most TypeScript/ESM-style libraries with several named exports need to appear under `require()`.

Rollup Config Generator - rollup.config.js for Libraries

Q: When do I need @rollup/plugin-node-resolve and @rollup/plugin-commonjs together?

node-resolve teaches Rollup to locate dependencies in node_modules the way Node does (rather than only bundling relative imports), and commonjs converts any CommonJS-only dependencies it finds into ES modules Rollup can include. You typically need both together only when you intend to actually bundle some dependencies rather than marking them external.

Overview

Introduction

Rollup remains the go-to bundler for publishing an npm library because of its clean ESM output and tree-shaking, but the config needed to produce a proper dual ESM+CJS build with correct externals takes a bit of assembly.

This tool generates a working rollup.config.js from an input path, output-format toggles, an external-dependencies list, and the three most common plugins, as real ES module JavaScript.

What Is Rollup Config Generator?

A rollup.config.js generator producing an `output` array with ESM and/or CJS targets (each with sourcemaps enabled), an `external` array for dependencies that shouldn't be bundled, and optional @rollup/plugin-typescript, @rollup/plugin-node-resolve, and @rollup/plugin-commonjs entries.

The config format matches what most published TypeScript/JavaScript npm libraries actually use: a single input, multiple output formats, and dependencies left external rather than bundled in.

How Rollup Config Generator Works

Enabling ESM and/or CJS output adds the matching object (file path, format, sourcemap, and `exports: "named"` for CJS) to the `output` array; at least one format must be enabled.

Each enabled plugin toggle adds both its import statement and its constructor call to the `plugins` array, and any external dependency names you list are placed verbatim into the `external` array so Rollup leaves import/require calls for them untouched.

When To Use Rollup Config Generator

Use it when setting up a new publishable npm package with Rollup and you want correct dual ESM/CJS output without assembling the config from several documentation pages.

It's also useful for reviewing or resetting an existing library's rollup.config.js to the standard shape after config drift.

Often used alongside package.json Generator, tsconfig.json Generator and Vite Config Generator.

Features

Advantages

Produces the correct output-array shape for dual ESM/CJS publishing in one step, rather than needing to look up each format's required options separately.
External dependencies are handled explicitly, helping avoid the common library-bundling mistake of accidentally inlining a dependency that should stay external.
Covers the three plugins (typescript, node-resolve, commonjs) that cover the vast majority of real-world Rollup library configs.

Limitations

Doesn't generate a matching package.json `exports`/`main`/`module` field mapping to the emitted files; that still needs to be added manually or with the package.json Generator.
Focuses on library-style single-entry bundling; multi-entry or code-splitting Rollup setups need additional configuration beyond this output.

Examples

TypeScript library with dual output and one external dependency

Input

input: src/index.ts, outputEsm: true, outputCjs: true, external: ["zod"], useTypescript: true

Output

import typescript from "@rollup/plugin-typescript";

export default {
  input: "src/index.ts",
  output: [
    {
      file: "dist/index.esm.js",
      format: "esm",
      sourcemap: true,
    },
    {
      file: "dist/index.cjs.js",
      format: "cjs",
      sourcemap: true,
      exports: "named",
    },
  ],
  external: [
    "zod",
  ],
  plugins: [typescript()],
};

Best Practices & Notes

Best Practices

Mark every runtime dependency (and peerDependency, like react) as external for a library build, so consumers' installs, not your bundle, own those copies.
Enable sourcemaps (as this generator does by default) on both output formats, so consumers debugging into your library see original source, not minified bundle code.
Set the corresponding `main`/`module`/`types` (or `exports` map) fields in package.json to point at the emitted dist files, so both CJS and ESM consumers resolve correctly.

Developer Notes

The CJS output sets `exports: "named"` unconditionally because Rollup otherwise infers the export mode per-bundle and warns (or silently picks "auto") when a module has both named exports and no default, which is the common shape for a TypeScript library with several named exports. Plugin ordering (typescript, then node-resolve, then commonjs) follows Rollup's own convention of running the language transform first, then resolving node_modules imports, then converting any CommonJS-only dependency to ESM so the rest of the pipeline can tree-shake it.

Rollup Config Generator Use Cases

Bootstrapping rollup.config.js for a new publishable TypeScript/JavaScript library
Producing dual ESM + CJS builds for a package supporting both `import` and `require()` consumers
Resetting an existing library's Rollup config to the standard dual-output, externals-aware shape

Common Mistakes

Forgetting to mark a runtime dependency as external, causing it to get bundled directly into the published output and potentially duplicated at the consumer's install.
Shipping only one output format (commonly just CJS) when the library's actual audience includes bundler-based ESM consumers who'd benefit from tree-shakeable ESM output.

Tips

Use the package.json Generator next to set main/module/types fields pointing at the dist/index.cjs.js and dist/index.esm.js files this config produces.

Rollup Config Generator