lerna 还是 pnpm + changesets?monorepo 工具核心就看这三个功能

前端小白MiyueFE

共 5717字,需浏览 12分钟

 ·

2023-05-10 07:31

monorepo 是多个包在同一个项目中管理的方式,是很流行的项目组织形式。

主流的开源包基本都是用 monorepo 的形式管理的。

为什么用 monorepo 也很容易理解:

比如 babel 分为了 @babel/core、@babel/cli、@babel/parser、@babel/traverse、@babel/generator 等一系列包。

如果每个包单独一个仓库,那就有十多个 git 仓库,这些 git 仓库每个都要单独来一套编译、lint、发包等工程化的工具和配置,重复十多次。

工程化部分重复还不是最大的问题,最大的问题还是这三个:

  1. 一个项目依赖了一个本地还在开发的包,我们会通过 npm link 的方式把这个包 link 到全局,然后再 link 到那个项目的 node_modules 下。

npm link 的文档是这么写的:

e469127a7811b46ceea25de35783ccfb.webp

就是把代码 link 到全局再 link 到另一个项目,这样只要这个包的代码改了,那个项目就可以直接使用最新的代码。

如果只是一个包的话,npm link 还是方便的。但现在有十几个包了,这样来十多次就很麻烦了。

  1. 需要在每个包里执行命令,现在也是要分别进入到不同的目录下来执行十多次。最关键的是有一些包需要根据依赖关系来确定执行命令的先后顺序。

  2. 版本更新的时候,要手动更新所有包的版本,如果这个包更新了,那么依赖它的包也要发个新版本才行。

这也是件麻烦的事情。

因为这三个问题:npm link 比较麻烦、执行命令比较麻烦、版本更新比较麻烦,所以就有了对 monorepo 的项目组织形式和工具的需求。

比如主流的 monorepo 工具 lerna,它描述自己解决的三个大问题也是这个:

cdc74372c3d3dbf6467ae4655df06721.webp

也就是说,把理清了这三个点,就算是掌握了 monorepo 工具的关键了。

我们分别来看一下:

npm link 的流程实际上是这样的:

0c339151beac07a617dae14092b1c4a1.webp

npm 包先 link 到全局,再 link 到另一个项目的 node_modules。

而 monorepo 工具都是这样做的:

ae5c8feda7e43cbf07114f1b1bddbea4.webp

比如一个 monorepo 项目下有 a、b、c 三个包,那么 monorepo 工具会把它们 link 到父级目录的 node_modules。

node 查找模块的时候,一层层往上查找,就都能找到彼此了,就完成了 a、b、c 的相互依赖。

比如用 lerna 的 demo 项目试试:

      
      git clone https://github.com/lerna/getting-started-example.git

下载下来是这样的结构:

5d86cf7703c490137674c123e9c02f92.webp

执行 npm install,在根目录的 node_modules 下就会安装很多依赖。

包括我们刚说的 link 到根 node_modules 里的包:

078b61731552a3b87f8c7a315e4de2ff.webp4daa1ece2b22ef2593cd4413e0543328.webpac26a4400068a726987b287f86e5ee99.webp

这个箭头就是软链接文件的意思。

底层都是系统提供的 ln -s 的命令。

比如我执行

      
      ln -s package.json package2.json

那就是创建一个 package2.json 的软连接文件,内容和 package.json 一样。

这俩其实是一个文件,一个改了另一个也就改了:

270b97474d51400ef5152c670fbb1c13.webp

原理都是软连接,只不过 npm link 的那个和 monorepo 这个封装的有点区别。

这种功能本来是 lerna 先实现的,它提供了 lerna bootstrap 来完成这种 link:

2c7c3fbce418925e2c9111dc7758bc98.webp

只不过后来 npm、yarn、pnpm 都内置了这个功能,叫做 workspace。就不再需要 lerna 这个 bootstrap 的命令了。

直接在 package.json 里配置 workspace 的目录:

d352c250721e3cf1a64b73e8b434da55.webp

然后 npm install,就会完成这些 package 的 link。

而包与包之间的依赖,workspace 会处理,本地开发的时候只需要写 * 就好,发布这个包的时候才会替换成具体的版本。

