rollup -c: Config-Driven Library Builds
rollup -c runs a build using rollup.config.js, the usual path for bundling libraries into ESM and CJS.
Rollup is the go-to for libraries because it emits clean, tree-shaken output. -c drives it from config so CI just runs one command.
What it does
rollup -c reads rollup.config.js (or a file you name after -c) and runs the build defined there: inputs, output formats, and plugins. Without a config you can drive it entirely from flags, but config is standard for real projects.
Common usage
rollup -c
rollup -c rollup.config.prod.mjs
# pass values into the config via --environment
rollup -c --environment BUILD:production
# no config, straight flags
rollup src/main.js --file bundle.js --format esOptions
| Flag | What it does |
|---|---|
| -c, --config <file> | Use a config file (default rollup.config.js) |
| --environment k:v | Set process.env values read inside the config |
| -i, --input <file> | Entry module (no-config mode) |
| -o, --file <file> | Single output file |
| -f, --format <fmt> | Output format: es, cjs, umd, iife |
| -w, --watch | Watch mode (not for CI) |
In CI
Libraries usually declare peers as external so they are not bundled; missing @rollup/plugin-node-resolve is the usual reason CI cannot find a dependency the app finds at runtime. Treat unresolved-import warnings as errors with an onwarn handler if a broken bundle should fail the job.
Common errors in CI
"(!) Unresolved dependencies" followed by "\"X\" is imported by ..., but could not be resolved" means node-resolve/commonjs plugins are missing or the dep is not installed. "Could not resolve entry module" means the input path in the config is wrong. Rollup often only warns, so a bundle can be produced yet be broken; check the warning list.