[Feature]: Replace `@types/jest`'s `expect` implementation with `@jest/expect`
#12.424 aperta il 18 feb 2022
Metriche repository
- Star
- (45.361 star)
- Metriche merge PR
- (Merge medio 11g 22h) (11 PR mergiate in 30 g)
Descrizione
🚀 Feature Proposal
People might not want to use the globals (expect, test etc.) Jest provides (either because of ESM or just a preference). And because Jest is written in TypeScript, when doing e.g. import {expect} from '@jest/globals' all built in matchers are typed. However, if you use some matchers from the community (such as jest-extended), they augment the matchers from @types/jest instead of expect (or @jest/expect). If instead all libraries augmented the actual expect types, the imported matcher would be typed correctly.
However, this flips the problem - now people using the globals no longer get custom matchers typed! The solution to this problem is to make @jest/types use @jest/expect instead of shipping its own types for this.
This issue is for tracking the work that needs to be done before releasing Jest 28 stable so there's a single source of truth - the source code.
I have started: https://github.com/SimenB/DefinitelyTyped/tree/jest-expect
We need to make sure the tests pass. Most breakage is due to the tests using e.g. jest.InverseMatchers etc - I don't think that's super useful? I might be wrong though, in which case we should expose more of those types from expect and/or @jest/expect.
(note that running tests is "impossible" until https://github.com/microsoft/DefinitelyTyped-tools/pull/411 is merged. I ran npm install manually inside types/jest to see errors in the tests in my IDE)
/cc @mrazauskas