研发协作
用 Nx 管理 monorepo 时:搭建…
在搭建或优化 Nx monorepo 工作区时,用于组织项目结构、划分库类型、约束项目边界并加速 CI。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 38/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15
适用场景
用 Nx 管理 monorepo 时:搭特定
解决思路
- 按 `apps/`(可部署应用)、`libs/`(共享库)、`tools/`(自定义 executor/generator)划分目录,工作区配置放在 `nx.json` 和 `workspace.json` 中。
- 按库类型分配职责:feature 放智能组件与业务逻辑(如 `feature-auth`)、ui 放展示型组件(如 `ui-buttons`)、data-access 放 API 调用与状态管理(如 `data-access-users`)、util 放纯函数与辅助工具(如 `util-formatting`)、shell 放应用启动引导(如 `shell-web`)。
- 需要具体模板时阅读 `references/details.md`,其中包含完整模板库和详细的可运行示例。
- 为项目一致地打 tags,并用 module boundaries(模块边界)规则强制执行这些约束。
- 尽早启用 caching(构建缓存),以大幅节省 CI 时间。
- 保持每个 lib 聚焦,只承担单一职责。
- 用 generators(生成器)创建代码,确保团队产出的一致性。
- 把项目边界写成文档,帮助新开发者理解依赖规则。
- 不要创建循环依赖,依赖图必须保持无环(acyclic)。
- 不要跳过 affected,只测试受本次改动影响的项目。
- 不要忽视边界约束,否则技术债会不断累积。
- 不要过度细粒度拆分,在库数量与维护成本之间取得平衡。
适用边界 · 注意事项
- 项目不使用 Nx(如纯 pnpm/yarn workspaces、Turborepo 或单仓库单应用),这些模式不适用。
- 只有一个应用、没有共享库与 CI 复用需求的小项目,引入 tags 与边界规则成本大于收益。