8ce73ecee4738dd32d54598720a4629b.webp

这里用的是 npm workspace:

724b9447240af7adf2482335cbbe4cd2.webp

它所解决的问题正如我们分析的:

b405daf4c1c9e2c8e605776bb7cd00c9.webp

在 npm install 的时候自动 link。

yarn workspace 也是一样的方式:

e4f043ee699c14bc2821f6a9ec17deaa.webp

pnpm 有所不同,是放在一个 yaml 文件里的:

db79c3bee3786d4aab2dc39b8884bff8.webp

此外,yarn 和 pnpm 支持 workspace 协议,需要把依赖改为这样的形式:

d75e63727375976fef3bf37400d12f5a.webp

这样查找依赖就是从 workspace 里查找,而不是从 npm 仓库了。

5f668c90a828c911cbc1d83964801e99.webp

总之,不管是 npm workspace、yarn workspace 还是 pnpm workspace,都能达到在 npm install 的时候自动 link 的目的。

回过头来再来看 monorepo 工具的第二大功能:执行命令

在刚才的 demo 项目下执行

      
      lerna run build

输出是这样的:

1e11099c5831882e93f764d0f010e98b.webp

lerna 会按照依赖的拓扑顺序来执行命令,并且合并输出执行结果。

比如 remixapp 依赖了 header 和 footer 包,所以先在 footer 和 header 下执行,再在 remixapp 下执行。

当然,npm workspace、yarn workspace、pnpm workspace 也是提供了多包执行命令的支持的。

npm workspace 执行刚才的命令是这样的:

      
      npm exec --workspaces -- npm run build

可以简写为:

      
      npm exec -ws -- npm run build
deb897c8b6333070e1dd0faf484a7096.webp

也可以单独执行某个包下执行:

      
      npm exec --workspace header --workspace footer -- npm run build

可以简写为:

      
      npm exec -w header -w footer  -- npm run build

只不过不支持拓扑顺序。

yarn workspace 可以执行:

      
      yarn workspaces run build
d965c189b1148dab3f0268d84cd819d9.webp

但也同样不支持拓扑顺序。

我们再来试试 pnpm workspace。

npm workspace 和 yarn workspace 只要在 package.json 里声明 workspaces 就可以。

但 pnpm workspace 要声明在 pnpm-workspaces.yaml 里:

1dc39ab87ff93adc2f0ec9f066013fdf.webp

pnpm 在 workspace 执行命令是这样的:

      
      pnpm exec -r pnpm run build

-r 是递归的意思:

e27151825934b6bc07388177334576ad.webp

关键是 pnpm 是支持选择拓扑排序,然后再执行命令的:

3ec97a842b539fe9332022e64fe1e451.webp

有时候命令有执行先后顺序的要求的时候就很有用了。

总之,npm、yarn、pnpm 都和 lerna 一样支持 workspace 下命令的执行,而且 pnpm 和 lerna 都是支持拓扑排序的。

再来看最后一个 monorepo 工具的功能:版本管理和发布。

有个工具叫做 changesets 是专门做这个的,我们看下它能做啥就好了。

执行 changeset init:

      
      npx changeset init

执行之后会多这样一个目录:

7fe2d67765e7b061114b636d271743b6.webp

然后添加一个 changeset。

什么叫 changeset 呢?

就是一次改动的集合,可能一次改动会涉及到多个 package,多个包的版本更新,这合起来叫做一个 changeset。

我们执行 add 命令添加一个 changeset:

      
      npx changeset add

会让你选一个项目:

210b380d11d222fa349874e75d5b2bf0.webp

哪个是 major 版本更新,哪个是 minor 版本更新,剩下的就是 pacth 版本更新。

a1591373a1cb59e1a6686953f0a62185.webp

1.2.3  这里面 1 就是 major 版本、2 是 minor 版本、3 是 patch 版本。

之后会让你输入这次变更的信息:

6d566e4375f45bfcd7ad545b0e9588ff.webp

然后你就会发现在 .changeset 下多了一个文件记录着这次变更的信息:

d6860198ff4c0a16c9ea9bd7de638cb0.webp

