Rollup配置实战详解与常见问题解决方案分享
先看效果,再看代码
最近在重构一个老项目时,我决定用 Rollup 替代原来的打包工具。为什么选它?简单说,Rollup 在打包小型库或组件时更轻量、更高效。如果你也想试试,那这篇文章就是为你准备的。
我们先来看一段核心代码:
import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';
import { terser } from 'rollup-plugin-terser';
export default {
input: 'src/index.js',
output: [
{ file: 'dist/bundle.cjs.js', format: 'cjs' },
{ file: 'dist/bundle.esm.js', format: 'es' }
],
plugins: [
resolve(),
commonjs(),
terser()
]
};
这段配置文件亲测有效,直接拿去用就行。下面我会详细讲一下每个部分的作用,以及一些踩坑点。
这个场景最好用
Rollup 的最大优势是处理模块化代码。比如你写了一个工具函数库,或者一个小型框架,Rollup 能帮你生成非常干净的代码。
举个例子,假设你的项目目录如下:
my-library/
├── src/
│ ├── index.js
│ └── utils.js
├── rollup.config.js
└── package.json
在这个场景下,Rollup 是最佳选择。它可以轻松将 index.js 和 utils.js 打包成 CommonJS 或 ES Module 格式,方便别人引用。
不过要注意的是,Rollup 默认不支持 CommonJS 模块,所以需要引入 @rollup/plugin-commonjs 插件。这一点我在第一次使用时踩过坑,折腾了半天才发现问题。
踩坑提醒:这三点一定注意
虽然 Rollup 很好用,但它也有一些坑点需要注意:
- 1. 插件顺序很重要:插件是有执行顺序的,比如
resolve()必须放在commonjs()前面。否则可能会报错,提示找不到模块。 - 2. 第三方库可能需要额外配置:如果你依赖了一些第三方库(比如 Lodash),可能会发现打包后这些库没有被正确引入。解决方法是安装
@rollup/plugin-node-resolve插件,并确保它在配置中启用。 - 3. 不支持复杂的运行时依赖:Rollup 更适合静态分析的场景。如果你的项目有很多动态加载的模块,建议还是用 Webpack。
这里多说一句,Rollup 的错误提示有时不够友好,尤其是插件配置出错时,可能会让你一头雾水。建议直接参考官方文档或社区示例,能少走很多弯路。
高级技巧:Tree Shaking 和 Code Splitting
Rollup 的 Tree Shaking 功能是我最喜欢的特性之一。它能自动移除未使用的代码,生成非常精简的打包结果。比如:
// src/utils.js
export function add(a, b) {
return a + b;
}
export function multiply(a, b) {
return a * b;
}
// src/index.js
import { add } from './utils.js';
console.log(add(1, 2));
打包后你会发现,multiply 函数根本不会出现在最终的代码中,因为它是未使用的代码。这个功能对性能优化非常有帮助。
此外,Code Splitting(代码分割)也是可以实现的,但需要一些额外配置:
import dynamicImport from '@rollup/plugin-dynamic-import-vars';
export default {
input: 'src/main.js',
output: {
dir: 'dist',
format: 'es'
},
plugins: [
dynamicImport()
]
};
不过说实话,Rollup 的 Code Splitting 并不如 Webpack 那么强大,建议仅在简单场景下使用。
结尾:这个技术的拓展用法还有很多
以上是我个人对 Rollup 配置的一些总结,希望能对你有帮助。当然,这篇文章只涉及了 Rollup 的基础用法和常见场景,其实它的扩展性很强,比如支持 TypeScript、CSS 处理等。
这个技巧的拓展用法还有很多,后续我会继续分享这类博客。如果你有更好的实现方式,欢迎评论区交流!

暂无评论