feat(jest): use enhanced version of unbound-method
rule
#146
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I implemented this rule a while back, but wanted to wait before adding it here in case any bugs showed up.
The rule itself is a light wrapper around
@typescript-eslint/unbound-method
that only calls the underlying rule if the AST node being checked isn't a call to one of theexpect
matchers that takes a function, i.e.toHaveBeenCalled
& co, as those methods don't require the argument to be bound since they're not actually calling the function (they're checking properties on it).For example:
This rule lets us remove the
eslint-disable-next-line
, while still having all other test code checked for unbound methods 🎉In order to make it easier to include this rule in configs, it silently fails if the base rule cannot be imported for some reason, aka if you're on a Javascript project that uses
jest
but nottypescript
- this means we can safely include it here instead of having to maintain a separatejest-and-typescript
config just for this.I've also included specifyingI'm going to revert this for now because the docs generator currently assumes all peer dependencies are required.eslint-plugin-jest
as an optional peer dependency, which should be fine (and tbh we should be doing this for all our other plugin dependencies), but if it turns out to cause trouble (such as on older projects) then it can be reverted as it's a "technically more correct but not strictly required" sort of thing.