Monorepo 就是个大坑

[BeijingBaby]

让你陷入无限折腾中。

monorepo 听起来很美好，多个项目作为子包放在同一个 repo 中，一般常听见的优点有：

1 、一次打开所有项目，尤其是一个人需要修改或维护多个项目（子包）时，不用来回切换编辑器，很直观。

2 、子包共享代码，如代码质量相关的 eslint 、prettier 、或跨 package 的代码等都可以给其他 pkg 的共享。

3 、类型共享，如前后端都是 ts 所写，则 types 可以共享不用重复定义或者担心迭代中产生不一致。

4 、ci/cd ，可以统一为整个 repo 做 ci/cd ，不再分散增加心智负担。

但是，monorepo 会给你带来无限的折腾。

首先，如果是跨语言的 mononrepo ，不同语言有不同的编码规范，根本不存在相同的 lint 或 prettier 。ci/cd 也相当于是独立项目要单独做，共享配置在这里没有带来任何好处的提升。

其次是，即使你是相同语言的 monorepo ，前期在项目架构时候也会让你消耗很多精力。

你需要创建 packages/prettier-config, packages/eslint-config...等等共享配置。

每次创建一个其他 package 你需要修改配置文件使用这些共享配置。

另外就是不同子包有不同的 eslint 配置，如 nextjs 和普通的 reactjs 项目就有不同的配置，你要么在 eslint-config 中再来一份针对 nextjs 的配置，然后修改 apps/web 引用，要么就干脆直接继承 eslint-config 再扩展 nextjs 官方推荐的配置。

这个过程非常折腾，本身 nextjs 这类项目就是开箱即用，已经有合适的 eslint 配置，你非要提取到共享的 package 中，可能大多数情况你的 monrepo 就不存在多个 nextjs 项目共享配置的情况！

好了，此时再来一个 nestjs 作为后端 api ，还得再折腾一遍 prettier-config ，eslint-config ，毕竟你都共享配置了，必须得用不是吗？

直接把这些项目的开箱即用抛弃了。

然后你的项目中要用 tailwind 或者 shadcn-ui ，你就会重复以上步骤，陷入无限的配置折腾中。

另外就是权限怎么管理，你总不想任何人都有整个 monorepo 的代码权限吧？实习生来几天直接给你代码拷走了。

multirepo 有问题吗？

其实一点问题都没有，更好的权限权利，更内聚。

一些项目本身开箱即用，创建好就能开始写业务，不用折腾什么共享配置。

或者每个项目有一些重复代码也没有任何影响，存储空间又不费钱，但是更内聚了。

要是有需求多个 repo 代码共享，统一标准，一样可以发布私有 npm 包来实现。

项目迭代中某个 repo 重构或者换语言，都根本不用考虑其他 repo ，只要对外接口保持一致就行。

个人感觉 monorepo 带来的提升很有限，不知道 v2er 的项目用的多不多，都用在什么场景？

[JoeJoeJoe]

我都是使用 vscode 的工作区来管理同一个项目里面不同的子项目, 好在 flutter 和 unity 都支持在 vscode 中直接调试.

[CHTuring]

用 monorepo 不一定要去折腾共用 prettier 或者 eslint ，这个放在各个 package 里设置 root 就可以了，这样世界不就很美好了

[kabob]

我觉得你有点钻牛角尖了，本身就是为了共享公共模块的，子包和子包如果规范不同没必要非得抽离出来，有点拿着锤子找钉子的意思了

[COW]

是否遵循了约定大于配置的原则？ Monorepo 通常是用于微服务场景，多语言是否有统一依赖或相互协作的强需求？ CI/CD 与是否 Monorepo 关系不大，但是 repo 过多，运维复杂度会飙升，反而在一个仓库中结合 Jenkinsfile + Makefile 很好做统一管理。

[WenhaoWu]

Monorepo 还好，git submodule 这位才是重量级

[COW]

@WenhaoWu 在需要定期跟踪同步第三方代码，但又不能 vendor 进自己 repo 的场景下，submodule 就非常好用，比如 hugo themes ，很典型的场景。

[wunonglin]

风格这些完全不需要公共的。

[PainAndLove]

Monorepo 适合拿收益，拿完赶紧跑 😁

[perfectlife]

别的不说，给 monorepo 做 cicd 真的是十分钟头疼，之前公司使用 mpnorepo 把安卓 ios 前端 的项目都塞在一个仓库下，cicd 一点都没有优雅可言，好多只能写死

[dssxzuxc]

去搞跨语言 monorepo 的懒得评论，属于没事找事，我就默认是 typescript monorepo

