prop-types not assigned via object literal do not work

[kesne]

The Airbnb styleguide recommends putting proptypes in a variable at the top of the file, and then assigning it into propTypes. This causes the linting of propTypes to fail.

The following does not cause any linting errors, despite not including the proptypes validation.

const propTypes = {};

class Test extends React.Component {
  render() {
    return (
      <div>{this.props.name}</div>
    );
  }
}

Test.propTypes = propTypes;

[ljharb]

Ideally either the rule should require inline propTypes, or should be able to determine what they are when assigned via a variable.

[yannickcr]

This pattern is difficult to handle, and currently if you're using it the rule will totally ignore props validation for this component.

[ljharb]

@yannickcr a silent failure is the worst possible way to handle it imo - if the rule can't handle it, then can it please raise an error, saying propTypes are unable to be validated?

If the rule can't handle this case, then it's useless, and I'd rather disable it completely than have it give false confidence :-/

(I recognize that if the object is imported or something it'd be difficult, but in this use case it's an object literal elsewhere in the file, so i'd think the info would be in the AST that esprima generates)

[yannickcr]

@ljharb since the patterns used in the React community are very diversified it is hard (impossible?) to cover everything. And I prefer to have certain errors silenced than having some false-positive cases that can break a build because the linter does not understand the used pattern (which does not indicate that the code is not correct). But maybe this can be a configurable setting?

Also about this current issue, after investigation it seems not so difficult to do after all (at least for simple cases like in @kesne example). So i'll try to submit a patch for this :)

[ljharb]

Awesome! Our use case at airbnb is just a straight object literal, that's referenced higher in the file, so hopefully that's achievable :-)

For me, a linter is a gate - i consider a pattern the linter doesn't understand to be forbidden, until the linter can be adapted to handle it (by allowing it or recognizing it). An option to enable this behavior would be great too!

[ljharb]

Thanks, this is excellent! Please let me know when it's released :-D

[ljharb]

Looks like this was out in 3.13.0 2 days ago. Thanks!

[yannickcr]

Right, it was released in v3.13.0, sorry for not having informed you earlier.