代码组织

大型代码仓库的隔离和代码复用有三种方案

• npm package：将依赖拆分出单独的 repo，通过 public package 的方式复用
  • 优点：独立、成熟的版本管理机制
  • 缺点：联调复杂麻烦
• monorepo：npm package 进阶版，适合批量管理 npm package
  • 优点：多 package 联调方便，统一的规范流程
  • 缺点：灵活性低，依赖 Owner 机制、对工程化要求较高
• git submodules：将依赖拆分成独立的 repo，作为主 repo 的 submodule

TODO:Monorepo 需要考虑的问题

• 开发隔离性：所有业务代码都在一个仓库，如何做权限隔离，避免误操作
  • code owner 机制
• 发布机制：被依赖代码更新后，所有的依赖项目是否自动更新，是否需要需要经过测试，如果需要的话 package 语义化机制是否更合理？

TODO:Monorepo 业务落地

项目安装场景分为两类，业务型项目和库项目

库项目

例如 Babel、React 等框架或工具，最终产物是 package。 较大的仓库通常会拆分成多个包，这些包之间存在依赖关系。 我们需要工具帮助我们解决本地调试、统一构建、依赖管理和版本发布。

业务型项目

不同于库项目 Monorepo 主要是为了代码复用(功能代码、项目配置)

• 不需要发布 package
• 不需要编译构建

TODO:目标

1. 主项目能够独立开发、发布
2. 各项目可以便捷的共享代码
   1. 引入方便
   2. 修改方便，修改共享代码和提交
   3. 同步方便，同步其它项目对共享代码的修改
3. Code Owner 机制，对共享代码的修改设置门槛

思路：monorepo+微服务

Fixed 模式

Independent 模式