-
-
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
feat(expect): replace RawMatcherFn
with MatcherFunction
and MatcherFunctionWithState
types
#12376
Conversation
@@ -41,23 +41,15 @@ export default function jestExpect(config: {expand: boolean}): void { | |||
jestMatchersObject[name] = function ( | |||
this: MatcherState, | |||
...args: Array<unknown> | |||
): RawMatcherFn { |
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.
This function
has inferred return type of ExpectationResult
without this extra type.
packages/jest-jasmine2/src/types.ts
Outdated
compare(...args: Array<unknown>): ExpectationResult; | ||
negativeCompare(...args: Array<unknown>): ExpectationResult; |
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.
Puzzle. To be precise this type should be () => (...args: Array<unknown>) => ExpectationResult
, but my version eliminates these @ts-expect-error
: https://github.com/facebook/jest/blob/faef0b4b7082df574a0e4423b86d468847360f17/packages/jest-jasmine2/src/jestExpect.ts#L50-L60
Codecov Report
@@ Coverage Diff @@
## main #12376 +/- ##
=======================================
Coverage 68.47% 68.47%
=======================================
Files 324 324
Lines 16967 16968 +1
Branches 5060 5060
=======================================
+ Hits 11618 11619 +1
Misses 5317 5317
Partials 32 32
Continue to review full report at Codecov.
|
@mrazauskas can we land this now, you think? Just so the types are closer to what we want than #12363. I wanna make a new alpha release without that in it 🙂 We can still revisit of course, but not publishing stuff we know will be yanked makes sense |
@SimenB Sure. Just let me take one last look. The thing is that I got stuck trying to use the new By the way, should |
Exciting stuff! II really hope these awesome changes you're working on will let us use
Hmm, let's keep it out for now, and if there's a use case we can expose it? Always easier to add than remove stuff 😀 Semi-related - thoughts about a
Not sure, might not make sense 😀 |
ExpectationResult
instead of RawMatcherFn
(partly reverts #12363)RawMatcherFn
with MatcherFunction
and MatcherFunctionWithState
types
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.
this is great, I'm super excited about where this is going!
Same here. Thanks for good questions. It is interesting exercise to think about and to shape these types.
Sounds interesting. And then |
Wait.. So, you think |
Yep
Yeah, exactly |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
It may be not the best idea to expose
RawMatcherFn
fromexpect
. That was my initiative (see #12363), so fixing it. Easier to explain with example:https://github.com/facebook/jest/blob/faef0b4b7082df574a0e4423b86d468847360f17/packages/expect/src/types.ts#L23-L24
In the example above
RawMatcherFn
will simply turn all threenumber
types intoany
. Ups.. Found it while working on #12363 (comment). Everything what I can infer withexpect.extend({toBeWithinRange})
isfloor: any, ceiling: any
.It felt like
RawMatcherFn
should give some type safety here. For example, the number of arguments? Let’s check. Hardly possible to imagine any implementation withoutactual
(orreceived
). The rest of arguments are optional (for instance.toBeNull()
). No use ofactual: any, expected?: any, options?: any
and it is not good idea toany
types of all args.What about return type? All we need is
ExpectationResult
, right? Like this:This way one can ensure that
{ pass: boolean; message(): string; }
will be returned as required. That’s good. Also arguments are notany
. That’s also good. And it seems thatExpectationResult
is all we need internally too. Or?Edit: One more detail.
RawMatcherFn
also hasthis
type. That’s important, of course. Just checked, it all works:Test plan
Green CI.