eslint-plugin-react: jsx-uses-react rule does not detect jsxFrag rule

If this is still causing anyone pain (especially https://github.com/emotion-js/emotion/issues/1549 folks, since #2158 appears to be stalled), I threw together a plugin that re-implements jsx-uses-react and react-in-jsx-scope for Fragments specifically. This could be useful as a reference implementation for this issue, but I didn’t feel like I understood the other ecosystem implications of how jsxFrag is used. @justingrant

It could be possible to implement something more general for jsxFrag support in jsx-uses-react and react-in-jsx-scope, but I’m not sure how this fits into everything else.

@Ailrun @ljharb - I ended up here after running into https://github.com/emotion-js/emotion/issues/1549. If I’m understanding that issue, the <> shorthand for Fragment is broken with the current versions of emotion and eslint-plugin-react, because:

1. if you import React from 'react' and don’t otherwise use React, then eslint will complain that 'React' is defined but never used. (no-unused-vars) (example: https://codesandbox.io/s/pensive-edison-bdkpp)
2. But if you don’t import React from 'react', then you’ll get a runtime error React is not defined because React.Fragment is emitted into the final transpiled code without React being imported.

In this comment, @Andarist says that emotion can’t solve (2), and recommends that eslint-plugin-react could help . Is there already an eslint-plugin-react rule that can solve (2) instead, presumably by not triggering the no-unused-vars if the unused var is React and the file contains <>? Or is that solution what #2158 is trying to address? If the latter, then what’s needed to get #2158 over the finish line?

I suppose that makes sense, but it’s a bunch of extra complexity.