-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
[Feature]: Make asymmetric matcher types more useful #13812
Comments
There was somewhat similar attempt to "lie about the types" of asymmetric matchers in
I still think this can be done and should be done in separate package. See: #13334 (comment). Glad to help, but I don’t want to create this package by myself. Simply because I can’t see myself maintaining a package which I do not use.
What do you have in mind? |
Thanks, I totally forgot we can override the types of expect like that. I'm using the following types; I don't know that this is big enough to bother publishing as a package anyway but others can copy-paste this: declare module "@jest/expect" {
interface AsymmetricMatchers {
any<T>(sample: T): T extends (...args: Array<unknown>) => infer V ? V : T
anything(): any
arrayContaining<T>(sample: T): Array<T>
closeTo(sample: number, precision?: number): number
objectContaining<T extends Record<string | number | symbol, unknown>, U extends T>(sample: T): U
stringContaining(sample: string): string
stringMatching(sample: string | RegExp): string
}
} |
That’s right. Same with |
For declare type Expect {
<T>(actual: T): Matchers<void, T> & ...
} & ...
declare interface Matchers<R, T> {
toEqual(expected: T): R
...
} but the problem is we don't actually get access to declare type Expect {
<T>(actual: T): Matchers<void> & ...
} & ... so our BTW, another use case for this for us is to make the matchers be typescript assertions, so that for example after you do |
Good point. I think it is reasonable to bring back So would you be up to opening a PR? |
Matchers isn't as typed as some users would like (see jestjs#13334, jestjs#13812). For users who want to customize it by extending the `Matchers` interface, it's useful to have access to the type of `actual` (the argument of `expect`) so you can do, say, ```ts interface Matchers<R, T> { toTypedEqual(expected: T): R } ``` This commit exposes it. The first-party matchers still have the same types as before.
Sure can: #13848 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
🚀 Feature Proposal
Using Jest expect's asymmetric matchers (
anything
,arrayContaining
, etc.) in typed contexts gets very annoying very fast. For example:This is in some sense correct:
expect.arrayContaining(3)
is not, in fact, anumber[]
. But in practice you almost always want to use it as anumber[]
! The proposal here is that we should lie about the types, and say it returns anumber[]
, because that allows for greater type-safety in practice.Motivation
Right now, most places where matchers get used in vanilla jest are untyped: for example
toEqual
takes(unknown, unknown)
. But it would be nice to support a move towards having more typed assertions as suggested in #13334; and this would also be useful for a first-partywhen
as I just proposed in #13811. (In fact, I've mainly run into this when using an internal version ofwhen
.)Example
No response
Pitch
This can't really be done anywhere else, but doing it in jest is just a matter of deciding the new types are better than the old ones, and adding them! This is a breaking change, but in practice it seems unlikely that many people are using the existing (unexported) types in a rich way.
The text was updated successfully, but these errors were encountered: