[New] Create a named-import rule for React

[el-angel]

[alexzherdev]

Note that this can be achieved with the core no-restricted-syntax rule by using the following selector: "ImportDeclaration[source.value=\"react\"] :matches(ImportSpecifier, ImportNamespaceSpecifier)"

[ljharb]

(disregard my previous review; i was looking at the "view changes" diff and not the entire diff)

[el-angel]

@ljharb absolutely! I'll work on it

[stefcameron]

This looks like exactly the rule I'm looking for! React 16.14.0 was just announced, and along with it, a new codemod to remove unused react imports -- if you move to the new JSX Transform available in 16.14.0.

But the codemod also has the option of moving all statements like React.useState() to useState() with an import { useState } from 'react', and I've run the codemod to move to these destructured imports.

Now I'd like to enforce that in the code base, because, as the article says at the very bottom,

In addition to cleaning up unused imports, this will also help you prepare for a future major version of React (not React 17) which will support ES Modules and not have a default export.

Note, "not have a default export".

Based on the examples in the README for this new rule, I think it would be perfect to make sure we keep consistently using destructured imports in our codebase with the import mode.

[el-angel]

@ljharb is there anything regarding this PR that needs improvement? It would be great if this rule could make a next (major) release

[ljharb]

Sorry for the delay, I'll take a look. New rules are semver-minor.

[ljharb]

Perhaps we should rename this rule to "named-import"?

[el-angel]

Perhaps we should rename this rule to "named-import"?

@ljharb I agree, changed it :-)

[ljharb]

@el-angel this is almost ready to land if we can resolve the tsc error.

[el-angel]

@ljharb pipeline fail s because it says rebase fails, but I don't see any merge conflicts? Can you help me out?

[ljharb]

@el-angel looks like you didn’t pull my latest changes when updating - could you reset your local branch to https://github.com/yannickcr/eslint-plugin-react/commit/a156b282586a093c134a0dc3994d24afaddf5725, add your fix on top, and force push that up?

[codecov-commenter]

Codecov Report

Merging #2585 (bdc9f09) into master (c66c073) will increase coverage by 0.00%. The diff coverage is 98.01%.

@@           Coverage Diff            @@
##           master    #2585    +/-   ##
========================================
  Coverage   97.40%   97.41%            
========================================
  Files         111      112     +1     
  Lines        7445     7546   +101     
  Branches     2723     2751    +28     
========================================
+ Hits         7252     7351    +99     
- Misses        193      195     +2     

Impacted Files	Coverage Δ
index.js	100.00% <ø> (ø)
lib/rules/named-import.js	98.01% <98.01%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update c66c073...bdc9f09. Read the comment docs.

[ljharb]

nvm, i'll take care of it :-)

[ljharb]

the only thing I'm still thinking about is https://github.com/yannickcr/eslint-plugin-react/pull/2585#discussion_r608809722.

In other words, there seems to be a few choices here:

1. assume that anyone using the jsx runtime will extend react/jsx-runtime, and in that config, set the rule to "named only".
2. do not assume this, and find a way to detect use of the jsx runtime, and either allow the rule to be configured to "auto" or error when the setting conflicts with the usage of the runtime (when the jsx runtime is enabled, "named only" must be selected).
3. do neither, and just force people to "know" they need to set this rule to "named only" when using the jsx runtime.