v0.8.8
0.8.8 (2026-08-24)
🐛 Bug Fixes
详细说明 —— 每条改动的现象 / 根因 / 实测数字（1 条）
fix(banner): 升级命令必须带具体版本号 —— @latest 时好时坏
上一版把 up 改成 add,以为解决了。没有:add @latest 也会失败,取决于 lockfile
当时的状态。端到端验证(装 0.8.7)当场打回。
逐个实测(都在真实 profile 上跑,版本刚发布几分钟):
up @latest 「Already up to date」,原地不动 ✗
up -L 同样原地不动 ✗
add @latest 时好时坏 —— 0.8.5→0.8.6 成功,0.8.6→0.8.7 失败
add @0.8.7 每次都真的装上(downloaded 1, added 1) ✓
排查排除了三个方向:
· 不是 registry 传播延迟 —— 直连 / npm view / pnpm view 三处 dist-tags 都已是新版
· 不是 packument 缓存 —— 缓存目录压根不存在,删了也没变化
· 不是 minimumReleaseAge —— 同一时刻显式版本号能装上同一个版本
真正原因:pnpm 优先复用 lockfile 里已有的解析结果。lock 记着
specifier: ^0.8.6 / version: 0.8.6,@latest 就被判定「已满足」而跳过。
这解释了为什么 add @latest 时好时坏 —— 我之前那次成功,是因为刚跑过
add @0.8.5 把 lock 重写成了 0.8.5。
修法:命令里直接带上横幅已经知道的版本号(标题里那个「有新版本 0.8.7 可用」)。
一次绕开全部:不依赖 pnpm 怎么解析 latest、不受 lock 影响,而且对用户更明确 ——
命令里的版本号和标题里的是同一个。
教训:「改完看起来对了」不等于修好了。前一版我只验证了 add 在一个特定
lock 状态下成功,就下了「up 不行 add 行」的结论 —— 端到端跑一次真实升级
立刻就翻了。要验证的是用户会走的那条路,不是我手头凑出来的那次。
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
9b3d32e
