🚀 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 microsoft/DefinitelyTyped-tools#411 is merged. I ran npm install manually inside types/jest to see errors in the tests in my IDE)

/cc @mrazauskas