[New] no-duplicates: support inline type import with prefer-inline option

[snewcomer]

close #2470

ref typescript-eslint/typescript-eslint#5050

Typescript import { type A } from 'util/cool-linter' was introduced in 4.5 https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/#type-on-import-names

This PR seeks to add TypeScript support to the existing rule no-duplicates.

❌ Invalid `["error", { "prefer-inline": true }]`

import { AValue, type AType } from './mama-mia'
import type { BType } from './mama-mia'

✅ Valid with `["error", { "prefer-inline": true }]`

import { AValue, type AType, type BType } from './mama-mia'

[snewcomer]

consistent with this PR, we could use prefer-inline

[jasongerbes]

Would it be possible to extend this rule to also test exports?

[snewcomer]

@jasongerbes Great q! I'm not seeing inline export type throw any warnings so I'm guessing it is possible! I didn't see any mention in the release notes. Either it is an option or a different rule. After this PR is merged, I imagine we could consider it then. I don't have an answer right now.

export { type A };

[snewcomer]

cc @ljharb @bradzacher This is ready for your review.

[ljharb]

Looks good!

[codecov]

Codecov Report

Base: 95.30% // Head: 95.27% // Decreases project coverage by -0.02% ⚠️

Coverage data is based on head (24fd549) compared to base (de895ac).
Patch coverage: 87.50% of modified lines in pull request are covered.

❗ Current head 24fd549 differs from pull request most recent head 6304ddc. Consider uploading reports for the commit 6304ddc to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2475      +/-   ##
==========================================
- Coverage   95.30%   95.27%   -0.03%     
==========================================
  Files          68       68              
  Lines        2960     2966       +6     
  Branches     1004     1008       +4     
==========================================
+ Hits         2821     2826       +5     
- Misses        139      140       +1     

Impacted Files	Coverage Δ
src/rules/no-duplicates.js	99.24% <87.50%> (-0.76%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[snewcomer]

Hi @ljharb! Just seeing if I could get another friendly review when/if you have time!

[ljharb]

Looks good! I'm comfortable with this option name, but preferInline would work as well.

What about someone who supports inline type imports, but wants to force non-inline ones? Perhaps this should be an option with a value of "separate" versus "inline"?

[snewcomer]

@ljharb Thanks for the reviews and comments! So this PR is part of a larger effort.

1. fixes a Type import to Inline-Type via prefer-inline or prefer-top-level - [New] consistent-type-specifier-style: add rule #2473.
2. Fixes a Value import to Inline Type - feat(eslint-plugin): [consistent-type-imports] support fixing to inline types typescript-eslint/typescript-eslint#5050.
3. (this PR) adds support for resolving duplicate Type imports to Inline Types to a single import source.

I think 1) is what you are referencing, correct?

[snewcomer]

I updated to prefer-inline to be consistent with #2473. Does that seem ok?

[ljharb]

Yep, 1 is what I'm referencing

[ljharb]

Looks great!

[ljharb]

I'm not worried about the node 6 travis failure (it's due to npm 6 breaking it, and travis not yet updating nvm to work around it) nor about the uncovered line.

[snewcomer]

This seems to be the source of error for a few folks