[@types/jest] Use optional generic in expect methods

[G-Rath]

If you know how to fix the issue, make a pull request instead.

• I tried using the @types/jest package and had problems.
• I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• Mention the authors (see Definitions by: in index.d.ts) so they can respond.
  • Authors: @NoHomey @jwbay @asvetliakov @alexjoverm @epicallan @ikatyang @wsmd @JamieMason @douglasduteil @JoshuaKGoldberg @bradleyayers

This is somewhat related to #27840, and could be superseded by #33705, but I decided to make an issue for this for the sake of tracking:

I think it could be useful if some of the methods in Jest had optional generics, in particular the expect matchers.

That way, we could explicitly denote the expected type of things, as well as the their value:

expect(obj).toStrictEqual<APIResponse>({ ... });
expect(value).toStrictEqual<string>('hello world');
expect(mock.fn).toHaveReturnedWith<number>(5);

// etc

Implementation example:

// before
toStrictEqual(expected: {}): R;
// after
toStrictEqual<T extends {} = {}>(expected: T): R;

// before
toHaveReturnedWith(expected: any): R;
// after
toHaveReturnedWith<T = any>(expected: T): R;

// etc

I have tried this locally, and it didn't seem to cause any problems.

The matchers relating to arrays and objects might take a bit more work. I know that the library factory.ts successfully strongly types the pattern of DeepPartial, doing the same thing as expect.objectContaining does, so those types might be useful here.

You could also do toHaveBeenCalledWith (and other function related matchers) with:

toHaveBeenCalledWith<T extends (...args: any) => any>(...params: Parameters<T>): R;

Regardless, I think it could be of great benefit to have any many any types use a generic instead.

I personally don't imagine this breaking too much, but in saying that I don't know Typescript well enough to predict how this might affect how TypeScript "perceives" the types if parameters are suddenly having a value of T rather than whatever they had before (where T equals what they previously had).

---

While I'm happy to try making a PR for this, DefinitelyTyped does explode my computer/IDE a bit, so it might be slow going 😂