fix no-unused-prop-types + async class properties and methods

[benstepp]

There was an incosistency with access and storage of the usedPropTypes
of a component that would cause proptypes to not be correctly marked as
used if more than one prop was used in the body of an async function
class property or async class method.

Fixes #1053

---

bug source:

First time around

• get the parentComponent using utils.getParentComponent() https://github.com/yannickcr/eslint-plugin-react/blob/master/lib/rules/no-unused-prop-types.js#L594
• save off the usedPropTypes array from what component was found.
• modify the array with my new used props.
• set the new array on the node https://github.com/yannickcr/eslint-plugin-react/blob/master/lib/rules/no-unused-prop-types.js#L638
  Note that in this case the node is a MemberExpression
• Components#set will then just crawl the parents of the current node
  (the MemberExpresion) until one was found in the internal this._list.
• Because all async FunctionExpressions, ArrowFunctionExpressions, and
  FunctionDeclaration are treated as components of confidence 0 (not a
  component). The unusedPropTypes would be attached
  to this. (Which is usually fine).

However, if the component tries to mark a prop as used again, it will
read from the parentComponent using utils.getParentComponent() (which in
this case will return the class) which does not have the previously used
methods. The array would then be modified (created because it doesnt
exist), and then set them onto the async arrow function overwriting
anything that was previously there.

This change just attaches used props to the found component (where the
previous usedPropTypes are pulled from) if it exists, otherwise to the
current node.

[ljharb]

LGTM.

Does this only happen with the combo of class properties and async functions, or are there test cases with async functions but not class properties we could add?

[benstepp]

It only happens whenever an async function was defined and used props without destructuring inside of a class.

I do have a few async methods for the non class property variety. And I just added four more test cases to hit a questionable factory method that returns an async function case. Although I don't see why you'd want to do that, but it's possible.

[ljharb]

does this also happen if propTypes are assigned outside the class body (ie, using only stage 4 features)? if so, could we add a test case that uses the default parser instead of babel-eslint?

[benstepp]

I added a few more cases with async functions defined in the render method rather than returned from a separate method, and used the default eslint parser.

The issue was with marking the props as used, not with how the propTypes were defined, so using OG syntax works just fine.

[ljharb]

Thanks!

[vkbansal]

When will this be merged? facing the same issue.

[EvHaus]

LGTM. Thanks for that fix and the detailed tests.

[TrevorSayre]

@benstepp It appears the merge conflicts still need to be handled before this can be merged

[jonandrewdavis]

Would leaving a comment here help this get merged? Having this issue and found that it's alllmost there. Keep up the good work here!

👍

[lencioni]

Looks like this needs a rebase

[ljharb]

I took the liberty of rebasing this - it was pretty tricky. I'll merge once tests pass.

[rkkautsar]

Having this issue and seeing the fix is already in the master but not released yet...
When is the next release scheduled?