然后你可以执行 version 命令来生成最终的 CHANGELOG.md 还有更新版本信息:

      
      npx changeset version

之后那些临时的 changeset 文件就消失了:

8bf94d743b1a9a28cddc92f02958560c.webp

更改的包下都多了 CHANGELOG.md 文件:

11e1bdaa8ac85e4630c8ae88edb0a20e.webpae28a3f636cc6e3a7f80412fdee35e72.webp

并且都更新了版本号:

27b1e3c741e0b30a495de5acaa2cadcd.webpc693330507398241dcbd0555eecae3f6.webp

而且 remixapp 这个包虽然没有更新,但是因为依赖的包更新了,所以也更新了一个 patch 版本:

11eaa6d9b441878fbeec44dd80d365fb.webpe8c0adcb0b0912d62a53b243de893dad.webp

这就是 changeset 的作用。

如果没有这个工具呢?

你要自己一个个去更新版本号,而且你还得分析依赖关系,知道这个包被哪些包用到了,再去更改那些依赖这个包的包的版本。

就很麻烦。

这就是 monorepo 工具的版本更新功能。

更新完版本自然是要 publish 到 npm 仓库的。

执行 changeset publish 命令就可以,并且还会自动打 tag:

8395aa5d5a1bdb9e3a7c9afc1a309443.webp

如果你不想用 changeset publish 来发布,想用 pnpm publish,那也可以用 changeset 来打标签:

39da3d58a8ab27b0abef5ccd954baf59.webp
      
      npx changeset tag
4a6931f7f80a0a38600320dfb68ee35f.webp

这就是 monorepo 工具的版本更新和发布的功能。

lerna 是自己实现的一套,但是用 pnpm workspace + changeset 也完全可以做到。

回过头来看下这三个功能:

96dfd8901a3d6cf0c6b447313f3a0699.webp

不同包的自动 link,npm workspace、yarn workspace、pnpm workspace 都可以做到,而 lerna bootstrap 也废弃了,改成基于 workspace。

执行命令这个也是都可以,只不过 lerna 和 pnpm workspace 都支持拓扑顺序执行命令。

版本更新和发布这个用 changeset 也能实现,用 lerna 的也可以。

整体看下来,似乎没啥必要用 lerna 了,用 pnpm workspace + changesets 就完全能覆盖这些需求。

那用 lerna 的意义在哪呢?

虽然功能上没啥差别,但性能还是有差别的。

lerna 还支持命令执行缓存,再就是可以分布式执行任务。

执行 lerna add-caching 来添加缓存的支持:

0ed1a4eee991a53be85f79647aac002e.webp

指定 build 和 test 命令是可以缓存的,输出目录是 dist。

那当再次执行的时候,如果没有变动,lerna 就会直接输出上次的结果,不会重新执行命令。

下面分别是第一次和第二次执行:

2836a797cc73b124f206855360d6d6a6.webp

至于分布式执行任务这个,是 nx cloud 的功能,貌似是可以在多台机器上跑任务。

所以综合看下来,lerna 在功能上和 pnpm workspace + changesets 没啥打的区别,但是在性能上更好点。

如果项目比较大,用 lerna 还是不错的,否则用 pnpm workspace + changesets 也完全够用了。

总结

monorepo 是在一个项目中管理多个包的项目组织形式。

它能解决很多问题:工程化配置重复、link 麻烦、执行命令麻烦、版本更新麻烦等。

lerna 在文档中说它解决了 3 个 monorepo 最大的问题:

  • 不同包的自动 link
  • 命令的按顺序执行
  • 版本更新、自动 tag、发布
3844cf3a63ab3a1ff408b658735f4414.webp

这三个问题是 monorepo 的核心问题。

第一个问题用 pmpm workspace、npm workspace、yarn workspace 都可以解决。

第二个问题用 pnpm exec 也可以保证按照拓扑顺序执行,或者用 npm exec 或者 yarn exec 也可以。

第三个问题用 changesets 就可以做到。

lerna 在功能上和 pnpm workspace + changesets 并没有大的差别,主要是它做了命令缓存、分布式执行任务等性能的优化。

总之,monorepo 工具的核心就是解决这三个问题。



浏览 103
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报