问题修复
配置、审查或排查 Rsbuild 项目时:统一配置写法…
在编写或评审 Rsbuild 应用(构建/开发命令、资源、类型检查、打包优化、调试与性能分析)时,按这套规则执行。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
配置、审查或排查 Rsbuild 项目时通用
解决思路
- 使用 `rsbuild.config.ts` 并配合 `defineConfig` 来定义配置。
- 仅当不存在 Rsbuild 一等配置项时,才使用 `tools.rspack` 或 `tools.bundlerChain`。
- 多页应用要显式定义 `source.entry` 的各个入口值。
- TypeScript 项目中优先使用 `tsconfig.json` 的路径别名(path aliases)。
- 本地开发使用 `rsbuild` 命令。
- 生产构建使用 `rsbuild build`。
- 仅把 `rsbuild preview` 用于本地生产环境预览。
- 用 `rsbuild inspect` 查看最终生效的 Rsbuild/Rspack 配置。
- 用 `@rsbuild/plugin-type-check` 在开发/构建流程中集成类型检查。
- 或者把 `tsc --noEmit` / `vue-tsc --noEmit` 作为显式脚本步骤来运行类型检查。
- 非关键代码路径优先用动态 `import()` 做代码分割/懒加载。
- 尽量选用体积轻量的库。
- 保持 browserslist 与实际兼容性要求一致。
- 从项目源码目录导入由源码管理的静态资源,不要从 `public` 导入。
- `public` 目录中的文件用绝对 URL 路径引用。
- 开启生产 source map 时,不要把 `.map` 文件发布到公开服务器/CDN。
- 排查配置解析或插件行为问题时,用 `DEBUG=rsbuild` 运行。
- 通过查看 `dist/.rsbuild` 中生成的文件来确认真实的最终配置,不要凭假设判断配置。
- 怀疑存在 JavaScript 侧开销时,使用 Node CPU profiling(`--cpu-prof`)。
- 排查编译阶段瓶颈时,设置 `RSPACK_PROFILE=OVERVIEW` 并分析 trace 输出。
- 查阅最新(v2)文档时读 http://rsbuild.rs/llms.txt。
- 查阅 Rsbuild v1 文档时读 http://v1.rsbuild.rs/llms.txt。
适用边界 · 注意事项
- 项目不使用 Rsbuild(如使用 Vite、webpack 等其它构建工具)时不适用。
- 不要用 `rsbuild preview` 承担线上部署/生产托管,它只用于本地生产预览。
- 不要因为有了 `tools.rspack`/`tools.bundlerChain` 就绕过 Rsbuild 已有的一等配置项。