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
fix(eslint-plugin): [unbound-method] report on destructuring in function parameters #8952
base: main
Are you sure you want to change the base?
Conversation
Thanks for the PR, @auvred! 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 on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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 really like these changes! The algorithm change makes sense to me, the code is easy to follow, and the new code for type inspection is very thorough.
Added a few questions and some test cases to flesh out edge cases.
node.parent.type === AST_NODE_TYPES.AssignmentExpression | ||
) { | ||
initNode = node.parent.right; | ||
} |
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.
should there be some kind of assertion here to ensure that every way that ObjectPattern could occur is handled (especially in light of the bug that this PR fixes)? Relates to #6225
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.
Interestingly, the introduction of the type checking actually supports unaccounted-for parents pretty well.
Check this out 😆
// should be invalid, passes (didn't in previous implementation)
function f({ evil: { nesting } } = { evil: { nesting: function () { } } }) {
}
// should also be invalid, fails (since it's _only_ looking at the type)
function g({ evil: { nesting } }: any = { evil: { nesting: function () { } } }) {
}
To be clear, I don't think you need to account for these crazy scenarios (or, even more heinous things like const [{ a }, { b }] = [{ a() {} }, { b: 'b' }];
in this PR. I am just pointing out that it's cool that you've incidentally added partial support for them!
There is one false positive regression introduced that I can think of, though....
// the possible assignments _are_ provably bound.
// but the presence of the annotation causes `b` to flag as possibly unbound.
const { a: { b } = { b: () => { } } }: { a: { b(): void } } = { a: undefined }
but I really don't think it's a blocker granted how absurd it is.
nativelyBoundMembers.has(getMemberFullName(node)) && | ||
isNotImported(objectSymbol, currentSourceFile) | ||
notImported && | ||
nativelyBoundMembers.has(`${object.name}.${property.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.
const { log } = console;
In our current configuration, the console.log
declarations are under @types/node
. So if we remove this check, the rule will report on this case. Not sure what's the best solution there..
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.
Are you saying, you'd like to get rid of the first half of this function and only have the part after the return
statement, but that that would cause bugs to do so? I'm not 100% following.
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.
A couple questions/commenting requests, but no significant concrete changes being requested at this time.
isBuiltinSymbolLike( | ||
services.program, | ||
services.getTypeAtLocation(object), | ||
[ |
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.
What's the difference between this array literal and the SUPPORTED_GLOBALS
array? Do we need both? Perhaps giving it a good name will make it clear?
Thoughts?
} | ||
|
||
const objectSymbol = services.getSymbolAtLocation(node.object); | ||
function isNativelyBound( |
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.
It's not super obvious how this function works. I cloned it down to play around with the tests, and I'm still not 100% sure, but my rough understanding is that the first part checks by identity whether something is a natively bound member, and the second part checks via the type system, in order to catch a more general set of cases where the builtin namespace objects are potentially renamed.
Could you add some comments to help the reader 🙏 ?
node.parent.type === AST_NODE_TYPES.AssignmentExpression | ||
) { | ||
initNode = node.parent.right; | ||
} |
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.
Interestingly, the introduction of the type checking actually supports unaccounted-for parents pretty well.
Check this out 😆
// should be invalid, passes (didn't in previous implementation)
function f({ evil: { nesting } } = { evil: { nesting: function () { } } }) {
}
// should also be invalid, fails (since it's _only_ looking at the type)
function g({ evil: { nesting } }: any = { evil: { nesting: function () { } } }) {
}
To be clear, I don't think you need to account for these crazy scenarios (or, even more heinous things like const [{ a }, { b }] = [{ a() {} }, { b: 'b' }];
in this PR. I am just pointing out that it's cool that you've incidentally added partial support for them!
There is one false positive regression introduced that I can think of, though....
// the possible assignments _are_ provably bound.
// but the presence of the annotation causes `b` to flag as possibly unbound.
const { a: { b } = { b: () => { } } }: { a: { b(): void } } = { a: undefined }
but I really don't think it's a blocker granted how absurd it is.
nativelyBoundMembers.has(getMemberFullName(node)) && | ||
isNotImported(objectSymbol, currentSourceFile) | ||
notImported && | ||
nativelyBoundMembers.has(`${object.name}.${property.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.
Are you saying, you'd like to get rid of the first half of this function and only have the part after the return
statement, but that that would cause bugs to do so? I'm not 100% following.
) { | ||
const objectSymbol = services.getSymbolAtLocation(object); | ||
const notImported = | ||
objectSymbol && isNotImported(objectSymbol, currentSourceFile); |
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.
(nit, optional) feels like this should be an actual boolean
objectSymbol && isNotImported(objectSymbol, currentSourceFile); | |
objectSymbol != null && isNotImported(objectSymbol, currentSourceFile); |
PR Checklist
Overview
Old approach: query for
VariableDeclarator, AssignmentExpression
and check if they haveObjectPattern
New approach: query for
ObjectPattern
, check ifVariableDeclarator, AssignmentExpression, AssignmentPattern
its parentWe're iterating over
ObjectPattern
's properties:ObjectPatterns
's parent has init node, check if it's safe to destructure this init node:ObjectPatterns
's parent isAssignmentPattern
:ObjectPattern
has a type annotation, then check if it's safe to destructure this type