决策讨论:为什么 IHUI-AI 选 TS Monorepo,而不是 Polyrepo?

[IHUI-INF-AI]

💬 决策讨论:为什么 IHUI-AI 选 TS Monorepo,而不是 Polyrepo?

本 Issue 对应 README 故事章节「附录 · 技术决策背后的故事 · 决策 3」
链接:https://github.com/IHUI-INF-AI/IHUI-AI/blob/main/README.md#决策-3--为什么选-ts-monorepo而不是-polyrepo

背景

8 端代码(Web / API / AI / CLI / Desktop / Extension / Mobile / Miniapp),monorepo vs polyrepo 是生死决策。

IHUI-AI 的选择

pnpm workspace + Turborepo + 13 个共享 packages

理由

• 类型对齐:8 端共享 @ihui/types,改一个类型 8 端立即感知,避免 polyrepo 的"类型漂移地狱"
• 原子提交:一个 feature 跨 8 端的改动可以一个 commit 搞定,polyrepo 要 8 个 PR
• 依赖一致性:pnpm workspace 强制版本一致,避免 polyrepo 的"依赖碎片化"
• CI 缓存:Turborepo 的远程缓存让一个独立开发者也能享受大团队的 CI 速度
• 共享 UI:@ihui/ui + @ihui/ui-primitives 让 8 端 UI 一致,polyrepo 做不到

代价

monorepo 配置复杂,但配好之后一劳永逸。

想听你说

我们愿意被说服。如果你认为 Polyrepo 更适合,请说明:

1. 规模:8 端 + 338 表 + ~1135 API + 200 页面,这个规模下 polyrepo 的优势?
2. 类型对齐:polyrepo 如何解决"类型漂移地狱"?(npm 包发布?Git submodule?)
3. 跨端改动:polyrepo 一个跨 8 端的 feature 改动如何 atomic 提交?
4. 依赖一致性:polyrepo 如何避免 8 个 package.json 的版本漂移?

相关代码

• pnpm-workspace.yaml — workspace 配置
• turbo.json — Turborepo 配置
• packages/ — 13 个共享 packages(types/database/auth/ui/config/eslint-config/tsconfig 等)

---

Labels: discussion architecture monorepo turborepo