You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Constrain the signature of isMockFunction<T> to accept only functions returning T, removing the need to explicitly specify the type.
Motivation
The ts-jest package offers a mocked helper to type safely set mock implementations. However, that relies on the @types/jest package, which offers types defined but not exposed by Jest. (For example, at the time of writing @types/jest is still for Jest 25, so migration to Jest 26 is not possible for any TypeScript tests which mock modules)
At the moment, code like JestMock.isMockFunction<number>(sum) && sum.mockReturnValueOnce(5) is possible. However, that does not ensure that the type of the function matches the explictly specified one – so isMockFunction<string>(sum) && sum.mockReturnValueOnce("k") also transpiles. If the signature of isMockFunction was tightened to isMockFunction<T>(fn: (args: any) => T): fn is Mock<T>;, the combination of the signature and the type predicate would provide nice safety.
Example
With the aforementioned signature:
import { sum } from "arithmetic-utils";
import * as JestMock from "jest-mock";
jest.mock("arithmetic-utils");
// this is OK
JestMock.isMockFunction(sum) && sum.mockReturnValueOnce(5);
// this would be caught by transpiler
JestMock.isMockFunction(sum) && sum.mockReturnValueOnce("k");
Pitch
The MockInstance and Mock types are not exposed by jest-mock, apart from being referenced in function signatures. Therefore the same type safety can not be achieved by third-party libraries unless they duplicate those types, which is obviously fragile. Alternatives to the proposed solution would be to export MockInstance from jest-mock (making it easier to maintain compatibility of ts-jest with future Jest versions), or to provide an equivalent of mocked in Jest core (which would make things easy for app developers, but perhaps it would be considered out-of-scope for core).
The text was updated successfully, but these errors were encountered:
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.
🚀 Feature Proposal
Constrain the signature of
isMockFunction<T>
to accept only functions returningT
, removing the need to explicitly specify the type.Motivation
The
ts-jest
package offers amocked
helper to type safely set mock implementations. However, that relies on the@types/jest
package, which offers types defined but not exposed by Jest. (For example, at the time of writing@types/jest
is still for Jest 25, so migration to Jest 26 is not possible for any TypeScript tests which mock modules)At the moment, code like
JestMock.isMockFunction<number>(sum) && sum.mockReturnValueOnce(5)
is possible. However, that does not ensure that the type of the function matches the explictly specified one – soisMockFunction<string>(sum) && sum.mockReturnValueOnce("k")
also transpiles. If the signature ofisMockFunction
was tightened toisMockFunction<T>(fn: (args: any) => T): fn is Mock<T>;
, the combination of the signature and the type predicate would provide nice safety.Example
With the aforementioned signature:
Pitch
The
MockInstance
andMock
types are not exposed by jest-mock, apart from being referenced in function signatures. Therefore the same type safety can not be achieved by third-party libraries unless they duplicate those types, which is obviously fragile. Alternatives to the proposed solution would be to exportMockInstance
from jest-mock (making it easier to maintain compatibility of ts-jest with future Jest versions), or to provide an equivalent ofmocked
in Jest core (which would make things easy for app developers, but perhaps it would be considered out-of-scope for core).The text was updated successfully, but these errors were encountered: