beizhu
type
Post
status
Published
date
Jun 30, 2023
slug
summary
Monorepo一些思考点 和 疑问？
tags
思考
基建
工具
category
技术
icon
password
阶段一：单仓库巨石应用， 一个 Git 仓库维护着项目代码，随着迭代业务复杂度的提升，项目代码会变得越来越多，越来越复杂，大量代码构建效率也会降低，最终导致了单体巨石应用，这种代码管理方式称之为 Monolith。
阶段二：多仓库多模块应用，于是将项目拆解成多个业务模块，并在多个 Git 仓库管理，模块解耦，降低了巨石应用的复杂度，每个模块都可以独立编码、测试、发版，代码管理变得简化，构建效率也得以提升，这种代码管理方式称之为 MultiRepo。
阶段三：单仓库多模块应用，随着业务复杂度的提升，模块仓库越来越多，MultiRepo这种方式虽然从业务上解耦了，但增加了项目工程管理的难度，随着模块仓库达到一定数量级，会有几个问题：跨仓库代码难共享；分散在单仓库的模块依赖管理复杂（底层模块升级后，其他上层依赖需要及时更新，否则有问题）；增加了构建耗时。于是将多个项目集成到一个仓库下，共享工程配置，同时又快捷地共享模块代码，成为趋势，这种代码管理方式称之为 MonoRepo。
思考
1：
1.团队能否驾驭？
大仓开发意味着团队每个人有全部项目的代码权限，严格的CR机制，自动化构建、测试流水线、团队整体代码水平这些都得有一定规模和经验。试想某个周五的下午一个公司新人提交了一段神秘代码，然后周末整个公司的项目全都挂了
2.产出是否步调一致？
无论是react还是vue他们采用Monorepo更多是因为他们产出步调一致并且存在相互关联场景，合在一起也能作为一个单独的项目发布。但是在普遍的业务项目开发中产出基本都是独立的项目，没有太多联系。例如，多个项目共用一个组件，如果有一天项目A对该组件有独特需求，这个需求是破坏性的，这时候如果步调不统一，其他项目怎么办？要么其他项目被迫升级，要么公共组件库粘贴复制一份用来满足这个独特需求。
综上所述，Monorepo更适合框架、工具类库开发，业务项目最好还是独立代码仓库的好。
2：
babel vue 等这样的仓库， 他们的目标只在专业的领域做专业的事情， 目标是为上层业务代码提供辅助；
但是实际的上层业务形态千奇百怪， monorepo 确实在一定程度上解决了 “公共模块复用性” ； 同时在大型项目中， 也会存在， git仓库臃肿， 源代码庞大等情况出现； code review 的成本也间接提升
3：
1. 代码重复：
在复用程度较高的项目monorepo确实方便，省去了npm包调试和发布的时间。但有些场景（如后台管理业务页面之间）定制化需求较多时，不复用反而迭代更方便。
2.版本管理：
npm包升级后如果有breaking change，可以通过npm包版本规范约定处理。宿主项目需要升级时单独测试单独上线影响范围较小；反而monorepo的方式影响范围更大
3. 集中管理：
多个项目权限统一回更好吗？
4：
结果就是编译时间奇长无比，改一行代码，想看看效果，发现要等半根烟的时间。
5：
其实就跟DDD和微前端一样，是战略层面的东西，是分析怎么组织monorepo，什么时候用monorepo的问题，而不是用了monorepo以后来想干什么的问题
6：
monorepo的使用场景更多是框架，举个例子你要写个 ANTD组件库，组件库下面很多包，有core核心的，plugin负责插件的等等，这种情况是适用于monorepo的，因为这些包之间往往有互相的引用，此外，对于版本管理来说比较方便。
对于业务项目来说，业务项目其实跟版本，你迭代你的需求就完了，你的package.json一辈子可能都不会改，而且你的几个子项目之间可能关联不紧密，此外每个项目可能都很大。这种情况下，使用常规的多仓库管理也是OK的，还有一个情况是，多仓库 对于权限管理是比较方便的