海阔天空的云

我们在自己的世界里独自狂欢

0%

pnpm初体验

pnpm

想利用它的一些优势

  • 快速 pnpm i –prefer-offline
  • workspace
  • publishConfig

整体体验很不错。

之前遇到的问题,我们有一个私有的npm包,这个包里面目前看来,有两块大的内容。

经过我的改造之后,将原来的一个包,改成了多个包,那么他的优势在哪里呢?

monorepo

monoRepo 这个概念近几年还蛮流行的,几个包,甚至是几个项目,在同一个repo里面管理,共享同一份代码,彼此之间有一定的联系,但是这些项目间又彼此独立。

说起来,我在刚刚来到这个公司大概半年多之后,就有过想要把两个项目放在同一个repo里这样的想法,只是当时没有想到这样的学术名词,也没有一些好的技术方案。

借助pnpm,其实是可以梳理成章地完成这些的。

我们之前要用刚刚说到那两块内容,比如A和B,我们的做法是在webpack里面写Alias,以及在tsconfig里面去做alias,将这两个用alias的方式去作为两个独立的内容去看待。这样做有什么问题呢?当然是有问题的,也就是说业务的项目已经对第三方的包有了感知,这种感知并不是优雅的。这也是我比较不太能够接受的。

而经过我改造之后,虽然我分拆成了多个包,但是我最后还是将这些分拆的包,放在了一个影子包里面。

monorepo借由pnpm的workspace方便地实现,同时也方便我们去进行开发和调试。包与包之间的相互引用,非常方便,我们可以指定直接使用当前workspace下的本地包,这样也方便我们进行开发。

分拆包之后,更多的新包出现

原本在一个包里面只有两个包,A和B,但是经过对项目的分析,我又添加了几个新包。每个包,都因为这种monorepo的概念,而显得非常合适。比如新添加的C包,就是一个导出umd,去做微前端项目间进行通讯的包。再来说,新添加的D包,就是一个脚本包,这个脚本包,就能够把几个项目里都用到的脚本整合在这里,避免代码的重复,利于维护。当然,刚才也说了,由于加了这么几个新包,我们也不可能每次加新包,都要去改webpack,tsconfig,这样又再次说明了之前不是一个优雅的解决方案。

速度

之前遇到的问题,大概有两点,一个是生成新包的过程略慢,当时测算了一下,每次新包build的过程,大概是6分钟。而通过pnpm去生成新包,这种缓存机制还是很明显的让速度加快的,现在大概一分多钟,就能够将包生成,当然前提是没有deps的更新等其他情况。

另一个问题,当新包生成之后,想要安装这个新包。在 npm i的时候,发现这个过程也是比较慢,经常卡顿的,通过调整代码代码结构,改成monorepo这样,也能够一定程度加速这个过程,当然,需要说明的是,对这个过程改进更明显的,应该是使用 –prefer-offline,这个即便是原生npm也是支持这一参数的。