Possible incorrect type in Trezor Connect for ethereumSignTypedData function

[lukeramsden]

The documentation function ethereumSignTypedData in trezor-connect stipulates you can call the function like so:

TrezorConnect.ethereumSignTypedData({
    path: "m/44'/60'/0'",
    data: eip712Data,
    metamask_v4_compat: true,
    // These are optional, but required for Trezor Model 1 compatibility
    domain_separator_hash,
    message_hash,
});

However, the types for ethereumSignTypedData list two possible function overloads:

function ethereumSignTypedData<T extends Ethereum.EthereumSignTypedDataTypes>(
    params: P.CommonParams & Ethereum.EthereumSignTypedData<T>,
): P.Response<Protobuf.EthereumTypedDataSignature>;
function ethereumSignTypedData(
    params: P.CommonParams & Ethereum.EthereumSignTypedHash,
): P.Response<Protobuf.EthereumTypedDataSignature>;

This leads to a type error if you try to call ethereumSignTypedData with both data/metamask_v4_compat AND the hash fields, despite this being ostensibly (and in my experience so far, demonstrably) supported by the implementation of the function itself.

Therefore, consumer code must resort to hacky workarounds such as:

private ethereumSignTypedData<T extends EthereumSignTypedDataTypes>(
  params: CommonParams & EthereumSignTypedData<T>,
): Response<EthereumTypedDataSignature>;
private ethereumSignTypedData<T extends EthereumSignTypedDataTypes>(
  params: CommonParams & EthereumSignTypedData<T> & EthereumSignTypedHash,
): Response<EthereumTypedDataSignature>;
private ethereumSignTypedData(
  params: CommonParams & EthereumSignTypedHash,
): Response<EthereumTypedDataSignature>;
private ethereumSignTypedData<
  T extends EthereumSignTypedDataTypes,
>(params: CommonParams & EthereumSignTypedData<T> & EthereumSignTypedHash): Response<EthereumTypedDataSignature> {
  // eslint-disable-next-line @typescript-eslint/no-unsafe-argument
  return TrezorConnect.ethereumSignTypedData(params as any);
}

Am I missing something, and this is intentional? Or can this possibly be rectified?

[szymonlesisz]

i believe this issue was already resolved in connect migration and this test proofs that using both data/metamask_v4_compat AND the hash fields should not throw type error