Handle new JSX transform

[mrmckeb]

We've added support for the new JSX transform into Create React App (facebook/create-react-app#9645, facebook/create-react-app#9788), and we've been discussing how best to support this in our ESLint config.

I'm not sure if this is a good idea, and wanted some thoughts. I wondered if we should update jsx-uses-react to warn when using a React version that ships with the new transform, and do one of the following:

• Add an autofix (remove all React imports).
• Recommend running the codemod.

For now, we're:

• Auto-detecting support for the new transform (see base.js#L14-L21).
• Updating rules based on that detection, leaving jsx-uses-react on to avoid confusion (see base.js#L52-L58).

[ljharb]

If the jsx-uses-react rule is simply disabled, a “no unused imports” or “no unused variables” rule would already catch an unnecessary React import. When there’s a React version that doesn’t allow the current jsx transform, then the jsx-uses-react rule can be updated to throw an error, but otherwise I’m not sure any change is needed in this plugin.

[mrmckeb]

I was thinking more about explaining why React is no longer needed to be imported.

I agree 100% that you could just rely on a no-unused variable, and as I said I was just interested in thoughts. As the community transitions, some members will obviously be confused... but a change to this plugin may not help, you're right.

We can close this off for now, again I was just interested in thoughts at this stage - thanks for your time!

[cdoublev]

Hello,

It would be nice to detect "runtime": "automatic" for the babel/preset-react option and disable errors from react-in-jsx-scope when applicable, since this rule is recommended.

[ljharb]

I’d rather not couple this plugin to babel so tightly.

[cdoublev]

Obviously. Though I predict that after the release of Babel 8, many people will ask the same thing (or to remove it from recommended rules).

[mrmckeb]

Perhaps the React version detection in this plugin could alter behaviour of the related rule?

[ljharb]

Using React does not guarantee you're using JSX, or Babel, or transpiling at all, so I'm afraid not.

[cyrus-za]

I disagree that no-unused-vars would catch it.

If someone writes

import React from 'react'

export const Header: React.FC = () => { }

Then the rule will not warn against it and then when the new react version launches, someone will need to refactor the entire codebase to remove default imports that could have been prevented by a eslint rule.

I know there's a codemod but it does not catch all scenarios.

[ljharb]

@cyrus-za in that case, the React import is strictly necessary, for the type. There’s nothing wrong with having it there.