Type duality: jest vs @types/jest

[anilanar]

Actually nevermind.

I'll be damned. Jest already declares its own types. Is it game over?

Edit: I just checked how that works out. When you import jest, it resolves to jest's own types. However, Typescript still brings in types from @types/jest and that only works because types are defined in the global namespace in @types/jest.

---

Now that (majority of) jest packages export their own typescript types, is it possible to expose types that @types/jest is exposing, but from jest without @types/jest and by reusing types from other jest modules in this repo?

Ideally, this should be done in a non-breaking/backward-compatible way for @types/jest users otherwise it's going to be a huge mess for TS users.

For example, jest.fn()'s generic arguments should default to any instead of unknown, at least until jest v27. There are many such small incompatibilities between jest's own types and @types/jest.

Some of such incompatibilities can potentially be fixed by jest package by re-exporting types from other packages by making minor modifications on types, where necessary.

Remember that once jest declares its own types, TS won't recognize @types/jest anymore! So it's a dangerous decision.

But this duality must be eventually abolished.

[SimenB]

The plan is for @types/jest to continue to exist, but only to add types to the global env. See DefinitelyTyped/DefinitelyTyped#44365

If you think Jest's own types can be improved, please send a PR 🙂

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.