Upgrade viem to 2.54.0 and remove unused Viem bindings - #1365
Conversation
The production decode path runs through the native addon decoder (HyperSyncClient.Decoder / EvmRpcClient), so viem's decodeEventLog and its parseLogOrThrow wrapper had no callers. Drop them along with the eventLog/ decodedEvent types, the ParseError/UnknownContractName exceptions, the test that only exercised the binding, and three unused hex externals (keccak256Bytes, encodePacked, intToHex). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014mSDqCdjyqrXeUSLzgzQk2
The template injected viem@^2.0.0, a wide range that resolves to whatever 2.x is latest at install time. Pin it to an exact version so generated indexers get a deterministic, tested viem. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014mSDqCdjyqrXeUSLzgzQk2
Align the envio runtime and test_codegen scenario with the external-calls template so a generated indexer resolves a single viem copy instead of two. The runtime only uses viem's stable hex/keccak/address-checksum helpers, all verified against 2.54.0. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014mSDqCdjyqrXeUSLzgzQk2
📝 WalkthroughWalkthroughUpgrades Changesviem 2.54.0 upgrade
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/cli/src/executor/init.rs (1)
257-257: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueExact pin trades patch/security auto-updates for determinism — confirm this is intended.
Pinning generated projects to exact
2.54.0(rather than^2.54.0) means scaffolded indexers won't pick up viem patch/security fixes without a CLI release that bumps this literal. That matches the PR's determinism goal, but couples downstream users' viem security posture to your release cadence. If determinism is the priority, prefer committing a lockfile in the template over freezing the manifest, so security patches remain reachable vianpm update.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/cli/src/executor/init.rs` at line 257, The generated project dependency in init should not be hard-pinned to an exact viem version unless that is intentionally trading away patch updates; review the dependency list returned by the init generator and either switch the viem entry in the relevant match arm to a range that still allows security updates or confirm this exact pin is a deliberate template choice. If determinism is the goal, prefer handling it via the template lockfile generation path rather than freezing the manifest version literal.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/cli/src/executor/init.rs`:
- Line 257: The generated project dependency in init should not be hard-pinned
to an exact viem version unless that is intentionally trading away patch
updates; review the dependency list returned by the init generator and either
switch the viem entry in the relevant match arm to a range that still allows
security updates or confirm this exact pin is a deliberate template choice. If
determinism is the goal, prefer handling it via the template lockfile generation
path rather than freezing the manifest version literal.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f40049cb-e703-490c-b7c0-27c8339363dc
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (5)
packages/cli/src/executor/init.rspackages/envio/package.jsonpackages/envio/src/bindings/Viem.resscenarios/test_codegen/package.jsonscenarios/test_codegen/test/Viem_test.res
💤 Files with no reviewable changes (2)
- scenarios/test_codegen/test/Viem_test.res
- packages/envio/src/bindings/Viem.res
Summary
Upgrades viem dependency to 2.54.0 across the codebase and removes unused event log decoding functionality from the Viem bindings module.
Key Changes
Dependency upgrade: Updated viem from 2.46.2 to 2.54.0 in:
packages/envio/package.jsonscenarios/test_codegen/package.jsonpackages/cli/src/executor/init.rs(template initialization)Removed unused Viem bindings (
packages/envio/src/bindings/Viem.res):eventLoganddecodedEventtype definitionsdecodeEventLogOrThrowexternal bindingkeccak256Bytes,encodePacked, andintToHexexternal bindingsParseErrorandUnknownContractNameexceptionsparseLogOrThrowfunctionRemoved test file: Deleted
scenarios/test_codegen/test/Viem_test.reswhich tested the removed event log decoding functionalityImplementation Details
The removal of event log decoding functionality suggests this capability is no longer needed or has been replaced by alternative mechanisms. The retained bindings (
toHex,keccak256,pad,bigintToHex,stringToHex,boolToHex,bytesToHex,concat) cover the core hex encoding/decoding utilities that remain in use.https://claude.ai/code/session_014mSDqCdjyqrXeUSLzgzQk2
Summary by CodeRabbit
Bug Fixes
Chores