Repository navigation
.toBeCallableWith() does not work with generic functions or overloads #50
Description
If a generic function is declared like this:
export declare function foo <T>(x: T, y: T): T;The .toBeCallableWith() matcher fails:
expectTypeOf(foo).toBeCallableWith(123, "123"); // no error reported
foo(123, "123");
~~~~~ Argument of type '"123"' is not assignable to parameter of type '123'.Testing an overloaded function:
export declare const foo: {
(x: string, y: string): string;
(x: number, y: number): number;
};Does not work either:
expectTypeOf(foo).toBeCallableWith("abc", "efg");
~~~~~ Argument of type 'string' is not assignable to parameter of type 'number'.
expectTypeOf(foo).toBeCallableWith(123, 456);
foo("abc", "efg"); // but all is good here
foo(123, 456);Hm.. If a simple foo() does the job (and does it better!), what is the purpose of .toBeCallableWith()? I mean, .toEqualTypeOf() works perfectly in both of the cases I mentioned above:
expectTypeOf(foo("abc", "efg")).toEqualTypeOf<string>();
expectTypeOf(foo(123, 456)).toEqualTypeOf<number>();.not.toBeCallableWith() could handle a check which .toEqualTypeOf() cannot and would be more useful than // @ts-expect-error. Unfortunately it is not implemented at the moment.
Activity
mmkal commentedon Jan 17, 2024
Yeah, I sometimes regret adding
toBeCallableWithfor this reason. The advantages of it:expectTypeOf(foo(...)).toEqualTypeOf<...>()which looks more like "I am testing that this function has this return type".But outside of those, you're probably better off with
foo(...)in this case.mrazauskas commentedon Jan 17, 2024
Thanks for explanation.
I’m leaving the issue open in case you would like to document the limitation with overloaded and generic functions. Feel free to close, if that does not look significant.
Add limitations section