crashes on stateless react class

[spudly]

I'm getting this error:

TypeError: Cannot read property 'type' of undefined
    at resolveSuperParameterPropsType (node_modules/eslint-plugin-react/lib/util/propTypes.js:615:20)
    at Object.ClassDeclaration (node_modules/eslint-plugin-react/lib/util/propTypes.js:651:39)
    at updatedRuleInstructions.(anonymous function) (node_modules/eslint-plugin-react/lib/util/Components.js:748:43)
    at listeners.(anonymous function).forEach.listener (node_modules/eslint/lib/util/safe-emitter.js:45:58)
    at Array.forEach (<anonymous>)
    at Object.emit (node_modules/eslint/lib/util/safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector (node_modules/eslint/lib/util/node-event-generator.js:251:26)
    at NodeEventGenerator.applySelectors (node_modules/eslint/lib/util/node-event-generator.js:280:22)
    at NodeEventGenerator.enterNode (node_modules/eslint/lib/util/node-event-generator.js:294:14)
    at CodePathAnalyzer.enterNode (node_modules/eslint/lib/code-path-analysis/code-path-analyzer.js:632:23)

It appears to be caused by a react class that has no state. It crashes for this code:

class MyClass extends React.Component<Props> {}

...but does not crash if you add a state annotation:

class MyClass extends React.Component<Props, State> {}

[ljharb]

Is this TS or Flow?

[spudly]

Flow

…

On Wed, Feb 27, 2019, 12:59 PM Jordan Harband ***@***.***> wrote: Is this TS or Flow? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2179 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdunBYZlJV1-7y4QoqZ_6_Rw0HTec5Kks5vRsdmgaJpZM4bVHVF> .

[ahutchings]

I'm seeing this issue with TypeScript as well. Adding an empty State interface works around the error.

[ljharb]

A PR to fix both would be great.

[jedwards1211]

The number of crashes fixed in the changelog recently really illustrates the pitfalls of managing a complex codebase like this without using TypeScript or Flow

[ljharb]

I don’t agree; it’s just the legacy of not being rigorous about defensive programming in this repo. That’s no longer the case.

[jedwards1211]

Defensive programming is of course always good, but what I'm saying is that Flow (and I assume TypeScript?) would have caught this potential NPE before it was ever published (and probably many other type errors in this codebase). I doubt there's any programmer who's as good at remembering to include null checks as Flow is at requiring them.

[ljharb]

Maybe so, but that relies on the parser types always being correct too. Either way, writing not-javascript in this repo isn’t on the horizon.