[Feature]: Replace `@types/jest`'s `expect` implementation with `@jest/expect`

🚀 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

[SimenB]

If this issue is resolved, yes 🙂 As of now @types/jest doesn’t get its matchers from expect

[SimenB]

For anyone following along, we’ve replace our own usage of @types/jest with the types exported from @jest/globals and an extra package sticking Jest’s globals into TS’s globals: #13344.

I’d still love for @types/jest to work with @jest/expect, but that might just be https://github.com/DefinitelyTyped/DefinitelyTyped/pull/62037 or something like it instead of having steps on the way