其他
大型 monorepo 中用 Bazel…
适用于用 Bazel 管理大型 monorepo、需要配置远程缓存/执行、优化构建时间、编写自定义规则或迁移到 Bazel 的场景。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 35/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 39/100 ×0.15
适用场景
大型 monorepo 中用 Bazel特定
解决思路
- 按 Bazel monorepo 典型结构组织工作区:根目录放 WORKSPACE.bazel、.bazelrc、.bazelversion、BUILD.bazel;在 apps/web、libs/utils、tools/bazel/rules 等目录放置各自的 BUILD.bazel。
- 定义 target:将库、二进制、测试等可构建单元作为 target。
- 创建 package:将包含 BUILD 文件的目录视为 package。
- 使用 label:用 //path/to:target 标识目标。
- 使用 rule:用 rule 定义 target 如何构建。
- 使用 aspect:用 aspect 实现横切构建行为。
- 需要具体模板和详细 worked examples 时,读取 references/details.md。
- 使用细粒度 target,以获得更好的缓存。
- 固定依赖版本,保证可复现构建。
- 启用远程缓存,共享构建产物;如需要则配置远程执行。
- 合理使用 visibility,强制架构边界。
- 每个目录编写 BUILD 文件,遵循标准约定。
- 不要用 glob 声明依赖,显式列出依赖更好。
- 不要提交 bazel-* 目录,将其加入 .gitignore。
- 不要跳过 WORKSPACE 设置,它是构建基础。
- 不要忽略构建警告,否则会形成技术债。
适用边界 · 注意事项
- 小型项目或单包项目:Bazel 的配置与维护成本可能高于收益,不必为简单项目引入。
- 不准备使用 Bazel,或仍在用 Maven/Gradle/npm 等构建系统且无迁移计划的场景。
- 没有远程缓存/执行基础设施,或无法维护 WORKSPACE、BUILD 依赖显式声明的团队。