chore(deps): clear the Dependabot alerts — viem to 2.55.19 plus toolchain bumps - #4
Merged
Conversation
viem pins ws exactly, so the two runtime-scope Dependabot alerts (CVE-2026-48779 memory-exhaustion DoS, CVE-2026-45736 uninitialized memory disclosure) could not be resolved by a lockfile refresh. 2.55.19 depends on ws@8.21.0, which patches both, so no overrides entry is needed. npm audit --omit=dev now reports 0 vulnerabilities. The remaining Dependabot alerts are all dev-scope (vitest/vite/esbuild, release-it, @pkcprotocol/pkc-js) and do not ship to consumers. Every breaking change between 2.47 and 2.55 is scoped to viem/tempo or to the ERC-20 token actions; none touch the transports, verifyMessage, getEnsAddress, decodeFunctionResult or encodeFunctionData paths this challenge uses. test/viem-client.test.ts exercises the real viem unmocked and still passes. Refs #3
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe change updates runtime and development dependency versions in ChangesDependency Version Alignment
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The dependency updates and scoped overrides preserve valid runtime resolution and supported Node requirements; no actionable merge-blocking risk remains after normal checks. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bumps the toolchain to the versions that carry the fixes:
vitest 4.0.18 -> 4.1.11 (vite/esbuild/
picomatch/postcss/nanoid/defu/fast-uri,
incl. both Vitest UI criticals)
release-it 19.2.4 -> 21.0.2 (handlebars critical,
js-yaml, brace-expansion, ip-address,
basic-ftp)
@release-it/conventional-changelog 10.0.5 -> 12.0.0 (peer of release-it 21)
@commitlint/cli 20.4.3 -> 21.2.2 (ajv -> fast-uri)
@commitlint/config-conventional 20.4.3 -> 21.2.2
commitizen 4.3.1 -> 4.3.2
Two transitives have no fixed dependent to upgrade to, so they need
scoped overrides. Both stay inside their current major:
js-yaml@^4 -> 4.3.1 (cosmiconfig 9 pins ^4.1.0)
brace-expansion@^1 -> 1.1.18 (commitizen -> glob 7 -> minimatch 3)
The rest all sit under @pkcprotocol/pkc-js, whose only npm-offered fix
is a downgrade to 0.0.46 — not an option, the challenge is written
against 0.0.85. Overriding the leaves that have a clean same-major
patch, scoped to that subtree so viem's exact ws pin is left alone:
ws 8.20.0 -> 8.21.3, uuid 13.0.0 -> 13.0.1, undici 7.24.7 -> 7.29.0
Total goes 48 -> 13. What remains is the react-native/metro/image-size
subtree pulled in by helia -> @libp2p/webrtc -> react-native-webrtc,
and protobufjs 6.x under typestub-ipfs-only-hash. Both would need
cross-major overrides on transitive internals to silence, neither ever
executes here, and pkc-js is a devDependency so none of it ships.
release-it 21 runs the existing config/.release-it.json unchanged
(verified by --dry-run: plugin loads, changelog and hooks unaffected)
and commitlint 21 accepts the existing commitlint.config.cjs. Both now
want node ^22.21.0; CI already uses node 22 latest. engines.node is
left at >=22.0.0 since that is the consumer contract and the shipped
code is unaffected.
Refs #3
Rinse12
changed the title
The bare "ws" / "uuid" / "undici" keys applied to every consumer in the @pkcprotocol/pkc-js subtree, including ones declaring an older major: react-native and metro ask for ws@^7, so the lockfile ended up recording ws@8.21.3 against a ^7 range. npm install tolerates that and writes the lock anyway; npm ci correctly refuses it, which broke CI. Adding the range selector confines each override to the major that actually has the advisory, leaving the older consumers alone: ws@^8 -> 8.21.3 (ws@7.5.13 stays; the CVEs are >= 8.0.0 only) uuid@^13 -> 13.0.1 (uuid@11.1.1 stays) undici@^7 -> 7.29.0 (undici@8.10.0 stays) Verified against a clean tree: rm -rf node_modules && npm ci exits 0, npm audit is unchanged at 13 (all dev-scope, all under pkc-js), npm audit --omit=dev is still 0, viem's own ws pin is still 8.21.0, and typecheck, build and all 98 tests pass.
The overrides were not pulling their weight, and two of them were covering for a stale lockfile rather than a real constraint. js-yaml and brace-expansion needed nothing: cosmiconfig asks for js-yaml@^4.1.0 and minimatch 3 for brace-expansion@^1.1.7, and the patched 4.3.1 and 1.1.18 both sit inside those ranges. The old lock was simply pinning stale resolutions. `npm update js-yaml brace-expansion picomatch` moves them with no package.json change. The three nested under @pkcprotocol/pkc-js could not be replaced the same way — pkc-js pins ws, undici and uuid exactly (8.20.0, 7.24.7, 13.0.0), so nothing this repo does short of an override can move them. That makes them upstream's to fix, in a pkc-js release, rather than something to paper over here. Dropping them puts the count at 18 instead of 13. Worth recording why the lockfile was refreshed surgically rather than regenerated: isows declares `ws: "*"` as a peer, so it binds to whichever ws is hoisted to the root. On a from-scratch `rm package-lock.json && npm install`, pkc-js's exact 8.20.0 wins that slot and viem's isows binds to it, putting a vulnerable ws back in the production tree — `npm audit --omit=dev` goes from 0 to 1. Rebuilding incrementally keeps viem's 8.21.0 at the root. `npm ci` reproduces that tree, so CI and Dependabot see the same thing. All 18 remaining alerts trace to @pkcprotocol/pkc-js (verified by walking `npm why` over every advisory); it is a devDependency, so none of them ship. npm audit --omit=dev is 0, npm ci exits 0, typecheck, build, commitlint and release-it --dry-run are clean, and all 98 tests pass.
Rinse12
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3.
Takes the 48 open Dependabot alerts down to 18. Runtime scope goes to zero, and every alert that remains is dev-scope and outside this repo's reach.
npm audit --omit=dev(what consumers get)npm audit(full dev tree)No
overridesblock, no source changes — the diff is dependency versions inpackage.jsonplus the lockfile.1. Runtime: viem 2.47.0 → 2.55.19
viemis the only entry independenciesand the only path to a runtime alert. It pinswsexactly (8.18.3), so neither alert could be cleared by a lockfile refresh; it had to be aviembump. 2.55.19 depends onws@8.21.0, clearing both.>= 8.0.0, < 8.21.0>= 8.0.0, < 8.20.12.47 → 2.55 review
Every
**Breaking**entry in the changelog across that range is scoped toviem/tempo(renamed Tempo Earn recovery param, removedportalAddresses,zone.waitForDepositStatus→zone.waitForTempoBlock, Tempo tokenAmountobjects) or to the ERC-20 token actions resolving symbols from the Clienttokensarray. None of that is used here.Nothing touches the paths this challenge does use —
http()/fallback()transports,verifyMessage,getEnsAddress/normalize,encodeFunctionData/decodeFunctionResult,readContract,call, or theviem/chainsexports. Two changes in range are mild improvements to those paths rather than regressions: 2.50.0 fixedgetEnsAddressdecoding of offchain DNS address records whencoinTypeis specified, and 2.55.1 added optionalblockHash/requireCanonicalparams toverifyMessage.2. Toolchain bumps
Most of the dev-scope alerts fall out of upgrading the direct devDependency that owns them:
vitestvite,esbuild,postcss,nanoid,defu,fast-urirelease-ithandlebarscritical, plusip-address,basic-ftp@release-it/conventional-changelog@commitlint/cliajv→fast-uri@commitlint/config-conventionalcommitizenThe three major bumps are all dev tooling, and both configs work unchanged:
config/.release-it.jsonas-is — verified with--dry-run --ci: the@release-it/conventional-changelogplugin loads, the changelog renders correctly forv0.1.4...v0.1.5, and thebefore:git:releasehook is unaffected. No files were touched by the dry run.commitlint.config.cjs;echo "chore(deps): x" | npx commitlintexits 0.Both now want
node ^22.21.0/>=22.12.0. CI already pinsnode-version: 22, which resolves to the latest 22.x.engines.nodeis deliberately left at>=22.0.0— that field is the consumer contract and the shipped code runs fine on 22.0; narrowing it for a dev-tool reason would be a needless breaking change for downstreams.3. Lockfile refresh, no overrides
js-yaml(3 quadratic-DoS advisories) andbrace-expansion(4 DoS advisories) looked like they needed pinning, but they did not.cosmiconfigasks forjs-yaml@^4.1.0andminimatch3 forbrace-expansion@^1.1.7— the patched 4.3.1 and 1.1.18 both sit inside those ranges, and the old lockfile was just holding stale resolutions.npm update js-yaml brace-expansion picomatchmoves them with nopackage.jsonchange at all.One subtlety worth flagging for whoever touches the lockfile next, because it is easy to trip over:
The lockfile here was therefore refreshed incrementally rather than regenerated, which keeps viem's own
8.21.0at the root.npm cireproduces that tree exactly, so CI and Dependabot resolve the same thing.4. What's left (18 alerts) and why it isn't fixable here
All 18 trace to
@pkcprotocol/pkc-js— verified by walkingnpm whyover every advisory in the audit output; nothing else in the tree is implicated. It is adevDependency, so none of it reachesnpm install @bitsocial/evm-contract-challenge.It splits into three groups, none of which this repo can move:
ws@8.20.0,undici@7.24.7,uuid@13.0.0— pkc-js pins all three exactly, the same way viem pins its ownws. No range in this repo can resolve past them; only a pkc-js release can.react-native/metro/metro-config/metro-transform-worker/image-size/@react-native/*— a React Native bundler toolchain reached viahelia→@libp2p/webrtc→react-native-webrtc. Never loaded by anything here.protobufjs6.11.6 /ipfs-unixfs/ipfs-unixfs-importer/ipld-dag-pb/@protobufjs/utf8— undertypestub-ipfs-only-hash, which pkc-js also pins exactly. Clearing these needsprotobufjs6 → 7/8, a two-major jump forced onto packages written against 6.x.npm's own suggested fix for the whole group is a downgrade to
@pkcprotocol/pkc-js@0.0.46, which is not an option: this challenge is written against 0.0.85 (see eca4c20), and pkc-js is the reference dependency for the package. 0.0.85 is the current latest, so there is nothing newer to move to either. The fix belongs upstream in pkc-js's own dependency pins.Verification
npm run typecheck— cleannpm run build— cleannpm test— 98/98 passing across all 3 files, on vitest 4.1.11npm cifrom a clean tree — exits 0, rootwsresolves to 8.21.0npm audit --omit=dev— 0 vulnerabilitiesnpx release-it --dry-run --ci— config loads, changelog correct, no files touchednpx commitlint— exits 0 on a conventional messagetest/viem-client.test.tsdeliberately does not mock viem, so its 19 tests exercise real transport construction and would have caught a transport regression from the 2.47 → 2.55 bump.