-
-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
fix!: Keyring.signTypedData
accepts types for V1
#224
base: main
Are you sure you want to change the base?
Conversation
17b68dc
to
fc6bec1
Compare
@metamaskbot publish-preview |
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions.
|
Keyring.signTypedData
accepts types for V1Keyring.signTypedData
accepts types for V1
async signTypedData< | ||
Version extends SignTypedDataVersion.V3 | SignTypedDataVersion.V4, | ||
Types extends MessageTypes, | ||
Options extends { version?: Version }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be optional? It seems that previous Options
type was mandatory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ignored what was accepted before and aligned it with other keyrings. It should not represent functional changes because of the way the method implementation works: we only care about distinguishing V3 from V4, so passing an empty version would result in V3 being used
Thoughts? The Keyring
type would also accept { version: Version }
, so the keyring could actually make the argument mandatory
Co-authored-by: Charly Chevalier <[email protected]>
Co-authored-by: Charly Chevalier <[email protected]>
Keyring.signTypedData
does not support V1 #225Examples