Handle nodes without init

[pfhayes]

Avoids this error which appears in master in the no-access-state-in-setstate rule

TypeError: Cannot read property 'type' of undefined
    at ObjectPattern (/Users/patrick/dev/sigopt-api/node_modules/eslint-plugin-react/lib/rules/no-access-state-in-setstate.js:158:52)
    at listeners.(anonymous function).forEach.listener (/Users/patrick/dev/sigopt-api/node_modules/eslint/lib/util/safe-emitter.js:47:58)
    at Array.forEach (<anonymous>)
    at Object.emit (/Users/patrick/dev/sigopt-api/node_modules/eslint/lib/util/safe-emitter.js:47:38)
    at NodeEventGenerator.applySelector (/Users/patrick/dev/sigopt-api/node_modules/eslint/lib/util/node-event-generator.js:251:26)
    at NodeEventGenerator.applySelectors (/Users/patrick/dev/sigopt-api/node_modules/eslint/lib/util/node-event-generator.js:280:22)
    at NodeEventGenerator.enterNode (/Users/patrick/dev/sigopt-api/node_modules/eslint/lib/util/node-event-generator.js:294:14)
    at CodePathAnalyzer.enterNode (/Users/patrick/dev/sigopt-api/node_modules/eslint/lib/code-path-analysis/code-path-analyzer.js:608:23)
    at Traverser.enter (/Users/patrick/dev/sigopt-api/node_modules/eslint/lib/linter.js:956:32)
    at Traverser.__execute (/Users/patrick/dev/sigopt-api/node_modules/estraverse/estraverse.js:397:31)

[ljharb]

Thanks; this is great - could you also include a regression test, so it doesn't happen again?

[pfhayes]

While I would love to, to be clear this was the state of the codebase when I checked it out. I don't really know what caused the error or how to reproduce, but this did fix the issue and seems worth checking in to resolve the issue for future developers

[ljharb]

@pfhayes i'm confused; you're saying that npm test failed with this error? O.o

[pfhayes]

I observed this when running eslint-plugin-react master on our company's codebase, and the actual case that causes this was hard to track down

[jomasti]

A test that would crash before this change is an SFC using destructuring in the parameters.

[ljharb]

@pfhayes generally it helps to temporarily add console.log(context.getFilename()) right before the line that throws in the plugin; that way you can find the code triggering it. @jomasti's example is great too, but it'd be helpful to confirm that that's what caused your issue too.

[grajagandev]

Would you be interested in software that automatically finds TypeErrors like this? I am building Fuzz Stati0n to do that (free for OSS) - please take a look and consider signing up for our newsletter to keep in touch.

[ljharb]

@grajagandev do you mean any unchecked property accesses? Generally in eslint plugins, eslint is supposed to provide some guarantees in the node structures returned, so there'll be tons of them in this repo that aren't a problem. What would be most useful is something that knows about eslint/babel-eslint node types, and warns when those accesses are incorrect.

[grajagandev]

Thank you - great feedback. We instrument the code and run npm test and we record functions called including arguments. Then we mutate those args (including objects) and re-run the tests many times in an attempt to force uncaught exceptions or other critical conditions. But it probably wouldn't have full knowledge of eslint/babel-eslint node types.

Your suggestion makes me think that it could be smarter - we are very early stage so your input means a lot.

[pfhayes]

Thanks, I confirmed the trigger on my end was object destructuring in function params and added a test

[ljharb]

Assuming the test fails without the fix, LGTM!