-
Notifications
You must be signed in to change notification settings - Fork 149
Fix prefer-explicit-assert raising error on destructuring statement #43
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
Conversation
lib/rules/prefer-explicit-assert.js
Outdated
(node.parent.type === 'Property' && | ||
node.parent.parent.type === 'ObjectPattern') || | ||
(node.parent.type === 'ArrayPattern' && | ||
node.parent.parent.type === 'VariableDeclarator'); |
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 don't think checking for VariableDeclarator
is necessary, is it?
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.
oh, I see, it's not. Fixed!
This made me think of something else, though. Should the following line be considered as a valid one? Right now it is consideren invalid:
const a = [ getByText('foo'), 'bar' ]
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.
That's interesting... I guess it should be considered as valid since we don't use it as an assertion here. We need to fix that as well.
Thanks for spotting the issue! 🙂
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.
okay, I'll work on that and update the PR accordingly! :)
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.
All right! Thanks for working on that 😄
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.
Okay, just updated the PR. I think checking if grandparent is an ArrayExpression
will suffice, but please do doublecheck it as I'm relying on tests I wrote and the AST explorer which is just learned about when you shared the screenshots 😇
thanks for helping me out!
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 sufficient for array declarations but I spotted the same issue if you declare an object, for example:
const hello = { foo: getByText("bar") }
In the end, I'm not sure if checking for array or object declaration is the right approach. I think we should just check if getByText
is both being called and assigned to a variable. Thus, we would need to do some modifications to isDeclared
.
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 got it working by doing this:
- Add a
findParent
function in theutils
file:
const findParent = (node, cb) => {
if (cb(node)) {
return node;
} else if (node.parent) {
return findParent(node.parent, cb);
} else {
return null;
}
};
- Modify both
isDeclared
andfindCallExpressionParent
:
const findCallExpressionParent = node =>
findParent(node, node => node.type === 'CallExpression');
// ...
const isDeclared = node => {
return !!findParent(node, node => node.type === 'VariableDeclarator');
};
-
I removed the
isInArrayDeclaration
function -
I added a last test:
{
code: `const a = { foo: getByText('bar') }`,
},
That way, we don't dive into specific details of how getBy queries have been declared, we just check if one parent (no matter where in the tree) has a type of VariableDeclarator
. I think it should be good by doing so 🙂
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 looks way smarter to check for positive cases rather than trying to take into account every posssible wrong edge case. Updating the PR.
Any estimates on when this will be merged? Great work regardless! 👍 |
AFAICT it's ok from my side, let's see if Thomas can take a look :) |
Hey there! Sorry, I have less time to check the PRs. I think it should be fixed by tomorrow 🙂 |
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.
All LGTM now! 🎉
Thanks a lot for your contribution @afontcu, I really appreciate it 😄
🎉 This PR is included in version 1.3.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Thank you for guiding me through! |
@all-contributors please add @afontcu for code and test. |
@thomlom I've put up a pull request to add @afontcu! 🎉 |
Closes #40.
I've added a check for Array destructuring. I've never seen it before, but I thought it wouldn't hurt.
Thanks for your help!