Skip to content

Avoid raising preferExplicitAssert warning on destructuring #42

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

Closed
wants to merge 2 commits into from
Closed

Conversation

afontcu
Copy link
Member

@afontcu afontcu commented Nov 1, 2019

Closes #40.

I was trying to get my head around the issue linked above, but I can't seem to be able to write a test case that reproduces the behavior we are getting in the wild.

Right now, tests pass/fail as the library should behave: valid test is passing, while invalid tests are failing (meaning, AFAIK, that given that piece of code no warning was raised).
However, in the real world™, const { getByText } = render(Comp) is raising an error.

I opened up a draft PR in order to get this sorted out, so any help would be appreciated :)

@afontcu
Copy link
Member Author

afontcu commented Nov 1, 2019

(Build obviously fails as I had to add --no-verify flag when commiting)

@thomaslombart
Copy link
Collaborator

thomaslombart commented Nov 1, 2019

Thanks for opening the PR @afontcu. I'm investigating it at the moment. So far, it seems that the test fails when the destructuring statement is wrapped in a callback function. If you add the test below in the valid tests, you'll get two errors:

    {
      code: `
      describe("App", () => {
        it("test", () => {
          const { getByText } = render(<Preview/>)
        })
      })
      `,
    },

I don't know why at the moment but I'm taking a look at it 😉

Update: the test fails when a destructuring assignement happens in a CallExpression such as describe or it. See why below.

@thomaslombart
Copy link
Collaborator

thomaslombart commented Nov 1, 2019

Ok, I found where the bug comes from. The selector used by the visited function 'CallExpression Identifier'(node) is incorrect since it triggers the function for all descendants of a CallExpression.

As getByText is an identifier inside an it call, it will be considered and will trigger the rule (twice because it is a destructuring statement, so getByText will be visited for the key and the value). Here is two screenshots to better understand what's going on:

Descendants selector:

Screenshot 2019-11-01 at 15 09 00

Children selector:

Screenshot 2019-11-01 at 15 08 48

Doing it this way seems a good solution at first sight but it makes other tests fail, particularly this one:

    ...ALL_QUERIES_METHODS.map(queryMethod => ({
      code: `const utils = render()

      utils.get${queryMethod}('foo')`,
      errors: [
        {
          messageId: 'preferExplicitAssert',
          line: 3,
          column: 13,
        },
      ],
    })),

@thomaslombart
Copy link
Collaborator

I found a fix to the bug, I'm doing a check on if the visited node is in a destructuring statement or not:

const isInDestructuringStatement = node =>
  node.parent.type === 'Property' &&
  node.parent.parent.type === 'ObjectPattern';

And in the big if statement:

        if (
          isValidQuery(node, customQueryNames) &&
          !isInDestructuringStatement(node) &&
          ...

Do you want to take it from here and add the corresponding tests @afontcu ?

@afontcu
Copy link
Member Author

afontcu commented Nov 1, 2019

sure, I take a look! It's my first time toying around with eslint rules 🙌

I'll ping you as soon as I get it ready to review :)
thanks!

@afontcu
Copy link
Member Author

afontcu commented Nov 1, 2019

Closing in favor of #43 (something got messed up with git history, and didn't want to spend much time on it).

@afontcu afontcu closed this Nov 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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