Agreed, added to the v8 milestone. Good call!

The way I see it, both those rules satisfy the conditions when flagging that "there is a unique and uncontroversially better way to write this, though there is not a significant correctness concern with the existing code". So there's no reason ever to not want them, but they're not terribly important to use either. As a user my intuition would that that should be part of strict, whereas stylistic would have to do more with opinionated things that don't have a uniquely better way to write them; one is just picked largely for the sake of consistency (consistent-type-assertions springs to mind as a good example of this). Idk if that's really the intention of those configs or not, though.

I think it would be good to also consider that strict is recommended only for proficient typescript developers. And I think these rules are easy to use and easy to adopt. So they could go for stylistics in that sense.

I thinkprefer-find could go to even recommended. I don't see it being really opinionated. Instead it will catch old code that could be updated. There is probably only handful of cases where you would not want to use that rule.

We recommend a TypeScript project extend from plugin:@typescript-eslint/strict only if a nontrivial percentage of its developers are highly proficient in TypeScript.

I'm leaning towardsstylistic for now, as (a) they really do mostly give objectively better stylistic benefits and (b) per@rubiesonthesky's note,strict locks them behind"you should be proficient" notes.

consistent-type-imports might too opinionated for us to turn on, I think.
Mainly because it has a fixer and it fixes to an opinionated default.

stylistic is our opinionated default but I am weary of complaints.
We could document that people should useimport/consistent-type-specifier-style if they want to customise the style...

🤔

no-import-type-side-effects isn't really useful for people unless they are usingverbatimModuleSyntax as well. With that turned off the "empty imports" are all properly elided by everything.

It's a useful rule if you have to useverbatimModuleSyntax - otherwise it's just noise and not necessary.

Oh, blurgh. Good callout. Now we have to figure out - what's a good replacement pair of emojis... 🤔

remove: 🗑️ (or ❌ but that is too red IMO.)
add: 🎉 / ✨

(I honestly do not know, I think it could be just+ and- :)

Mmhh it'd be nice to have two emojis with meanings related to each other... surprisingly hard to find. I'm surprised there aren't + and - versions in squares the way there are 🔼 / 🔽 .

👍 / 👎 :D There is ✅ and ❎ but I think those are hard for some people as they use same color and the different symbol is just so small.

I think the table could use ✨ for meaning "new". Both meaning as a new rule and as a new item in shared config. Because I had difficulties remembering what every emoji means :D But I'll leave this to you (or others) to find best option.

(Found this kind of tool where you could check in both modes easilyhttps://github-emoji-picker.rickstaa.dev/ but emojis are pretty limited in this way)

I like it! It straddles the line between "recommended" and "stylistic"... but given the strong TypeScript push, that's enough for me to be happy switching it over.

Note that once#9102 is merged, we'll have some more changes to the table.

No strict timeline. When we get to things, really.
You can use the canary releases if you need v9 support now.

As volunteer maintainers we work on things when we have the bandwidth -- and unfortunately we haven't had the bandwidth. ESLint sadly did not coordinate with us and released before we were ready and at a time where we have been time poor.

Aha thank you, great callout! Updating now.