[KevinZhang19870314]

两个提交:一个补漂移本身,一个拦住让它复发的那条路。

提交 1 — 260fa31 补上漂移

package-lock.json 里 apps/merchant-cli 的版本停在 0.10.1,而 package.json 已经走到 0.10.3 —— 连漏了两次。

提交	版本	动了 lock
1d672f9	0.10.1	是
1c58adb	0.10.2	没有
9aabbf9	0.10.3	没有(我这次也漏了)

本次这一行是发 0.10.3 时 npm 自动写进工作区的。

提交 2 — 5e20da0 拦住复发

漏的根因是顺序,不是粗心

改 apps/<app>/package.json 的版本号本身不碰 lock。真正同步 lock 的是之后的 npm install / npm publish —— 而那两步发生在提交之后,于是 lock 的改动留在工作区没人管。

靠「记得改」拦不住:下一次按同样顺序发版,它还会掉在提交之后。npm ci 也拦不住 —— 它查的是依赖树,workspace 条目的 version 字段对不上它并不报错,然后严格按 lock 装,于是装出来的版本号与源码不符。workspace 包是本地链接,不影响运行行为,但排障时「现在装的是哪一版」会答错。

scripts/check-lockfile-versions.mjs(新增)

照 check-error-codes.mjs 的约定写:既可运行又可导入。

把 lock 的 packages 里属于本仓 workspace 的条目(apps/* / packages/*,跳过 node_modules/*)逐个与对应 package.json 的 version 比对。导出 checkLockfileVersions() / formatReport() / workspaceKeys();CLI 入口一致退 0、有漂移退 1、lock 读不到退 2。

formatReport 由 CLI 与发布脚本共用,保证两处的措辞和修法提示是同一份。

两个刻意的宽松处:lock 里有、磁盘上没有的包不算漂移(那不是版本问题,交给 npm 自己报);没声明 version 的包跳过(无从对账)。

两道拦截

CI — npm run check:lockfile 插在 npm ci 之后、tsc 之前。这个检查很便宜,早失败就不必等 build 与 test 跑完。

发版 — 在「即将发布」清单之后、确认之前对账。一致时打一行确认;不一致打出报告并问「仍继续发布?」,默认中止。

发布脚本这道不是重复:漂移恰恰是发版动作本身造成的,所以要在动手前把上一轮的残留问出来 —— CI 只能拦已经推上去的,拦不住本地刚攒出来的。

测试

packages/cli-core/tests/lockfile-versions.test.ts,6 条,照 error-codes-contract.test.ts 的模式(包括那条「防止检查空转」的断言):

1. 本仓当下没有漂移;
2. 真的在对账 —— checked >= 5,否则第 1 条会退化成永真;
3. 抓得到漂移,并报出两边版本与修法;
4. 只看 apps/* 与 packages/*,不理 node_modules/*;
5. lock 缺失 / 非法 JSON 报 unreadable,不误判成「一致」;
6. lock 里有、磁盘上没有的包不算漂移。

验证

项	结果
npm test	1013 passed(原 1007 + 新增 6),1 skipped
npm run check:lockfile	退 0,五个包一致
npm run type-check	退 0
node --check × 2 脚本	均退 0
漂移分支实跑	临时目录里 apps/demo lock=1.0.0 / actual=1.0.2 被正确报出

publish-packages.mjs 顶层直接调 main()(交互式),不能用 import 验证,所以只查了语法并单独确认了 check-lockfile-versions.mjs 的导出可被解析。

五个工作区包的 lock 与 package.json 现已逐一对齐:

apps/admin-cli     0.4.3     apps/merchant-cli  0.10.3
apps/payment-cli   0.5.4     apps/token-cli     0.10.3
packages/cli-core  0.2.3
不一致数量 = 0