前言
大家好,我是evanryuu🫠
这次给大家分享一个我们前些天经历的pnpm缓存导致线上打包失败的抽象经历。
事件过程
我们的项目部署在AWS Amplify上,跟大部分公司一样是在线上进行打包的。
项目里之前是用得npm,前些天换成了pnpm。推到线上测试分支打包,没问题。合并到主分支打包,也没问题。于是我们都觉得没啥问题了。
后来过了两天,有个新的修复要马上上线。但这时候测试服突然打包失败了。
抽象的是,我们在本地打包都没什么问题,不管是npm还是pnpm,不管是已经装好环境的电脑还是重新弄台电脑,本地都打包得很正常。
我看了看线上的报错,是这样的
说实话,看不明白这里是什么问题。所以为了偷懒选择了升级了ts和vue tsc的版本。
当然,错误没有解决,只是从几千行变成了几十行。甚至连报错的信息都没有差很多。但是由于只剩下了几十行,所以排除了很多可能性。
当时线上有一行错误非常显眼
lua
failed to load vite.config.ts
我心想:这玩意儿也能failed?啊?怎么可能呢?
然后我的目光移到了另一行报错
kotlin
xxx.yy is not a constructor
其实之前几千行报错有很多都是上面这样的,然而现在还有。于是我回去看了下还没更新依赖的报错日志。
我发现里面有很多依赖都经过了 .pnpm
这个文件夹。
原因推测
我们知道pnpm的核心原理就是软硬连接。我们安装的依赖会被pnpm放到一个全局store里,然后在项目里的 node_modules/.pnpm
文件夹则是虚拟store,它会通过硬连接指向全局store。所以不同项目如果有同样的依赖就会指向同样的全局store,也就能节省磁盘空间。
而包与包之间的关系是通过软连接(symbolic link)关联起来的,各位也可以打开pnpm的项目看看node_modules。
而在我们的线上流水线的配置文件中,配置了node_modules的缓存,像下面这样
yml
cache:
node_modules/*
所以第一次合并分支进行线上打包的时候,服务器没有node_modules的缓存,会从头安装一遍依赖,此时虚拟store和全局store关系很正常
但是由于我们设置了缓存,这就导致了第二次打包之后进来有了虚拟store的缓存,但由于全局store没了,所以硬连接指向了一片空白,所以并没有依赖文件。
这也合理地解释了为什么报错全都是 xxx.xx is not a constructor
之类的,而且路径基本都会经过 node_modules/.pnpm
。
结果
由于急着上线,所以我们直接取消了node_modules的缓存。神奇的是,pnpm在不缓存的情况下,安装+打包的速度也比有缓存的npm要快。
谨以此文记录下这次神奇的经历。
如果对你有所启发的话,也希望你可以动动小手点一个免费的赞,这会给我的创作带来很大的激励!
如果你觉得这篇文章哪里写的有问题的话,也欢迎你在评论区中指出,我们友好讨论~