[expect-type] Implement not.toBeCallableWith

[LorenzHenk]

At the moment, not.toBeCallableWith is not implemented (the function type is never).

I read the source code and understand why you implemented the typing of toBeCallableWith in the way you did.

I tried to implement it in several ways:

Type checking only the first argument

As typescript does not allow multiple spreads in 1 function parameter list, this approach allows you to check only the first argument.

  toBeCallableWith: <Expected>(
    expected?: Expected,
    ...MISMATCH: MismatchArgs<Extends<[Expected], Params<Actual>>, B>
  ) => true;

Passing arguments as array

Did not work well. You have to use as const for your array. This makes the array readonly though, so you have to use a custom type to remove readonly

type NotReadonly<T> = {
  -readonly [P in keyof T]: T[P];
};

// ...
  toBeCallableWith: <Expected extends any[]>(
    expected?: Expected,
    ...MISMATCH: MismatchArgs<Extends<NotReadonly<Expected>, Params<Actual>>, B>
  ) => true;

Using it

expectTypeOf((a:number) => a).toBeCallableWith([1] as const);

Most feature complete, but breaking change

  toBeCallableWith: <Expected extends any[]>(
    ...expected: Expected
  ) => (
    ...MISMATCH: MismatchArgs<Extends<Expected, Params<Actual>>, B>
  ) => true;

You need to change the obj: FunctionsDict to not get a runtime error:

//...
    toBeCallableWith: () => fn,
//...

Using it

The breaking change here is the additional need for () at the end. Sadly this can often be overlooked by the end user.

expectTypeOf((a: number, b:number) => a + b).toBeCallableWith(1,2)();

[mmkal]

I went down a similar path a couple of times, it's a tricky one. Responding to your proposals in reverse order:

I think requiring the () at the end is a non-starter, it's just too easy to forget and for everything to look ok.

The as const approach isn't quite as problematic, I had run into the readonly problem too, but hadn't thought of using a type mapping to work around it. Still, it's not very intuitive to put the arguments in an array, since that isn't how you'd call the original function. Even less intuitive to see mysterious errors unless as const is added.

Regarding the method that only works with one argument - something like that might actually be workable. Maybe a similar approach could be used for 2-, 3-, 4- and 5-arg functions, with any more than that not supported until someone requests them. I'd potentially be open to a PR along those lines, depending on how it looked in practice.

In the meantime, since typescript 3.9 there is a decent way to ensure a function isn't callable with certain args:

const f = (a: number) => a

// @ts-expect-error
expectTypeOf(f).toBeCallableWith('not a number')

I will add an example along these lines to call this out explicitly in the docs.

[mmkal]

@LorenzHenk see #152 - there might be something clever that can be done with "throw" types, assuming they land sometime soon (see microsoft/TypeScript#40468) - the use of the ...MISMATCH: MismatchArgs<...> pattern is no longer needed. I'd be open to a PR if you can find a clean way to do handle .not.toBeCallableWith.