chore(deps): bump the all-dependencies group across 1 directory with 3 updates - #428
Conversation
…3 updates Bumps the all-dependencies group with 3 updates in the /packages/x402-facilitator-node directory: [viem](https://github.com/wevm/viem), [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) and [vitest](https://github.com/vitest-dev/vitest/tree/HEAD/packages/vitest). Updates `viem` from 2.56.1 to 2.56.3 - [Release notes](https://github.com/wevm/viem/releases) - [Commits](https://github.com/wevm/viem/compare/viem@2.56.1...viem@2.56.3) Updates `@types/node` from 26.4.0 to 26.4.1 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node) Updates `vitest` from 4.1.11 to 5.0.0 - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v5.0.0/packages/vitest) --- updated-dependencies: - dependency-name: viem dependency-version: 2.56.3 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: all-dependencies - dependency-name: "@types/node" dependency-version: 26.4.1 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: all-dependencies - dependency-name: vitest dependency-version: 5.0.0 dependency-type: direct:development update-type: version-update:semver-major dependency-group: all-dependencies ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
github-actions
Bot
added
the
major-update
clestons
left a comment
clestons
left a comment
There was a problem hiding this comment.
Review — #428 @ 7a5a6c594535394f407cf5f1bd161775b304b79a
意图（reviewer 自己写的一句话）：把 packages/x402-facilitator-node 的三个依赖抬到最新 —— viem/@types/node 是 patch，而 vitest 4.1.11 → 5.0.0 是 major。所以这不是一次「纯 bump」：它换掉的是这个包唯一的安全网（test/consistency.test.ts，锁着 X402Facilitator 的 EIP-712 typehash / digest 常量）的执行器。按这个意图，要回答的问题只有一个：换了执行器之后，那张网还在不在、还咬不咬人。
🔴 先说最重要的一件事：这个 PR 上的 11 个绿勾，一个都没有跑过这个包
$ grep -rniE "vitest|pnpm (run )?test|x402-facilitator|setup-node|npm test" .github/workflows/ .github/scripts/
.github/workflows/dependabot-auto-merge.yml:72: # ... Measured on #368 (actions/setup-node 6 -> 7) ... ← 只是注释
.github/workflows/abi-docs.yml:51: uses: actions/setup-node@v7 ← 根包的 ABI 文档生成
[以上是全部命中 —— vitest / pnpm test / x402-facilitator 这三个词 0 命中]
# 正对照（证明这条 grep 是活的、而且找对了树）：
$ grep -rl "forge" .github/workflows/
security.yml test.yml merge-preflight.yml abi-docs.yml
test.yml 的 test job 只跑 forge，门禁是
^(contracts/|singleton-paymaster/|foundry\.toml$|remappings\.txt$|\.github/workflows/test\.yml$|\.github/scripts/)。
本 PR 只动 packages/x402-facilitator-node/{package.json,pnpm-lock.yaml}，一条都不匹配 ——
所以那个绿勾走的是文件末尾那条
Gate not applicable (no contract-path changes) → Reporting success for the required check 'test'。
唯一装 Node 的 job 是 abi-docs.yml（Node 20），跑的是根包的 pnpm gen:abi-docs:check（根 viem ^2.47.0）；
且仓库根没有 pnpm-workspace.yaml（这个包自带独立 pnpm-lock.yaml），根目录的 pnpm install 装不到它。
所以：这个 major bump 在 CI 里是零覆盖的。下面每一条读数都是我在本地跑出来的，不是从绿勾推出来的。
我实际跑了什么（Node v22.22.2 / pnpm 10.15.1，base 与 head 各一棵独立 worktree）
| # | 命令 | base ba0214aa（vitest 4.1.11） |
head 7a5a6c59（vitest 5.0.0） |
|---|---|---|---|
| 1 | pnpm install --frozen-lockfile |
✅ viem 2.56.1 / @types/node 26.4.0 / vitest 4.1.11 | ✅ viem 2.56.3 / @types/node 26.4.1 / vitest 5.0.0 |
| 2 | pnpm test |
Test Files 1 passed (1) · Tests 21 passed (21) |
Test Files 1 passed (1) · Tests 21 passed (21) |
| 3 | pnpm run typecheck（tsc --noEmit） |
— | rc=0 |
| 4 | pnpm run build（tsc） |
— | rc=0 |
我读的是 Test Files 那一行，不只是 Tests —— 整份测试文件加载失败时 Tests 那行只会安静地变小，而 Test Files 会说出 1 failed。两侧都是 1 passed (1) 且 21 passed (21)：文件数与用例数都没缩水。
变异对照 —— 证明这 21 个绿不是空转的绿
「两侧都 21 绿」这句话，在「vitest 5 根本没执行断言」的世界里长得一模一样。所以我在 head（vitest 5）上装了一个已知的坏实装：
src/lib/verify-sig.ts:71 name: "X402Facilitator", → name: "X402FacilitatorX",
（字面量替换 + assert 打中，不用正则）
→ Test Files 1 failed (1)
Tests 2 failed | 19 passed (21)
红得很响，而且归因是对的：改的是 X402Facilitator 的 EIP-712 domain name，红的正是绑在那个 domain 上的 2 条；
走 USDC domain 的 EIP-3009 那几条、以及 scheme / ABI round-trip 那些应当仍绿，实测确实仍绿。
还原后 git diff 与 git diff --cached 都为空，重跑回到 21 passed (21)。
→ vitest 5 确实在执行这份断言，而且这份断言承重。
vitest 5 的 breaking change，逐条对到这份代码上
test/consistency.test.ts 只 import { describe, it, expect } from "vitest" —— 没有 mock、没有 fake timers、没有 locator/browser、没有 benchmark、没有 sequential/concurrent 选项、没有 expect.poll、没有未 await 的异步断言。v5 那串 breaking change 里能碰到它的只剩一条：
-
「不再向上级目录查找配置文件」 —— 实测无影响：
$ find . -path '*/node_modules' -prune -o \( -name "vite.config.*" -o -name "vitest.config.*" -o -name "vitest.workspace.*" \) -print [空] # 正对照：同一条 find 换成 tsconfig.json → 4 个文件全仓没有任何 vite/vitest 配置文件。所以既不存在「v4 在偷偷加载某个上级配置、v5 不再加载」的行为漂移，也没有配置需要迁移 —— 这是量出来的 no-op，不是假设的 no-op。
-
peer 也没断：vitest 5 要
@types/node: ^22.0.0 || >=24.0.0（实装 26.4.1 ✅）、vite: ^6.4.0 || ^7 || ^8（解析到 7.3.5 ✅）。
🔎 生产依赖图的变化比「viem patch」这个说法要大（我复核过 R2 提的这条）
只看 package.json 会以为运行时只动了 viem 一个 patch。锁文件不是这么说的：
base ba0214aa head 7a5a6c59
node_modules/.pnpm/ox@* ox@0.14.34_typescript… ox@0.14.44_typescript… ← 跨 10 个 patch
@standard-schema/spec @standard-schema+spec@1.1.0 （不存在） ← 整个被移除
node_modules/.pnpm/viem@* viem@2.56.1_… viem@2.56.3_… ← 各一份，没有分叉成两份
锁文件里 "standard-schema" 计数 3 0
正对照：锁文件里 "viem" 计数 3 3
ox 正是 viem 的 ABI / 签名原语层 —— 也就是这个包唯一真正依赖的那部分行为。
这不构成阻塞，但它改变了证据的分量：这不是「锁文件机械重生成」，而是一次真实的生产依赖图变更，目前只由我这一次本地运行覆盖着。
好消息是量具选对了：test/consistency.test.ts 正是 EIP-712 typehash + ABI round-trip 的不变量套件，硬编码的 digest 是一次性对着 X402Facilitator.sol 算出来的字面量（文件头注释明确禁止用被测 helper 反推），它在新的 viem/ox 上全绿，这本身就是这次 bump 的回归检查。
另外 viem 2.56.2 那两条行为修复（isHash 对奇数长度 hex、hexToBigInt/hexToNumber 奇数长度）在本包里没有直接调用点：
grep -rn "isHash\|hexToBigInt\|hexToNumber\|size(" src test → 空（正对照：keccak256 在 verify-sig.ts 5 处、contracts.ts 3 处、settle-args.ts 2 处）。
锁文件本身干净：两侧 lockfileVersion: '9.0'，全部 resolution 都是标准 sha512 integrity，
grep -icE "npmmirror|taobao|cnpm|registry\.np" → 0，无 registry 漂移；两侧 --frozen-lockfile 都装得下来，锁文件与 package.json 自洽。
合并机制（顺手核过，工作正常）
dependabot-auto-merge.yml 的 run log 里 outputs.update-type: version-update:semver-major，
所以 Enable auto-merge 那步被正确跳过、只有 label-major 跑了；PR 标签 dependencies, javascript, major-update，autoMergeRequest = null。
major 没有自动合并，符合该 workflow 注释里写的设计。
🟡 建议一（非阻塞，DX-only）：engines.node 声称的和实装要求的对不上
packages/x402-facilitator-node/package.json:26 "engines": { "node": ">=18" } ← 本 PR 未改
vitest@5.0.0 engines.node = "^22.12.0 || ^24.0.0 || >=26.0.0" （从装好的包里直接读的）
vitest@4.1.11 engines.node = "^20.0.0 || ^22.0.0 || >=24.0.0" （同上）
这不是本 PR 引入的缺陷，是本 PR 把口子拉宽了：base 上 >=18 就已经比 vitest 4 要求的 >=20 松了；本 PR 把开发侧的实际下限从 20 抬到 22.12。
范围要说准，别夸大 —— 三条路径分开看：
- 运行时不受影响：
Dockerfile是node:22-alpine，且vitest是 devDependency，node dist/index.js不加载它。 - install / build 也不受影响：全仓没有
.npmrc，没有engine-strict=true，pnpm 只会 warn（EBADENGINE）不会 fail；pnpm build是tsc，与 vitest 无关。 - 真正会踩到的只有一条：一个照着
docs/ECOSYSTEM-SERVICES-SETUP-GUIDE.md（第 14 行前置条件表写着Node.js | ≥ 18）在 Node 18/20/21 或 22.0–22.11 上装好环境的贡献者，去跑pnpm test。
另外说句公道话：>=18 这个字段两个方向都没被验证过 —— 从来没有人在 Node 18 上跑过这个包，而唯一的读数（21/21）是在 v22.22.2 上取的。
处方（放到单独的 PR，不要卡这个 bump；三处一起改，只改一处会留下新的不一致）：
packages/x402-facilitator-node/package.json:26→"node": ">=22.12"；docs/ECOSYSTEM-SERVICES-SETUP-GUIDE.md:14的Node.js | ≥ 18同步；- 顺带：
docs/ECOSYSTEM-SERVICES-SETUP-GUIDE.md:141的示例 Dockerfile 写的是FROM node:20-alpine，而真实的packages/x402-facilitator-node/Dockerfile:1,10写的是FROM node:22-alpine—— 这处漂移在本 PR 之前就有，一并说一声。
怎么验这条处方：在一个 Node 20 的环境里跑 pnpm test，确认它失败 —— 那次失败就是「>=18 这个字段是错的」的证据。判据只到「红/绿」为止，我不指定它红成什么样。
（
🟠 建议二（非阻塞，但比上一条重要，而且 dependabot 修不了）
给 packages/x402-facilitator-node 加一个 CI job。 目前它的 21 条不变量测试、typecheck、build 在 CI 里全部无人执行 —— 也就是说任何改到这个包的 PR（不只是依赖 bump），拿到的绿勾都不包含它。这次是我手动跑才有证据，下一次可能没有人跑。
最小形状（Node 22.12+）：
- uses: actions/setup-node@v7
with: { node-version: 22 }
- run: corepack enable
- working-directory: packages/x402-facilitator-node
run: pnpm install --frozen-lockfile && pnpm run typecheck && pnpm test怎么验：合进去之后，在下一个锁文件 bump 的 PR 上跑 gh pr checks，确认这个 job 出现在列表里 —— 今天这个 PR 的 11 个 check 里，它一个都不在。
（注意：test.yml 顶部那段注释已经解释过这个仓库为什么不用 paths: 去控制必需检查。这个新 job 若要设成 required，请照它那套「门禁判断放在 job 内部」的做法，不要再引入一个 paths-filter 的必需检查。）
⚪️ 附带记一笔（先于本 PR 存在，不属于本 PR 范围，不要在这里改）
packages/x402-facilitator-node/Dockerfile:5 和 :14：
5: RUN pnpm install --frozen-lockfile 2>/dev/null || pnpm install
14: RUN pnpm install --frozen-lockfile --prod 2>/dev/null || pnpm install --prod
--frozen-lockfile 一旦失败就静默回退到不锁版本的重新解析，而 2>/dev/null 把失败原因也一起丢了；
第 4/13 行的 COPY package.json pnpm-lock.yaml* ./ 里那个 * 还意味着锁文件缺失也不会报错。
后果是：这个 PR 建立的版本钉子，不保证就是镜像里真正装进去的版本 —— viem: ^2.56.3 在构建镜像那一刻可以解析成任何更晚的 2.x。
记在这里是因为它正好是「锁文件 bump 类 PR 的分量比看上去低」的那个机制，值得单开一个 issue，但不该卡住本 PR。
结论：APPROVE
APPROVE 即表示本仓库可以直接合并这个 PR。（我自己不执行合并 —— 那是仓库这边的动作。）
依据是实测，不是绿勾：
- 两侧
Test Files 1 passed (1)/Tests 21 passed (21)，文件数与用例数都不缩水； - vitest 5 下的变异对照红得响、且归因正确（2 红 / 19 应绿仍绿），证明这份断言仍在执行且承重，还原后工作树干净；
typecheck+buildrc=0；- v5 的 breaking change 逐条对下来只有「不再查找上级配置」可能相关，而全仓零 vite/vitest 配置（find 带正对照）—— 量出来的 no-op；
- 生产依赖图的真实变化（
ox0.14.34→0.14.44、@standard-schema/spec移除）正好落在那份 EIP-712 / ABI 不变量套件的覆盖面内，且它是绿的； - 锁文件无 registry 漂移、无重复安装分叉。
两条建议都非阻塞：engines 那条是本 PR 之前就存在、本 PR 拉宽了的声明不一致，且只影响「贡献者跑测试」这一条路径；CI 覆盖那条是仓库级缺口，dependabot 改不了。拿它们卡住一个 dependabot bump 属于扩大范围，只会把 bump 停在原地。
⚠️ 一句提醒，因为它决定了上面这些读数的有效期：这 11 个绿勾没有覆盖这个包，而以上全部结论都锚在7a5a6c594535394f407cf5f1bd161775b304b79a这一棵树上。此后若有新 commit 落到这个 PR 上，上面的测量不自动延续；同样，以后有人改动packages/x402-facilitator-node时，请不要把test的绿当成它被测过了 —— 在补上 CI job 之前，那里只有本地手跑这一条路。
🔎 自评
- 轮数：3 轮实跑（R1a + R1b DeepSeek → 我自己的机械验证 → Opus R2 独立评审）。 triage 我记的是 4-round（major bump，按安全偏置升档）；post-R2 严重度闸门判定全 Low/建议 → 按 skill 规定跳过 Codex R3；Opus R2 同时把 triage 下调为 2-round（
R2_TRIAGE_CONFIRM: 2-round），因此未跑 R4，裁决走 2-round 路径。不虚标 4-round。 - 机械证据：双 worktree install/test/typecheck/build；vitest 5 下的字面量变异对照（2 failed | 19 passed）并还原验空；engines 字段从装好的包里直接读；CI 覆盖用带正对照的 grep 判空；find 判无 vite 配置（带正对照）；锁文件 registry 判零；
.pnpm目录逐个核 ox / @standard-schema / viem 的实装版本与份数。 - DeepSeek flash 评级：4/5 —— R1a 那条 finding（
engines >=18vs vitest 5 需 Node ≥22.12）方向正确、事实成立，是本轮唯一由外部模型提出的真问题。扣分在：它把严重度定成 Medium，没区分「运行时 / install / 仅pnpm test」三条路径，也没意识到这在 base 上就已存在（vitest 4 要 ≥20）；而且它开的处方（钉回 vitest 4.x）方向是反的。R1b 判「无安全面」正确。
改进建议：给 R1 的 prompt 里附上Dockerfile与.npmrc的存在与否，它对「dev vs runtime」的分不清多半来自看不到这两样。 - 我驳回了哪些 finding：① R1a 的处方「或把 vitest 钉回 4.x」—— 驳回，理由是为迁就一个已经过期的
engines字段而回退依赖属于因果颠倒；我保留了它指出的机制（版本区间不一致确实存在），只换了处方方向。②「R1a 严重度 Medium」下调为 Low —— 依据是我实测的三条路径拆分（无.npmrc→ pnpm 只 warn；vitest 不进--prod镜像；pnpm build是纯 tsc）。
Reviewed by PR-Daemon · head 7a5a6c594535394f407cf5f1bd161775b304b79a
2 participants
Bumps the all-dependencies group with 3 updates in the /packages/x402-facilitator-node directory: viem, @types/node and vitest.
Updates
viemfrom 2.56.1 to 2.56.3Release notes
Sourced from viem's releases.
Commits
3db6cdfchore: version package (#5060)1ba6aa3feat(tempo): infer multisig request chains (#5061)e3de334fix(tempo): expose zone return type (#5059)9a6f9aafix: update browserslist security overrideabfa9d1chore: update esm size limit31ad9fdtest: stabilize tempo error snapshots1bf8f74chore: version package (#5054)32ba41ftest(tempo): update decorator type benchmark390b48fchore: up changesete96cc4dtest(tempo): fix multisig CI fixturesUpdates
@types/nodefrom 26.4.0 to 26.4.1Commits
Updates
vitestfrom 4.1.11 to 5.0.0Release notes
Sourced from vitest's releases.
... (truncated)
Commits
f441c6fchore: release v5.0.0 (#11130)d46a747fix: treat test.describe as a suite during static collection (#11128)584cf30fix: add a warning if inline project has duplicate plugins due to unexpected ...f08ce4bfix: apply queued mocks from doMock() in queue order (fixes #10706) (#11127)897f51fchore: release v5.0.0-rc.4 (#11107)1339b06chore(deps): update all non-major dependencies (#11104)51e9494feat!: parse files statically in vitest list by default (#11088)2122ffdfix: propagate --maxWorkers to projects (#11102)dc10f5ffix(browser): report the action error when a task times out (#11101)d4fe198feat: promote clearCache out of experimental (#11086)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions