-
-
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(jest-expect): re-export Matchers
and MatcherFunctionWithState
interface
#12418
Conversation
Hmm, it depends! Are the matchers for Jest specifically, or Snapshots need runtime support, so makes sense for them to be separate, but I'd assume most matchers doesn't need that and can safely extend the base Doesn't hurt to re-export of course, but unsure of changing the example |
Agreed. The example is reverted. |
@@ -5,8 +5,7 @@ | |||
* LICENSE file in the root directory of this source tree. | |||
*/ | |||
|
|||
import {expect} from '@jest/globals'; | |||
import type {MatcherFunction} from 'expect'; | |||
import {type MatcherFunction, expect} from 'expect'; |
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.
What about this? If 'expect'
is extended later, perhaps importing from 'expect'
here makes sense? Or?
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.
agreed!
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.
at least, I agree if this example is "extend expect" and not "extend jest with extra matcher". In that case people should import from @jest/globals
(or use the global whenever we fix that)
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.
Hm.. Perhaps I will revert this. In my head this was "extend jest with extra matcher" example. I mean, there is an extra file where this new matcher is used in a test. If expect
was extended not for Jest, then expect(100).toBeWithinRange(90, 110);
line in this file would be enough without extra test file. It makes sense to import from '@jest/globals'
.
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.
👍
We should work on https://jestjs.io/docs/expect to give better examples there probably, but keep this example as is
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.
Agreed (;
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 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
Perhaps
jest-expect
should re-exportMatchers
interface as well?I was looking at the example again. Feels like Jest users should be recommended to extend interfaces from'@jest/expect'
instead of'expect'
. Right? In this caseMatchers
must be re-exported fromjest-expect
.Also
MatcherFunctionWithState
is also useful. It is just the same asMatcherFunction
, but takes two generic type arguments (state and matcher args) instead of one (only matcher args). I guess in most of the casesMatcherFunction
will do the job, but for more advance usageMatcherFunctionWithState
will be helpful too.Other problem. Because of augmentation the example was pulling types from test type files. Ups.. I added minimal
tsconfig.json
, which helps to isolate the example.Test plan
Green CI.