-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: improve how jest function calls are resolved to account for import aliases #1122
Conversation
ba4b8df
to
e6c3360
Compare
a2fd28e
to
92ef9e3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woah, amazing!
@@ -6,6 +6,7 @@ import { | |||
TSESTree, | |||
} from '@typescript-eslint/utils'; | |||
import { version } from '../../package.json'; | |||
import { isTypeOfJestFnCall } from './utils/parseJestFnCall'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename this file to utils/index.ts
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was planning on moving everything else in a follow-up PR, as I'll split things across a few more files but wanted to wait until I'd refactored expect
parsing since that represents about 1/3rd of the file.
# [26.4.0](v26.3.0...v26.4.0) (2022-05-28) ### Features * improve how jest function calls are resolved to account for import aliases ([#1122](#1122)) ([781f00e](781f00e))
🎉 This PR is included in version 26.4.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Resolves #1106 and #1119, and has highlighted a few other improvements (like that
prefer-todo
ignoresx
prefixed methods even though it applies to.skip
'd methods, and the ability to supportcontext
as an alias ofdescribe
).This overhauls how we parse jest methods to leverage the redesign of how to check if something is a jest method that was landed via #1094 so that rules can handle aliased functions.
Because of how this turned out I've ended up doing away with most of the
utils
tests as they're now covered by tests in rules - I have only brought them back to cover cases that are not specific to one particular rule.I've kept this to being just focused on implementing #1106 even though I could also do a few more things like add support for
failing
(#1118), support parsingexpect
, remove support for invalidconcurrent
call chains, etc. I'll be doing follow up PRs straight away for these so that they have their own changelog.Support for parsing
expect
calls in particular will be my next focus as I've got that mostly done already but realised a little bit of extra thinking needs to be done becauseexpect
usage is generally inverse to other methods since it goesexpect(..).property.call(...)
- I would like to merge the existing parser/api into this new one, but need to decide on a pattern to represent the difference betweenexpect
calls whereexpect
itself is called (which is what the current parser handles) andexpect
calls where it's not (which is what the new parser is really looking for, in all cases except forexpect
).I also realised while doing this that
spyOn
and co are still accessed viajest
even when using@jest/globals
- you just importjest
(e.g. it'simport { jest } from '@jest/globals';
, notimport { spyOn } from '@jest/globals';
)Also also while not super important, this makes
lib
~4kb smaller which I think is a good sign that it's on the right track :D