fix!: Keyring.signTypedData accepts types for V1

[mikesposito]

• Fixes Keyring.signTypedData does not support V1 #225

Examples

[mikesposito]

@metamaskbot publish-preview

[github-actions]

Preview builds have been published. See these instructions (from the core monorepo) for more information about preview builds.

Expand for full list of packages and versions.

{
  "@metamask-previews/keyring-api": "17.1.0-5f85942",
  "@metamask-previews/eth-hd-keyring": "10.0.1-5f85942",
  "@metamask-previews/eth-ledger-bridge-keyring": "8.0.5-5f85942",
  "@metamask-previews/eth-simple-keyring": "8.1.1-5f85942",
  "@metamask-previews/eth-trezor-keyring": "6.1.1-5f85942",
  "@metamask-previews/keyring-internal-api": "4.0.2-5f85942",
  "@metamask-previews/keyring-internal-snap-client": "4.0.0-5f85942",
  "@metamask-previews/eth-snap-keyring": "11.0.0-5f85942",
  "@metamask-previews/keyring-snap-client": "4.0.0-5f85942",
  "@metamask-previews/keyring-snap-sdk": "3.0.0-5f85942",
  "@metamask-previews/keyring-utils": "2.2.0-5f85942"
}

[ccharly]

Should this be optional? It seems that previous Options type was mandatory?

[mikesposito]

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

[mikesposito]

@ccharly I aligned the options type across all keyrings in 0952d0a