浅谈 Monorepo 带来的效益：以 Turborepo 为例

发表于 2年以前 | 总阅读数：1128 次

前言

随着技术发展越来越进步，除了编程语言的框架越来越多以外，连项目的架构也越来越复杂了，今天这篇文章就来探讨一个算是近年越来越多开发者在讨论的项目架构：Monorepo。

什么是 Monorepo？

在一般的开发模式中，通常都是一个项目用一个仓库进行管理，假如今天要设计一个内容管理系统的产品，一般来说会提供以下两种服务。

后台管理系统。
前台页面(H5)。

这时候按照以往的开发方式，我们会创立两个仓库分别去管理这两个网站，这种项目架构的设计方式称之为：Multi-repo。

反之，当我们把这两个网站都用一个仓库进行管理，这种做法就是 Monorepo。

为什么我们需要 Monorepo？

看完上述 Monorepo 的介绍，可能读者还是会觉得有点懵，觉得集中管理跟分开管理并没有相差多少，其实除了项目上的集中管理外，Monorepo 能做到的事情还有很多。

其实 Monorepo 除了管理专案之外，也可以管理一些共用的组件，甚至是共用的 utils，这样就不用很麻烦的在两个项目上进行 ctr c + v，通常在 Monorepo 上会用以下的项目架构进行设计。

apps
  |- 后台网站
  |- 前台网站
node_modules
packages
  |- components
  |- utils

在 apps 的文件中，我们会放置真正会被执行的项目，假如日后这个项目是有机会要被 build 成 docker image 的话，这时候就可以根据 apps 文件中的项目产出相对应的 docker image，以上述的例子来看就是会产生出后台网站以及前台网站这两个 image。

在 packages 的文件中，我们就可以放置各种需要被共用的组件或者是 utils，在这边开发的共用内容就可以同时被 apps 文件内的项目使用，这样的架构设计也可以让代码写起来相当干净。

Package Manager

在 Monorepo 的世界中一个仓库底下会有很多个项目，每个项目都会有自己的 package，假如没有一个好的** package manager** 来管理这些 package 的话，最后就会让整个仓库很难被控制，因此接下来要花一点篇幅来稍微阐述一下 package manager 的用法。

以前端来说比较著名的 package manager 有以下几个：

npm
Yarn
pnpm
Rush

通常** package manager** 只负责用来处理依赖的安装，然而在 Monorepo 的架构中，我们通常都会有好几个项目在同一个文件中，这时候就必须要使用 package manager 的一个重要观念：workspaces。

workspaces 简单来说就是可以方便让你一键安装所有的依赖至 workspaces 所管理的目录内，或者是方便你安装依赖在 workspaces 所管理的目录。

想要设定 workspaces 管理的目录也很简单，只要在 package.json 中填上想要被管理目录路径就好，像下图这样：

在上图中让 workspaces 所管理的目录就包括 apps 文件以及 packages 文件内的所有第一层的文件。

想要将依赖利用 workspaces 安装到指定的目录也很简单，只要打上yarn workspace folderName add packageName 即可。

这时候打开 web 目录中的 package.json 就会发现 styled-components 真的被安装进去了非常方便。

想要移除依赖也很简单，只要把刚刚指令中的 add 改成 remove 就好。

这时候的 package.json 也就会删除掉依赖的相关资源。

Turborepo

接下来就正式进入本篇文章的重头戏：Turborepo 。

Turborepo 支持的 package manager 有 Yarn、npm、pnpm，这边以 Yarn 当作范例。

为了快速产生一个完整可用的项目架构，这边可以运行 npx create-turbo@latest 这样就可以快速产生一个基于 Turborepo 架构而生的 Monorepo 项目。

接下来进入 repo 内可以看到有一个蛮特别的文件叫 turbo.json ，这个文件主要可以用来设定一些执行指令的 pipeline，而 pipeline 主要的功能就是当你在执行 yarn run xxx时，这个指令在执行时应该要有哪些规范，想要了解更多 pipeline 设定的读者也可以参考这个网站。