010-62840732
背景
日常开发中, 管理不同仓库中多个项目和组件之间的协作变得很复杂, 甚至日常开发的调试效率也会受到影响。想要利用monorepo(单一代码库)的能力, 帮助我们更好的管理项目。如果你也在同时管理开发多个项目, 强烈建议使用单一代码库, 它将释放更多的生产力, 尤其是在前端领域。
1. 原代码仓库结构(multirepo)
多代码仓库(multirepo)：将不同的项目、组件分别存放在独立的仓库中，单独进行版本控制、构建、部署和发布，使得不同的团队可以独立地开发、测试和维护各自的模块，更容易实现并行开发和团队协作。
存在的问题
代码共享: app每个都自己维护自己的utils, 基本没共享, 共享也是copy;
开发调试：npm包有有变更要经历发版, 安装的过程，本地开发调试麻烦(npm link)；
依赖版本管理: 当不同npm包存在依赖时, 管理之间的版本也很麻烦；
项目配置文件，新老项目规范很难保证统一;
2. 解决方案： pnpm + monorepo + turbo + changeset
因为packages同时多个app提供服务, 将所有仓库合并为一个存储库, 形成单一存储库。前端很早就有很成熟的mono repo的方案, 就是为了解决传统分离式代码仓库所面临的一些痛点。目前lerna, pnpm, npm很多都支持monorepo。
3. 单一代码库如何解决之前的问题？
3.1 代码共享
app1项目package.json中添加package1:
3.2 开发调试
通过修改package.json中的main指向代码源文件, 和在同一个src下开发体验一致。
3.3 依赖版本管理
统一代码库中可以利用changeset做对版本的管理;
3.4 项目配置文件统一问题
可以将prettier, eslint等配置文件放置更目录统一管理, 不同项目作引入;
4. 新问题: 构建顺序
假设存在app1的build需要依赖pacakge1的build前置, 执行 pnpm build:app1 并不会自动执行 pnpm build:package1。
monorepo在代码管理方面确实很不错, 但是并没有提供构建方案, 例如判断项目的依赖管理, 自动处理构建顺序。
社区中存在nx, turborepo等方案, 可以在monorepo的基础上集成构建系统, 进一步提升单一代码库的流程效率。
解决方案: turborepo(nx)
5. 整个方案概述
包管理方案：pnpm(npm, yarn)
包版本方案：Changesets(lerna)
包构建方案：Turborepo(nx)
6. 优缺点
优点
代码共享：多个项目或模块之间需要共享代码和统一src下体验一致;
统一版本管理：changeset可以统一管理各个项目的版本;
简化依赖管理：减少依赖发版和后续的安装步骤，提高构建和部署效率。
协作与团队工作：团队成员可以更轻松地共享代码、协作开发和进行代码审查。
敏捷开发和迭代：加快开发和迭代周期，避免在多个代码仓库之间切换和同步。
缺点
代码仓库可能会变的很大, git clone, pull会变得慢一些, 目前体验没有感觉。倒是项目下寻找文件, 稍微有点繁琐, 目前更倾向使用vscode的cmd+p快速定位文件位置;
整个代码库架构会稍微变得复杂, 需要一些维护成本;
文件夹权限管理：项目粒度的权限管理较为困难，github、gitlab权限目前不支持文件夹级别；