Even if KeyringControllerOptions correctly forbid cacheEncryptionKey: true with an encryptor that doesn't support key export, Typescript is unable to correctly infer that cacheEncryptionKey is of type true instead of the more generic boolean.

Hmm, I feel like this is happening because of the way that we're working with the options. It knows that in the argument that the constructor takes, if cacheEncryptionKey is true then encryptor may be an ExportableKeyEncryptor, and if cacheEncryptionKey is false then encryptor may be a GenericEncryptor or a ExportableKeyEncryptor. However, the destructuring kind of screws this up and divorces these options from each other, so from TypeScript's perspective, cacheEncryptionKey is just a boolean and encryptor can be GenericEncryptor | ExportableKeyEncryptor | undefined. Because options can be in two different forms, we need to preserve it. We also need to take TypeScript down one of two code paths depending on which one it is.

In other words we could do something like this:

  constructor(options: KeyringControllerOptions) {
    const {
      syncIdentities,
      updateIdentities,
      setSelectedAddress,
      setAccountLabel,
      keyringBuilders,
      messenger,
      state,
    } = options;

    // ...

    if (options.cacheEncryptionKey) {
      this.#keyring = new EthKeyringController({
        initState: state,
        encryptor: options.encryptor,
        keyringBuilders,
        cacheEncryptionKey: options.cacheEncryptionKey,
      });
    } else {
      this.#keyring = new EthKeyringController({
        initState: state,
        encryptor: options.encryptor,
        keyringBuilders,
        cacheEncryptionKey: options.cacheEncryptionKey ?? false,
      });
    }

    // ...
  }

The downside to this approach is that we now need to remove some of the JSDoc for the constructor. But that would get you what you want.

Yeah the destructuring is definitely behind us losing this type information. That seems like a good suggestion to me.

There is no need to remove the TSDoc breakdown of the properties though. The linter only requires that the properties be defined if they are destructured, but they're always allowed.

Thanks! I applied the suggestion