升级 shadcn 后 Orval 报 Cannot find module ajv

只升级了 shadcn，原本能运行的 Orval 却开始报 Cannot find module 'ajv'，堆栈指向 ajv-formats/dist/limit.js。在 pnpm 12.13.0、12.14.0 的相关锁文件中，检查 ajv-formats 的快照是否在重新解析后变成了空对象。

这里不是 ajv 只存在于开发依赖、生产安装将它省略的普通情况。ajv-formats 3.0.1 同时把 ajv 声明为常规依赖和 optional peer。锁文件如何从带 peer 后缀的快照迁回无后缀快照，会影响这条本应保留的依赖边。

名字还在，快照里的依赖却没了

受影响场景的旧锁文件中，两个上游包引用同一份带 peer 解析信息的 ajv-formats，ajv 记在那份快照的 optionalDependencies 中。只重新解析其中一个上游后，可能得到这样的快照：

ajv-formats@3.0.1: {}

应用仍然能走到 ajv-formats，但它再加载 ajv 时失败。与修订前比较，应重点看快照键中的 peer 后缀、上游引用和快照内的依赖字段，不是仅搜索锁文件里是否出现过字符串 ajv。

一个旧锁文件能通过 --frozen-lockfile 检查，也不代表之后的重新解析必然保留依赖边。不要为了制造相同现场，照搬手工篡改锁文件的方式到业务项目。

保留锁文件，再修复解析结果

先保存清单、工作区配置与锁文件，确认实际执行的 pnpm 版本。在受控分支中，可以评估现有安装入口的修复选项：

pnpm install --fix-lockfile

这个命令会修改安装结果和可能损坏的锁文件条目，不是只读诊断。运行后审查完整差异，确认 ajv-formats 的有效快照恢复了 ajv 依赖，同时没有引入未批准的版本变化。不能把“这次安装成功”当成锁文件变化都合理。

pnpm 12.15.0 的正式源码已包含这条快照迁移路径的回归检查：重新解析一个上游后，无 peer 后缀的快照仍须保留常规依赖。通过项目既有版本管理方式采用兼容正式版后，仍需用项目的旧锁文件验证，不能只拿全新生成的锁文件作比较。

不要简单把 ajv 加到每个顶层项目来掩盖丢边，也不要删除整个锁文件或共享 store。顶层依赖偶然被找到，不能证明传递包的声明与解析结果已经一致。

从失败的调用方确认恢复

在原来会报错的 Orval 或其他调用入口验证模块解析，检查它使用的那份 ajv-formats 能找到预期 ajv。再按审定锁文件进行正常的可重复安装，确认依赖边没有在下一次解析时消失。

若快照本来就完整，继续查实际安装目录、运行入口和生产依赖策略；同样的 Cannot find module 也可能来自其他安装问题。工作区相对路径覆盖导致链接悬空，属于另一条workspace override 路径解析问题，不能用修复 peer 快照替代路径核对。