初见 monorepo

Posted 2023-02-21 一百个Chocolate

大家好，我是 Chocolate。

monorepo 不知道大家是否了解呢，我依旧记得在去年博客社区就有大佬写过这方面文章，当时对这个词语有点陌生，平常貌似也接触不到，不过算是给自己脑海中多添了一个词汇。

而在最近一个月内，我发现给我推荐了好多关于 monorepo 的文章，这让我不得不去了解一下了，于是我就在开源社区逛了逛，然后也查阅了一些资料。

发现原来现在 Vue3 也是使用了 monorepo 的方式。

点进去看，你会发现很多独立的文件夹，其实每个都代表一个仓库，而在根目录下的配置文件都是可以共享的。

当然，也查看了 vue 生态中的 vueuse，发现也是使用 monorepo。

他们大概是如下的一个结构：

.
├── package.json
└── packages/ //存放所有子 repo 目录
    ├── project_1/
    │   ├── index.js
    │   ├── node_modules/
    │   └── package.json
    ├── project_2/
    │   ├── index.js
    │   ├── node_module/
    │   └── package.json
    ...

发现痛点

大部分技术的更新都是为了解决一些业务痛点的，虽然我平常的工作我觉得和大部分人相比难度也许不是很大，在一个运营部门主要还是协助支持为主，看似很边缘，但还是能自己琢磨些东西的。

在我去年刚在公司实习的时候，组长交给了我一个任务，因为我们官网包括各产品页面其实都是公共的 header 和 footer，但是实际情况是很分散的，一个官网，旗下还有帮助中心，还有帮助文档，还有相关技术博客页面，这其实分别在 4 个代码仓库里面。

表面上看起来，我们可以分开管理，有时候运营经理需要增加一些文档，他们只需要去帮助文档的仓库添加就好了，简单的 git 推送还是能自己来做，这看起来任务进行了好的分工了对吧？

但是，他们页面的 header 和 footer 都是一样的，假设我们第三个季度需要增加了一个产品页面，此时需要添加在 header 的入口处做个引流，那我们每次更新还得去四个仓库，把相同的代码复制一份，当然，这少不了开发流程的规范，不管你改动多少，都得经历「本地自测 -> 提测->产品通过->运营通过」最后就是前端组长的代码评审 review，再就是代码授权合并，合并之后还要发车上线，有些页面需要 staging 还要验证，上线之前还得交由组长授权…

当然，具体流程根据每个组的规范不同会有一定差异，但发现没有，我仅仅是想加个入口，居然还有这么多步骤！

开始我也说了，也许部门边缘一点，需要的开发人员也不会很多，2-3 位前端就足够了，一般情况下，谁做的那个需求，就由谁来发车上线，简单来说就是一条龙咯，不管怎么样，这中间过程其实挺废时间的，但你说这个意义大吗，其实不大，很多都是重复的，也是没有太多必要的，授权这一块不仅是自己找人麻烦，被找的组长也挺麻烦，授权还要好几个。

这就是当时发现的痛点，也是当时准备要交给我的任务，不过当时我还是在实习期间，我导师也是比较建议我去做这件事情，也说了这件事情算是一个有挑战性的，可以尝试去做一做。

思考解决方式

拿到任务，当然得好好想一想，我该如何简化呢。

其实任务也很明确，就是让我做成 npm 包，这样我们不需要每次去复制代码了，而是更新一下 npm 包的版本就好了，当时的我觉得这种方式还可以，之后也在社区里面尝试去查阅了一些资料，看看是否有人做了这件事情，这里有个问题是我们的这几个项目他们底层有点区别，有些是用 hexo 搭建的，有些通过 webpack 打包的方式，而有些又是纯静态的，就是 html 来写的，没有用现在主流的框架来做。

这就有点不对劲了，这表面上大家都是相同的样子，样式和布局都一模一样，但是实现的代码又不相同，这一下就难到我了。

后续我想到了写一个 cli 的方式，因为之前大学了解过 vue-cli。既然每个仓库都是用的不同代码，那是不是可以通过脚手架方式在安装的时候选择对应的代码就好了，比如官网就选择官网的模版代码，文档页面就选择文档页面的模版代码，一一对应就好了。

看起来好像是正确的，不过在迭代会的时候，我导师说是希望我根据每个项目打包方式不同来做，cli 好像不太行，当时我其实提了这个想法，但好像直接被否决掉了，那我一下就想不到其他方式了。所以也明确说了这个可能交由现在的我来做可能不好做。

那在之后就由我导师来接手这个需求了，完成了 npm 包的方式。

npm 包抽离的方式真的好吗

那个需求已经关闭了，但是这种方式真的好吗？

随着项目迭代的进行，我发现还是依旧有之前提到的痛点问题，还是没有解决最大的痛点：我的更新还是有很多步骤，只是说原本我们是复制代码，现在只需要更新包的版本就好了，在制品库里面，我们发布 npm 包之后，再在这 4 个仓库里面逐个更新版本。

这时候还比原来多了一个维护的仓库，反而还多加了一些环节，这就是多仓库带来的问题与痛点。

那在了解了 monorepo 之后，我发现也许是该落地工程化实践了。

我的疑问

当然，我在写这篇文章的时候，我仅仅是查阅了一些资料，看了一些工程化方面的实践，我也觉得这个应该能够解决我的问题。

正好前不久说的要用 Next.js 新做一个官网，正好公司项目也都逐渐换新的了，这也许就是边缘化的好处吧，旧项目不做就不做了，也不必维护了，有新技术直接用就完事了。

那待我实践之后，才有底气继续把 monorepo 这玩意讲的清楚一点。

那对于 monorepo 其实我还是有一定疑问的，大概有如下几点吧：

• 如果将所有项目整合在一起，是否会存在大家一起做需求，然后频繁地代码冲突问题？
• 代码的 CD 发布该如何考虑，按照目前了解的是所有子项目都会同步更新，那如果在这个过程中，某个环节出了点小问题，比如某个小菜鸟混淆了一些代码，而 review 环节又不够严谨，导致某个工程崩了，那是不是发上去其它工程会有影响？
• 其实看完一些资料，就感觉有一种「分久必合，合久必分」的感觉在这里面，未来是否又会分开呢，就算是分开了是否也能解决我上述提到的痛点呢？

当然，在还没有实践之前还是会有点模糊的，也许我上面提到的问题在一些社区早就有人提过了，或者已经有解决方式了，欢迎来交流，那也期待后续我的补充吧。

本次就分享到这了，不要忘了关注和点赞~