prop-types improved handling for destructuring and member expressions

[cbranch101]

This adds handling for multiple previously unhandled situations related to destructuring and member expressions. It required that I pretty heavily rework the existing code related to marking prop types usages, but I think it actually simplifies it a bit from what was there before.

Multi-staged destructuring

        const Foo = ({ a: { b } }) => {
          const { c } = b
          return <div>{c}</div>
        }
// reports `'a.b.c' is missing in props validation`

Destructuring off of member expressions

        const Foo = props => {
          const { b } = props.a
          return <div>{b}</div>
        }
// reports `'a.b' is missing in props validation`

Renamed destructuring

        const Foo = ({ a: aRenamed }) => {
          const { b } = aRenamed
          return <div>{b}</div>
        }
// reports `'a.b' is missing in props validation`

Member expressions of off destructured variables

        const Foo = ({ a: { b } }) => {
          return <div>{c.d}</div>
        }
// reports `'a.b.c.d' is missing in props validation`

Everything should be working as it was before with one exception.

This test used to be reporting an error on names.map not being defined in prop type, but I'm now ignoring all array methods when checking prop types off a member expression.

{
      code: [
        'const Hello = (props) => {',
        '  let team = props.names.map((name) => {',
        '      return <li>{name}, {props.company}</li>;',
        '    });',
        '  return <ul>{team}</ul>;',
        '};'
      ].join('\n'),
      parser: 'babel-eslint',
      errors: [
        {message: '\'names\' is missing in props validation'},
        {message: '\'company\' is missing in props validation'}
      ]
    }

Fixes #1422 Fixes #1447

[MatthewHerbst]

but I'm now ignoring all array methods when checking prop types off a member expression

@cbranch101 out of curiosity, why?

[ljharb]

@MatthewHerbst you can't know statically if .map is on an array or not.

[brokentone]

This rule would really help me out! Looks like the outstanding question is to @ljharb, and a conflict to be resolved.

[ljharb]

@cbranch101 this needs a rebase; I tried doing it but it wasn't a clean one.

[davidlewallen]

Any progress with this issue? Is there anything that I can do to further this along?

[ljharb]

@davidlewallen if you could make a branch that has these commits, rebased and passing tests, and you post a link to it here (without creating a duplicate PR) then I'd be happy to update this PR with your rebase/additions :-)

[alexzherdev]

I have a PR upcoming that deduplicates propType usage detection from prop-types and no-unused-prop-types https://github.com/alexzherdev/eslint-plugin-react/commit/348021f4fbfae9c39de6ed7f77ef6395d7916e6f (bringing them both down to < 200 lines compared to 1100+ lines originally 🤗). If that were landed first, then both rules would benefit from this improvement.

[cbranch101]

Hey guys, sorry for the delay, got pulled off into some other things, I'll take a look at the rebase this week

[ljharb]

ping @cbranch101, are you still interested in completing this PR?

[ljharb]

@cbranch101 unfortunately it seems like @alexzherdev's propType detection refactors makes this PR not trivially rebaseable. I was able to manually preserve the test cases, but I think you'll need to be the one to look at how to rebase the implementation changes.

I'll mark this as a draft in the meantime; please unmark it when it's rebased and ready to go.