Monorepo踩坑记：从混乱到有序的重构之路

# Monorepo踩坑记：从混乱到有序的重构之路 我们团队有6个前端项目，之前各自独立仓库，共享组件靠npm私有包，每次改个按钮要发6次包。受不了了，决定迁Monorepo。 ## Nx vs Turborepo | 特性 | Nx | Turborepo | |------|------|-----------| | 学习成本 | 高 | 低 | | 构建缓存 | 本地+远程 | 本地+远程 | | 任务编排 | 强 | 够用 | | 代码生成器 | 有 | 无 | 最后选了Turborepo，原因很简单：**够用就行**，团队学习成本更重要。 ## 踩过的坑 ```json // turbo.json - 任务依赖配置 { "pipeline": { "build": { "dependsOn": ["^build"], "outputs": ["dist/**"] }, "lint": {}, "test": { "dependsOn": ["build"] } } } ``` **坑1：幽灵依赖**。Package A没有在package.json声明某个包，但因为被提升到根目录的node_modules能正常运行，迁移后单独install就挂了。 **坑2：TypeScript路径映射**。共享包用`workspace:*`引用后，tsconfig的paths要统一配置，否则IDE识别不了。 **坑3：CI缓存命中率低**。要确保turbo.json里的`outputs`和`inputs`配置正确，否则每次都全量构建。 迁移花了两周，但之后的开发效率提升了至少3倍，值了。