关于javascript:浅谈-Monorepo-带来的效益以-Turborepo-为例

有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。

前言

随着技术倒退越来越提高，除了编程语言的框架越来越多以外，连我的项目的架构也越来越简单了，明天这篇文章就来探讨一个算是近年越来越多开发者在探讨的我的项目架构：Monorepo。

什么是 Monorepo？

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

1. 后盾管理系统。
2. 前台页面(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 设定的读者也能够参考这个网站。

例如这边的 dev 有一个 cache 为 false 的设定，就代表著每次执行 dev 这个指令时都不要应用先前的 cache 以确保每次的开发环境都会是最新的环境。

能够看到在 turbo.json 配置项的 pipeline 基本上跟 package.json 的 scripts 指令相互对应。

能够看到在 turbo.json 这隻档案设定的 pipeline 基本上跟 package.json 的 scripts 指令都有相互对应。

其实在 apps 目录内的我的项目都有各自的 package.json，只有在这些我的项目的 package.json 内都有 dev 这个 script，Turborepo 就会主动执行这些内容。

最初再补充一点，读者在察看我的项目架构时能够看到有一个叫 packages 的目录，这个目录内内容基本上就是要提供一些共用的内容给 apps 中的我的项目。

如果要让 packages 内的某个文件容给 apps 内的某个我的项目用，这时候就能够在该我的项目 package.json 中填上对应包名，并且把版本号设定为 *，这样就能够顺利在该我的项目内援用 packages 中的内容啦！

Turborepo 开发

因为这次的范例是利用 Yarn 做为 package manager，因而这边能够下 yarn dev 来启动开发环境，这边能够看到有一个参数是 --parallel，这个参数是能够让咱们依序启动我的项目的参数，如此一来在开发环境下就不会遗记有哪个我的项目没被启动了。

之后就能够在 localhost:3000 以及 localhost:3001 看到两个我的项目的画面啦！

总结

明天介绍了 Monorepo 的我的项目架构，尽管 Monorepo 的架构看似十分好用，但其实这种我的项目架构设计并不适宜所有的产品，如果明天大家有想要试玩看看 Monorepo 但又不晓得能够怎麽下手的话，也能够利用 Monorepo 的架构设计一些 UI 库。

而且当初很多支流的 UI 库 都有应用 Monorepo 作为架构，例如：Material UI 应用 lerna、NextUI 应用文章介绍的 turborepo 等等，如果之后读者有遇到相似的应用情境无妨能够尝试看看 Monorepo 架构喔。

代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。

作者：Andy Chen 起源：medium

原文：https://medium.com/starbugs/%…