-
-
Notifications
You must be signed in to change notification settings - Fork 33
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: Detect sync functions from built in node modules #128
Conversation
6c5a128
to
b0b1469
Compare
b0b1469
to
9a39c84
Compare
|
||
/** @type {import('eslint').Rule.Node} */ | ||
const memberExpression = reference.identifier.parent | ||
if ( |
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.
nits: the name memberExpression
seems a little confusing to me - it's also likely to be a non-memberexpression node?
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.
Mm, I know what you mean.
I didn't really know what to call this, I called it memberExpression because I check to see if it's a memberExpression immediately after I create it 👀
Do you have any better name suggestions 😅
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.
something like parentNode
or identifierParentNode
?
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.
ok, given it's checked I think it's fine to be as-is. (naming is not an easy thing :). 😄
Mm, if #127 is merged shall I close this one? |
data: { | ||
importName: node.imported.name, | ||
aliasName: variables.at(0)?.name, | ||
}, |
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.
out of curiosity: is there a benefit to use .at()
over [0]
?
not sure .at()
was supported since node.js v16.
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.
This is just personal preference, I like the way .at behaves for negative numbers and for non numbers
I really didn't think about it that much, from a performance standpoint you probably want to use [0]. But I dont know 🤔
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.
Just checked, it was 16.6 - when I am at my pc I will change it to an array index
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.
seems its support was added in node.js v16.8.0, while the package requires node.js >=16.0.0
. let's just use [0]
? 😅
or you can fetch and rebase the main branch, and then do a force push:
|
👌 it's fine to close this one, thanks for doing this! ❤️ |
This is a different strategy to detect "Sync" functions by looking for the builtin node imports. Then we look for the usage of the function from there.
This means we can detect aliases like this too:
The tradeoff is that npm packages can now export Sync functions, eg:
This is the counterpoint to #127 and Option 2 for #102 (the complex option).