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.
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?
Yup, exactly!
I'd prefer to use only type checking here for obvious reasons, as it is more flexible and robust than just checking identifier names.
But this type checking-based approach works by checking whether a method is defined in the default library. This can be a problem for us, especially in the case of console
methods.
Imagine the following situation:
// tsconfig.json
{
"compilerOptions": {
"lib": ["ESNext"],
"types": ["node"]
}
}
// index.ts
const { log } = console
The log
method of the Console
interface is defined in the node_modules/@types/node/console.d.ts
, not in the default TypeScript library. Therefore, the rule will false-positively report on this destructuring because it knows that this method is defined outside the default lib.
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?
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.
Do we need both?
I really don't know 🙁
For more reasoning on this, see #8952 (comment)
Perhaps giving it a good name will make it clear?
+1 👍 Will rename it
} | ||
|
||
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.
Co-authored-by: Kirk Waiblinger <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8952 +/- ##
=======================================
Coverage 87.40% 87.41%
=======================================
Files 260 260
Lines 12608 12630 +22
Branches 3937 3946 +9
=======================================
+ Hits 11020 11040 +20
- Misses 1313 1315 +2
Partials 275 275
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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