packages/eslint-config packages/prettier-config
这是错误做法，在新版本 eslint 中，一个 monorepo 应当只有一个 eslint.config 和一个 prettier.config ，它们覆盖所有要 lint 的文件，新版本扁平化配置文件能精细地针对不同文件，不同包，不同场景进行定制配置，旧版本这种到处塞屎的做法已经过时了，共享配置用得好那很好，但是多数人用不好，写得一坨狗屎，应该让最有经验的那人认真写一份集中配置，然后慢慢改进。
所有配置遵循最小化原则，像 prettier 就没几条是需要配置的，默认配置已经很好了。
尽量使用适合团队的 recommended 规则，然后在此之上进行小幅改动，能不改就最好不改。
如果团队个个都是体操大师，请选择 strictTypeChecked+stylisticTypeChecked ，如果只想凑合过过日子，那就降级成 recommendedTypeChecked ，觉得 lint 太花时间就换 strict ，断言选手太多了 recommended 也不是不行。
每个热门项目一般都有积极维护的 eslin 推荐配置，真正要自己配置的规则，其实最多也就几十条，再多那一定是因为各种历史原因堆积下来，维护者没时间去看默认配置的变更，很多开源项目就是这样，推动 lint 迭代比写代码还难，主要是性价比太低。
同上所述，tailwind/unocss 等等东西的配置文件也应该只有一份，一定需要分开的只有 packag.json 、tsconfig.json

权限管理？代码是世上最不值钱的东西，不会以为自己写出来的东西很宝贵吧？值钱的只有能赚钱的业务，这玩意是 copy 不了的。

Monorepo 不是大坑，屎山才是大坑。

[imvkmark]

@JoeJoeJoe 你的图咋传的, Pro 才有的权限 ?

[Torpedo]

个人觉得 monorepo 能火，本质就是通过 monorepo ，解决版本管理对多项目管理的不足

[dssxzuxc]

最重要的是，lint 一定要持续升级，如果以任何理由拒绝 lint 的升级，那项目引入 lint 没有任何意义。
lint 升级会强迫维护者重构自己代码，会暴露出隐藏起来的运行时隐患，升级 lint 不会破坏代码行为，只会破坏流水线，流水线不是用来看的，连 lint 都不升级那可能对代码行为产生破坏的依赖就更不会升级，那整个流水线也没多大意义，费心搞基础建设，结果不强制推动迭代，那一开始就别搞，一地鸡毛。

[renmu]

monorepo 对开源项目来说就是很大程度上加大了版本管理的心智负担，整体觉得还是利大于弊的

[weiwenhao]

原来把多个项目放到一个仓库的方式叫 monorepo, 第一次知道这个名词。 我今天刚好做了这样的事情，因为受不了 git submodule ，然后多个仓库 issue 管理起来麻烦，并且对子仓库的贡献不能很好的体现在核心项目中。

[tonytonychopper]

@imvkmark 搞个 V2EX polish 插件

[mark2025]

@weiwenhao 别用 git submodule ，太麻烦了。monorep 好得多

[Pipecraft]

@imvkmark #11 imgur 的图片就可以。很多 V2 扩展或油猴脚本支持上传图片。

[seth19960929]

monorepo 只做单语言的， 多语言的干嘛用这个

[seth19960929]

@weiwenhao 两个作用不一样
submodule 适合库分享， 比如共同的代码，比如配置读取， 日志类似的， 或者（内部的 SDK ），还有 proto 文件的共同定义+生成的代码文件
monorepo 适合项目级别划分，比如项目里的 订单 / 用户 / 商城 / 广告系统 / admin ， 我没说微服务（确实微服务很适合）， 想要按模块划分项目也可以用 monorepo

[RedNax]

以前我也搞 shared config ，eslint, prettier,webpack 甚至 tsconfig 啥的都放 share package ，巴不得哪怕一行共同代码都要 share 。结果遇到前后端、不同测试框架什么的简直要爆炸。
现在都不 share ，自己各写一份，也没多少，干净快捷方便。

[Biggoldfish]

来个搞跨语言 monorepo "没事找事"的例子

https://research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/

[conn457567]

相反，monorepo 恰好是微服务和 severless 发展后的结果，现在一个应用动不动可以拆分为十几个子程序，有些子程序其实就一个目录十几个源文件而已，如果单独建仓库，管理成本太高了，所以才有 monorepo ，服务才分了但是代码不拆分。

[superares]

你举的例子都是前端的，会不会是前端本身的问题？

[cj323]

不怎么写 js/ts 但是我经历过 multirepo 和 monorepo, 以及 monorepo -> multi repo 和 multi repo -> monorepo. 说下我的经验和看法.

总人数在四位数/团队数在三位数以下时, 我倾向 monorepo; 总人数>五位数, 我仍然倾向 monorepo, 但是实际情况往往会走向 multirepo.

我喜欢 monorepo 是因为
1. 技术上 multirepo 解决的问题往往能用更低的成本在 monorepo 里面用模块化达成, 不管是多语言还是多环境还是什么.
2. monorepo 能带来的便利, 比如版本管理, multirepo 往往难做到而且成本不小

走向 multirepo 的情况我认为往往是因为人, 不是技术
1. 法律风险
2. 团队分歧

[XTTX]

monorepo 对前端项目非常重要。apps 有 www, web, dashboard, document. ui 打包成 共享 package. 为了保证设计一致性，所有的 design token 也都是出自一出。

完全就是前期费事，后期省事。搞不明白就看那些 github repo 。复杂一点的项目都用就能说明事了。

