Skip to content
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 prefer-explicit-assert raising error on destructuring statement #43

Merged
merged 3 commits into from
Nov 6, 2019

Conversation

afontcu
Copy link
Member

@afontcu afontcu commented Nov 1, 2019

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!

(node.parent.type === 'Property' &&
node.parent.parent.type === 'ObjectPattern') ||
(node.parent.type === 'ArrayPattern' &&
node.parent.parent.type === 'VariableDeclarator');
Copy link
Collaborator

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?

Copy link
Member Author

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' ]

Copy link
Collaborator

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! 🙂

Copy link
Member Author

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! :)

Copy link
Collaborator

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 😄

Copy link
Member Author

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!

Copy link
Collaborator

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.

Copy link
Collaborator

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:

  1. Add a findParent function in the utils file:
const findParent = (node, cb) => {
  if (cb(node)) {
    return node;
  } else if (node.parent) {
    return findParent(node.parent, cb);
  } else {
    return null;
  }
};
  1. Modify both isDeclared and findCallExpressionParent:
const findCallExpressionParent = node =>
  findParent(node, node => node.type === 'CallExpression');

// ... 

const isDeclared = node => {
  return !!findParent(node, node => node.type === 'VariableDeclarator');
};
  1. I removed the isInArrayDeclaration function

  2. 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 🙂

Copy link
Member Author

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.

@Meemaw
Copy link

Meemaw commented Nov 5, 2019

Any estimates on when this will be merged? Great work regardless! 👍

@afontcu
Copy link
Member Author

afontcu commented Nov 5, 2019

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 :)

@thomaslombart
Copy link
Collaborator

Hey there! Sorry, I have less time to check the PRs. I think it should be fixed by tomorrow 🙂

Copy link
Collaborator

@thomaslombart thomaslombart left a 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 😄

@thomaslombart thomaslombart merged commit ac76e41 into testing-library:master Nov 6, 2019
@Belco90
Copy link
Member

Belco90 commented Nov 6, 2019

🎉 This PR is included in version 1.3.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

@afontcu
Copy link
Member Author

afontcu commented Nov 6, 2019

Thank you for guiding me through!

@thomaslombart
Copy link
Collaborator

@all-contributors please add @afontcu for code and test.

@allcontributors
Copy link
Contributor

@thomlom

I've put up a pull request to add @afontcu! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

prefer-explicit-assert does not work as expected
4 participants