[New] consistent-type-specifier-style: add rule

[bradzacher]

Fixes #2469

Adds a new rule as specced in #2469
To test this I had to bump the TS version to 4.5, as that was the first version that supported inline type specifiers.

[bradzacher]

big oof - testing against all of these old versions of things is really tough to get right

[snewcomer]

Lovely 👍

[codecov]

Codecov Report

Base: 95.15% // Head: 95.14% // Decreases project coverage by -0.00% ⚠️

Coverage data is based on head (ac4960c) compared to base (7f251b2).
Patch coverage: 97.46% of modified lines in pull request are covered.

❗ Current head ac4960c differs from pull request most recent head 2df9be6. Consider uploading reports for the commit 2df9be6 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2473      +/-   ##
==========================================
- Coverage   95.15%   95.14%   -0.01%     
==========================================
  Files          66       67       +1     
  Lines        2828     2907      +79     
  Branches      949      979      +30     
==========================================
+ Hits         2691     2766      +75     
- Misses        137      141       +4     

Impacted Files	Coverage Δ
src/rules/consistent-type-specifier-style.js	97.46% <97.46%> (ø)
utils/module-require.js	85.71% <0.00%> (-14.29%)	⬇️

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.

[ljharb]

I'd prefer to avoid use of generators and loops, but that's also something I can clean up once the tests are passing.

How does a Flow user who isn't using the inline typeof syntax already, autofix to import typeof?

I think that if we can get this to leave behind the empty braces, we'll be OK pending the other comments. I'd love to land this soon.

[bradzacher]

Now that the TS 4.8 release is done, I should be able to get back to this this week (hopefully).

[ljharb]

I'm holding off on the next release for this :-) looking forward to you getting back to it.

[bradzacher]

assuming test pass - this should be good to go now.
I updated the fixer to (a) cleanup unnecessary commas and (b) cleanup empty named blocks

[ljharb]

Looks great - have these items been addressed?

How does a Flow user who isn't using the inline typeof syntax already, autofix to import typeof?

leave behind the empty braces

[bradzacher]

leave behind the empty braces

The fixer should no longer leave behind empty braces.

How does a Flow user who isn't using the inline typeof syntax already, autofix to import typeof?

If I'm understanding your question correctly:

• If they don't want to use the inline specifiers at all, then they can use the prefer-top-level setting.
• If they want to use inline type with top-level typeof, the rule does not currently have handling for this (could be a future enhancement if people want it!).

[ljharb]

Rebased; looks like this is good to go, pending any "uncovered line" annotations (#2473 (comment) and #2473 (comment))

[latin-1]

microsoft/TypeScript#47118

import type { X } from "...";
import { type X } from "...";

These two lines of code behave differently. Perhaps we should add a special treatment for this.

[ljharb]

It's not clear what the difference is from that issue. Can you elaborate?

[latin-1]

typescript-eslint/typescript-eslint#6338
I posted more details at the link above. I'm not sure which plugin this should be handled in.
It's a mess. We may need two or more passes of code fixes to make it work.

[ljharb]

eslint on the CLI runs multiple passes, so it's only in an editor that you're likely to run into this problem.