Properly initialize wallet with mnemonic

[compojoom]

I'm wondering what would be the correct arguments to satisfy the Wallet constructor.

The constructor is defined as:

constructor(privateKey: BytesLike | ExternallyOwnedAccount | SigningKey, provider?: Provider) {

Leaving BytesLike aside - I feel like ExternallyOwnedAccount and SigningKey types can't satisfy the mnemonic.

On this line:
https://github.com/ethers-io/ethers.js/blob/master/packages/wallet/src.ts/index.ts#L43

We check whether the provided privateKey is an account. The Account check is whether the privateKey has a "privatekey" and "address".

This check only works if we pass an ExternallyOwnedAccount, but then an ExternallyOwnedAccount can't have a mnemonic - according to the type definition, no?
https://github.com/ethers-io/ethers.js/blob/master/packages/wallet/src.ts/index.ts#L52

SigningKey type also can't have a mnemonic, so in order to pass a privateKey with mnemonic we have to use @ts-ignore?

Also why is address commented out here? https://github.com/ethers-io/ethers.js/blob/master/packages/signing-key/src.ts/index.ts#L28

[ricmoo]

To create a Wallet from a mnemonic, you would use this method, which creates an HDNode from the Mnemonic Phrase, which satisfies the ExternallyOwnedAccount shape.

The mnemonic on an EOA become complicated, because with a password the mnemonic doesn’t correctly match the private key; the mnemonic and password are required, so additional properties are required to make sure everything understands there is a password to mix in to match the private key and address, as well the locale matters.

In v6, there has been a bit of overhaul done in this API and probably a bit more will go into it, as I’m not entirely happy with it. The Wallet has also been split into Wallet and BaseWallet (the former inheriting the latter), so that people who do not need the mnemonic support (after tree-shaking) don’t have to incur the cost of the English wordlist, base58 coding and all that jazz required for HD derivation to work.

Which is the main reason the address is not present on the SigningKey instance; if it were keccak256 would be required for that class, which is meant to be a small abstraction on top of secp256k1, since each library has its own weird API, it makes it easier to swap out and update as needed.

Does that make sense? Did I miss a question? Raise new ones? :)