查看原文
其他

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

神说要有光zxg 神光的编程秘籍 2023-04-19

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 的文档是这么写的:

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

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

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

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

这也是件麻烦的事情。

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

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

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

我们分别来看一下:

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

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

而 monorepo 工具都是这样做的:

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

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

比如用 lerna 的 demo 项目试试:

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

下载下来是这样的结构:

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

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

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

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

比如我执行

ln -s package.json package2.json

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

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

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

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

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

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

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

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

这里用的是 npm workspace:

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

在 npm install 的时候自动 link。

yarn workspace 也是一样的方式:

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

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

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

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

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

在刚才的 demo 项目下执行

lerna run build

输出是这样的:

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

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

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

可以简写为:

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

只不过不支持拓扑顺序。

yarn workspace 可以执行:

yarn workspaces run build

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

我们再来试试 pnpm workspace。

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

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

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

pnpm exec -r pnpm run build

-r 是递归的意思:

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

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

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

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

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

执行 changeset init:

npx changeset init

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

然后添加一个 changeset。

什么叫 changeset 呢?

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

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

npx changeset add

会让你选一个项目:

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

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

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

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

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

npx changeset version

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

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

并且都更新了版本号:

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

这就是 changeset 的作用。

如果没有这个工具呢?

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

就很麻烦。

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

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

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

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

npx changeset tag

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

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

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

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

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

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

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

那用 lerna 的意义在哪呢?

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

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

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

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

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

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

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

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

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

总结

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

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

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

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

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

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

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

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

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

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

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存