背景
今年在做公司AI项目时，用的pnpm8版本做monorepo多包管理，这段时间在做公司工程化的时候，也在考虑要不要升到pnpm9版本，因为初步看v9.5.0版本推出的目录特性还是蛮心动的。之后在调研工程化所需要的几种技术栈的时候发现大多要求最低node18版本，再看pnpm9所需node版本：v18.12，我只能说：“我们一拍即合~”
然后，就踏上了pnpm9的踩坑之旅
坑列表
workspace
pnpm9默认禁用了link-workspace-packages，也就是直接安装工作区协议指定依赖会报错了：
一开始我还以为我workspace配置的有问题，然后切到pnpm8又没有问题，看了下文档才发现这个配置调整
解决方案也很简单，在.npmrc配置link-workspace-packages=true即可
另类的幽灵依赖
众所可能大家都周知pnpm解决了递归依赖带来的“幽灵依赖”问题，不知道的可以看看光神的文章，但在monorepo领域，pnpm带来了另外一个“幽灵依赖”
eg：我在根路径下安装了rollup，然后我就可以在packages声明的空间下在不声明rollup依赖的情况下直接使用
这不妥妥的“幽灵依赖”吗？？所以为了保证依赖规范，需要在core包中再安装一遍rollup，但可能导致版本不一致，那在根路径下安装全局依赖又有什么意义，全局依赖的初衷不就是为了统一版本吗
catalog
在v9.5.0版本中，新增了catalog(目录)特性，作用就是规范全局依赖的版本问题：维护唯一版本，更容易升级，更少的合并冲突。
这个特性好像解决了上面的“幽灵依赖”的问题，但它的问题在于缺少命令联动添加catalog依赖和依赖校验的能力，怎么理解这两个问题呢
依赖校验的能力
这跟我们平常使用包体验一样，没有在当前包的package.json中声明的依赖，是不可使用的
缺少命令联动添加catalog依赖
我所设想的能力是这样的：
- 在全局
package.json安装了rollup - 在
pnpm-workspace.yaml声明了catalog，添加了rollup依赖 - 在A包中
pnpm install rollup -D，或者在命令行中再传入一个catalog的选项，比如：pnpm install rollup -D --catalog，生成“rollup”: “catalog:”，流程应该是跟workspace一样，自动链接
这样解决了手动添加造成的人工出错/遗漏问题和成本
总结
以上就是这期的pnpm搭建monorepo的踩坑内容了，其中可能有什么问题可以通过配置解决的，有知道的大佬欢迎在评论区指出
