Thanks for the PR,@bradzacher!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently onhttps://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitorsper day.

Codecov Report

Merging#3256 (a086fa1) intomaster (62dfcc6) willdecrease coverage by0.07%.
The diff coverage is81.15%.

@@            Coverage Diff             @@##           master    #3256      +/-   ##==========================================- Coverage   92.91%   92.84%   -0.08%==========================================  Files         316      317       +1       Lines       10854    10923      +69       Branches     3069     3086      +17     ==========================================+ Hits        10085    10141      +56- Misses        342      348       +6- Partials      427      434       +7

Flags with carried forward coverage won't be shown.Click here to find out more.

@bradzacher do you think this could be another one worth extending ineslint-plugin-jest, to have it ignore theany ofexpect async matchers?

i.e

expect(mockMessageReactor.prototype.react).toHaveBeenCalledWith(  message,  expect.arrayContaining<ReactionAction>([    ['heavy_multiplication_x', true]  ]));

I know I can satisfy this by casting tounknown (or stronger), but in this context such a cast is typically very meaningless.

In saying that, I am casting for properties due tono-unsafe-assignment:

expect(mockSlackReactionsApi.remove).toHaveBeenCalledWith({  name: expect.any(String) as string,  timestamp: '1',  channel: '#my-channel'});

Curious on if you have any opinions on if this is something extending :)

this rule checks arguments using outisUnsafeAssignment function.

Which will allow assignments ofany to eitherany orunknown.
So as long as the jest expect functions are typed as receivingany orunknown, then it should just work.

But it looks like there is a bug in the rule.

The jest function is typed as:

declarefunctiontoHaveBeenCalledWith<Eextendsany[]>(...params:E):void;

So at typecheck type, when called withtoHaveBeenCalledWith(1 as any), the type ofparams isn'tany[], it's[any].. which isn't handled right now

So as long as the jest expect functions are typed as receiving any or unknown, then it should just work.

which (if I remember and understand everything correctly) they're not - they're typed to receiveany[] (where appropriate).

So:

expect(captureExceptionSpy).toHaveBeenCalledWith(expect.any(Error));

Gets

ESLint: Unsafe argument of typeany assigned to a parameter of type[any].(@typescript-eslint/no-unsafe-argument)

(that could be what you mean by[any] not being handled right now).

shouldn't the new rule be added to therecommended-requiring-type-checking preset?

It will, but changes to the recommended sets is a breaking change.