-
-
Notifications
You must be signed in to change notification settings - Fork 188
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
feat: Allow overwriting built-in keyring builders #4362
Conversation
The KeyringController comes with two built-in keyrings: Simple and HD. Unfortunately it's impossible to overwrite these because when we build a new keyring, we look for the first keyring builder in the list that matches the type we want to build, and the built-in keyrings are always first. The order has been switched so that built-in keyrings come second, after custom keyring builders. This allows them to be overwritten. This makes it possible to test behavior that is specific to simple or HD keyrings. This is something that I wanted to do in the mobile repository.
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.
LGTM! only a small change if it's relevant
keyringBuilderWithSpy.type = KeyringConstructor.type; | ||
// Not sure why TypeScript isn't smart enough to infer that `type` is set here. | ||
return keyringBuilderWithSpy as { (): EthKeyring<Json>; type: string }; | ||
} |
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.
Nit:
We can also do:
function buildKeyringBuilderWithSpy(KeyringConstructor: KeyringClass<Json>): {
(): EthKeyring<Json>;
type: string;
} {
const keyringBuilderWithSpy = jest
.fn()
.mockImplementation(
(...args) => new KeyringConstructor(...args),
) as jest.Mock & { type: string };
keyringBuilderWithSpy.type = KeyringConstructor.type;
return keyringBuilderWithSpy;
}
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.
Hmm, yes that would also work but it seems equivalent to me (in terms of type safety and readability and whatnot).
I was trying to do it with no assertion.
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 could do this without an assertion by doing something like
keyringBuilderWithSpy.type = KeyringConstructor.type
if (!hasProperty(keyringBuilderWithSpy, 'type')) {
throw new Error('Missing type');
}
TypeScript would be able to infer it then. But that would be very silly to have to do, because we already know that type
is set by that point (KeyringConstructor.type
is of type string
, it's not optional).
Explanation
The KeyringController comes with two built-in keyrings: Simple and HD. Unfortunately it's impossible to overwrite these because when we build a new keyring, we look for the first keyring builder in the list that matches the type we want to build, and the built-in keyrings are always first.
The order has been switched so that built-in keyrings come second, after custom keyring builders. This allows them to be overwritten.
This makes it possible to test behavior that is specific to simple or HD keyrings. This is something that I wanted to do in the mobile repository.
References
N/A
Changelog
@metamask/keyring-controller
Added
Checklist