Check existing issues
Viem Version
2.46.3
Current Behavior
viem: 2.46.3
ox (bundled inside viem): 0.12.4 — this is the package containing the buggy Secp256k1.ts
Package: ox (via viem)
File: core/Secp256k1.ts, line 391
Error:
Type '{ r: bigint; s: bigint; yParity: number; } | { r: bigint; s: bigint; yParity?: number; }'
is not assignable to type '{ r: bigint; s: bigint; yParity: number; }'.
Property 'yParity' is optional in type '{ r: bigint; s: bigint; yParity?: number; }'
but required in type '{ r: bigint; s: bigint; yParity: number; }'.
Context:
When running next build, TypeScript type-checks node_modules source files (.ts).
Since ox ships raw .ts files (not just .d.ts), this internal type error surfaces as a
build-breaking compile error even with skipLibCheck: true in tsconfig.json.
Workaround: typescript: { ignoreBuildErrors: true } in next.config.js
Suggested fix: Narrow the union before passing to recoverAddress, or adjust the
type signature so yParity is consistently required/optional on both union members.
Expected Behavior
next build (and tsc --noEmit) should complete successfully without type errors originating from within ox's own source files.
Specifically, the union type used in Secp256k1.ts line 391 should be internally consistent — if recoverAddress can return a signature where yParity is optional, the type passed to Address.isEqual should accept that, or the union should be narrowed before the call so TypeScript can verify it safely.
Projects with skipLibCheck: true should not be affected by type errors inside third-party .ts source files shipped in node_modules.
Steps To Reproduce
No response
Link to Minimal Reproducible Example
No response
Anything else?
No response
Check existing issues
Viem Version
2.46.3
Current Behavior
viem: 2.46.3
ox (bundled inside viem): 0.12.4 — this is the package containing the buggy Secp256k1.ts
Package: ox (via viem)
File: core/Secp256k1.ts, line 391
Error:
Type '{ r: bigint; s: bigint; yParity: number; } | { r: bigint; s: bigint; yParity?: number; }'
is not assignable to type '{ r: bigint; s: bigint; yParity: number; }'.
Property 'yParity' is optional in type '{ r: bigint; s: bigint; yParity?: number; }'
but required in type '{ r: bigint; s: bigint; yParity: number; }'.
Context:
When running
next build, TypeScript type-checks node_modules source files (.ts).Since ox ships raw .ts files (not just .d.ts), this internal type error surfaces as a
build-breaking compile error even with
skipLibCheck: truein tsconfig.json.Workaround:
typescript: { ignoreBuildErrors: true }in next.config.jsSuggested fix: Narrow the union before passing to
recoverAddress, or adjust thetype signature so
yParityis consistently required/optional on both union members.Expected Behavior
next build (and tsc --noEmit) should complete successfully without type errors originating from within ox's own source files.
Specifically, the union type used in Secp256k1.ts line 391 should be internally consistent — if recoverAddress can return a signature where yParity is optional, the type passed to Address.isEqual should accept that, or the union should be narrowed before the call so TypeScript can verify it safely.
Projects with skipLibCheck: true should not be affected by type errors inside third-party .ts source files shipped in node_modules.
Steps To Reproduce
No response
Link to Minimal Reproducible Example
No response
Anything else?
No response