Skip to content

[Snyk] Upgrade viem from 2.43.2 to 2.43.3 #492

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dpatsora wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[Snyk] Upgrade viem from 2.43.2 to 2.43.3 #492

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions sdk/package-lock.json
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion sdk/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@
},
"dependencies": {
"abitype": "^1.2.3",
"viem": "^2.43.2",
"viem": "^2.43.3",
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Jan 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This patch upgrade of viem includes a change to the object returned by simulateContract. Specifically, the chain property is no longer part of the returned request object.

While the current implementation in sdk/src/client/services/NitroliteService.ts should handle this gracefully by relying on the walletClient's chain configuration, it highlights a potential risk with the use of as any in the executeWriteContract function (lines 39-42).

// sdk/src/client/services/NitroliteService.ts:39-42
return walletClient.writeContract({
    ...request,
    account,
} as any);

This type assertion suppresses type-checking, which means future breaking changes in viem might not be caught at compile time, leading to runtime errors.

I recommend creating a follow-up task to refactor this part and remove the as any cast. It might be possible to achieve type safety with more specific generic types or by creating a more constrained type for PreparedContractRequest instead of any.

"zod": "^3.25.76"
},
"devDependencies": {
Expand Down
Loading