什么是monorepo?

Monorepo 它是一种管理 organisation 代码的方式，在这种方式下会摒弃原先一个 module 一个 repo 的方式，取而代之的是把所有的 modules 都放在一个 repo 内来管理。

目前诸如 Babel, React, Angular, Ember, Meteor, Jest 等等都采用了 Monorepo 这种方式来进行源码的管理。

git 多仓库管理的缺点

1.管理调试困难2.分支管理混乱3.依赖关系复杂4.三方依赖版本可能不一致5.占用总空间大6.不利于团队协作

单体，多仓库，单体仓库

google为什么使用mono-repo_微服务

单体应用 到 多仓库 到单体仓库


单体仓库的优点：代码规范易于管理 配合自动化工具能够做到一键构建，一键部署 易于理解项目整体，开发人员有一个更好的全景视图 易于重用

谁在用monorepo

google为什么使用mono-repo_json_02

bazel

Bazel 是 Google 的一款可再生的代码构建工具。它主要是用于构建 Google 的软件,处理出现在谷歌的开发环境的构建问题,比如说:大规模数据构建问题,共享代码库问题,从源代码构建的软件的相关问题。

Bazel 支持多种语言并且跨平台，还支持自动化测试和部署、具有再现性（Reproducibility）和规模化等特征。Bazel 在谷歌大规模软件开发实践能力方面起着至关重要的作用。

google为什么使用mono-repo_json_03

Buck

BUCK 是 facebook 开源的安卓高速构建系统，速度完爆 gradle ，更多细节，请自行搜索。

10 行配置从 Android Studio + Gradle 构建体系迁移到 facebook 的 BUCK 构建体系，且保持两者同时兼容使用，编码使用 AS ，享受安卓最强大 IDE 的功能，打包、安装、测试用 BUCK ，享受安卓最快构建系统的畅快淋漓，两者互不干扰。从此妈妈再也不用担心我在编译安卓工程时睡着了，而且真的只要 10 行！

Github 地址：https://github.com/Piasy/OkBuck/blob/master/README-zh.md

示例

一个理想的 monorepo 结构：

.
├── packages
│      ├─ module-a
│      │    ├─ src            # 模块 a 的源码
│      │    └─ package.json   # 自动生成的，仅模块 a 的依赖
│      └─ module-b
│           ├─ src            # 模块 b 的源码
│           └─ package.json   # 自动生成的，仅模块 b 的依赖
├── tsconfig.json             # 配置文件，对整个项目生效
├── .eslintrc                 # 配置文件，对整个项目生效
├── node_modules              # 整个项目只有一个外层 node_modules
└── package.json              # 包含整个项目所有依赖

所有全局配置文件只有一个，这样不会导致 IDE 遇到子文件夹中的配置文件，导致全局配置失效或异常。node_modules 也只有一个，既保证了项目依赖的一致性，又避免了依赖被重复安装，节省空间的同时还提高了安装速度。

兄弟模块之间通过模块 package.json 定义的 name 相互引用，保证模块之间的独立性，但又不需要真正发布或安装这个模块，通过 tsconfig.json 的 paths 与 webpack 的 alias 共同实现虚拟模块路径的效果。

总结

现在微服务在业界比较认可的就是monorepo的结构，使用这种方式构建的微服务能够快速开发，快速迭代，而且不影响项目的复用性。