[hucw21750]

@WenhaoWu 2 样都用了

[JoeJoeJoe]

@imvkmark 图床的话是 pro 和持有 1w V2EX 币才有, 但是我这个是用的插件直接粘贴上传的

[darklinden]

可以折中一下，多 repo 但是有个主 fake-mono-repo 搞一堆 submodule 只管管理多 repo 的版本
这样接触工程的能从主 repo 找到 tag 版本对应的分 repo 版本，分 repo 也不必关心主 repo 干了点儿啥，修改完也可以给主 repo 提 mr

[ChevalierLxc]

大家有看到过 20-30 人开发一个 repo,进一个 PR 有多难吗？

[sx931210]

用 monorepo 把公司所有项目搞一个仓库都是 sha der
monorepo 只是适合把相关性高的库放一起，比如 vue/core 那样的

[superrichman]

用 monorepo 管理的很多都是用 svn 用习惯了，现在流行用 git 了结果还是用以前 svn 的思路去管理，什么乱七八糟的都塞到一个 repo 里面去。

[ooxiaoming]

总结没事找事

[craftsmanship]

@dssxzuxc #13 太痛了 切身体会 8 年多的祖传 TS 屎山 一锤子买卖之后再也没人管过 现在让我来升 node22 人有点没了

[fadaixiaohai]

跨端项目用 monorepo 挺好的，保证两边版本一致

[SmiteChow]

不跨语言啊，跨语言干嘛？ monorepo 概念提出来的目的就是为了共享代码的啊，其他的都是副作用，跨语言怎么共享代码？

[jjx]

感觉味不对

首先,你这个是前端的角度看 monorepo , 后端怎么看?

其次, monorepo 第一有点是不切换编辑器? 当真?

第三, monorepo 大项目肯定有模块切分, 模块切分原则其实同微服务没有任何区别

[Huelse]

你这属于没经验，不知道什么东西可以共用，什么东西不可以

[leokun]

一直用 yarn 的 workspace ，全部装到 root 上，并且 root 是 app ，其他包放到 packages ，这套操作下来挺省心的

[pluswu1986]

@WenhaoWu yon 至今没用明白 submodule

[panlatent]

Monorepo 这玩意需要经验。可以去看看流行的开源项目怎么使用 Monorepo 以及为什么用。对于框架级别的开源项目来说，就是比较适合 Monorepo 的类型，记得好多年前 Symfony 的创始人分享过一次 Monorepo 的实践。我觉得本质上还是追求 DX 的前提下，减少心智负担和工作量。

[zjsxwc]

SVN+Monorepo 是常见组合了，有 svn 中央集权的权限管理。

GIT+Multirepo 也是常见组合，可以用 linux 系统自身 ssh 的用户组权限和钩子来管理每个用户对 Multirepo 每个分支的权限。

[maggch97]

没有几十个人的团队维护，用什么 monorepo 。

[hwdq0012]

react native c++ turbomodule /fabric 的项目打包成 npm 包， 不用 monorepo 真不知道怎么组织项目了，还在探索中，上个周末完测试了 react native for windows 和 react native for mac ，monorepo 方案是可行的

[imvkmark]

@tonytonychopper tks

[gowk]

https://changelog.com/posts/monoliths-are-the-future

[CitrusColaYiYi]

你 multirepo ，不也得一个个配置 eslint 和其他配置，一样的工作，monorepo 相比 multirepo 有个好处就是容易调试，不会分太散，不然不同仓库，你还得去 link ，不过主要看项目特性，采取啥方案。整体来说就是看看能不能开发成本换后期的维护成本而已。

[pakholeung372]

先看看一些大规模的项目是怎么做 monorepo 实践的好吧，像 vite 就做的比较好，可以参考一下。Facebook 这种大公司也是有各种实践的，看看 react 的仓库

[summerwar]

方案没有银弹，一劳永逸的，monorepo 也只是为了解决某个问题而已，不要想着它能解决所有问题

[FrankFang128]

看来你不知道 vscode 的 workspace

[clemente]

谷歌跑了十几年了 mono repo 了

[xiaket]

楼上看来没有真正用 bazel 管理 monorepo 的啊. monorepo 不提 Bazel 就差点意思.

[YShell]

velero 好像就是 monorepo 管理模式，使用 nx 和 npm ，类型和常量都是共享的，前端是 vue3 后端是 nestjs 不是什么大型的项目。

[mogg]

我想问，你说的这些问题，分仓难道不需要配置一遍了吗？
btw ，monorepo 是需要专门有人维护的……

[bbao]

这么多人都知道 monorepo ，让我好焦虑～

[Rorysky]

@clemente 那是谷歌，普通实体能和谷歌一样么？

[greycell]

完全看不懂在说啥，monorepo 的最大问题其实是 cicd

[ByteCat]

还好，没感觉很折腾，共享方便，我用的 turborepo ，比 nx 简单好用，当然，都是 TS

[ihciah]

monorepo 一定要配合 bazel 这种构建系统才行的。同语言的话不一定，但很难做到统一语言。