Changes to configurations for 8.0.0

[JoshuaKGoldberg]

Overview

We're working towards a new v8 major versions for typescript-eslint. Major versions are when we have an opportunity to adjust the shared configs. Exciting!

As with 6.0 (#6014), this is a proposal for the new shared configs. We're looking for feedback from the community before we go ahead and make the changes.

Please, let us know here or in the typescript-eslint Discord's #v8 channel: what feedback to you have? 💜

Table Key

Column	Description	Emojis
Status	Being added, deprecated, or removed	🆕 = newly added to typescript-eslint 🙅 = to be deprecated in the next major 💀 = currently deprecated; to be removed in the next version
TC	Requires type checking?	💭 = yes
Ext	Extension rule?	🧱 = yes
Rec'd	Recommended	➕ = add to recommended this version ➖️ = remove from recommended this version 🟩 = stays in recommended this version
Strict	Strict	➕ = add to strict this version ➖️ = remove from strict this version 🔵 = stays in strict this version
Style	Style	➕ = add to stylistic this version ➖️ = remove from stylistic this version 🔸 = stays in stylistic this version

Recommendations Table

Hint: search for 🆕 to find newly added rules, and ➕ or ➖ to see config changes.

Rule	Status	TC	Ext	Rec'd	Strict	Style	Comment
adjacent-overload-signatures						🔸
array-type						🔸
await-thenable		💭		🟩
ban-ts-comment				🟩
ban-tslint-comment						🔸
ban-types				🟩
class-literal-property-style						🔸
class-methods-use-this	🆕		🧱				too opinionated for stylistic
consistent-generic-constructors						🔸
consistent-indexed-object-style						🔸
consistent-return	🆕	💭	🧱				too opinionated for stylistic
consistent-type-assertions						🔸
consistent-type-definitions						🔸
consistent-type-exports		💭
consistent-type-imports
default-param-last			🧱
dot-notation		💭	🧱			🔸
explicit-function-return-type
explicit-member-accessibility
explicit-module-boundary-types
init-declarations			🧱
max-params	🆕		🧱				too opinionated for stylistic
member-ordering
method-signature-style
naming-convention		💭
no-array-constructor			🧱	🟩
no-array-delete	🆕	💭		➕	➖
no-base-to-string		💭		🟩
no-confusing-non-null-assertion						🔸
no-confusing-void-expression		💭
no-dupe-class-members			🧱
no-duplicate-enum-values				🟩
no-duplicate-type-constituents		💭		🟩
no-dynamic-delete					🔵
no-empty-function			🧱			🔸
no-empty-object-type	🆕			➕
no-empty-interface	🙅					➖
no-explicit-any				🟩
no-extra-non-null-assertion				🟩
no-extra-semi			🧱
no-extraneous-class					🔵
no-floating-promises		💭		🟩
no-for-in-array		💭		🟩
no-implied-eval		💭	🧱	🟩
no-import-type-side-effects
no-inferrable-types						🔸
no-invalid-this			🧱
no-invalid-void-type					🔵
no-loop-func			🧱
no-loss-of-precision			🧱	🟩
no-magic-numbers			🧱
no-meaningless-void-operator		💭			🔵
no-misused-new				🟩
no-misused-promises		💭		🟩
no-mixed-enums		💭			🔵
no-namespace				🟩
no-non-null-asserted-nullish-coalescing					🔵
no-non-null-asserted-optional-chain				🟩
no-non-null-assertion					🔵
no-redeclare			🧱
no-redundant-type-constituents		💭		🟩
no-require-imports
no-restricted-imports			🧱
no-shadow			🧱
no-this-alias				🟩
no-throw-literal		💭	🧱
no-type-alias
no-unnecessary-boolean-literal-compare		💭			🔵
no-unnecessary-condition		💭			🔵
no-unnecessary-qualifier		💭
no-unnecessary-type-arguments		💭			🔵
no-unnecessary-type-assertion		💭		🟩
no-unnecessary-type-constraint				🟩
no-unsafe-argument		💭		🟩
no-unsafe-assignment		💭		🟩
no-unsafe-call		💭		🟩
no-unsafe-declaration-merging				🟩
no-unsafe-enum-comparison		💭		🟩
no-unsafe-member-access		💭		🟩
no-unsafe-return		💭		🟩
no-unsafe-unary-minus	🆕	💭		➕
no-unused-expressions			🧱			➕
no-unused-vars			🧱	🟩
no-use-before-define			🧱
no-useless-constructor			🧱		🔵
no-useless-empty-export
no-useless-template-literals	🆕	💭		➕	➖		To be renamed in #8821
no-var-requires				🟩
non-nullable-type-assertion-style		💭				🔸
only-throw-error	🆕	💭	🧱	➕	➖
parameter-properties							too opinionated for stylistic
prefer-as-const				🟩
prefer-destructuring	🆕	💭	🧱				too opinionated for stylistic
prefer-enum-initializers
prefer-find	🆕	💭				➕
prefer-for-of						🔸
prefer-function-type						🔸
prefer-includes		💭			🔵	➕
prefer-literal-enum-member					🔵
prefer-namespace-keyword				➕		➖
prefer-nullish-coalescing		💭				🔸
prefer-optional-chain		💭				🔸
prefer-promise-reject-errors	🆕	💭	🧱	➕	➖
prefer-readonly		💭
prefer-readonly-parameter-types		💭
prefer-reduce-type-parameter		💭			🔵
prefer-regexp-exec		💭				➕
prefer-return-this-type		💭			🔵
prefer-string-starts-ends-with		💭				🔸
prefer-ts-expect-error					🔵
promise-function-async		💭
require-array-sort-compare		💭
require-await		💭	🧱	🟩
restrict-plus-operands		💭		🟩
restrict-template-expressions		💭		🟩
return-await		💭	🧱
sort-type-constituents
strict-boolean-expressions		💭
switch-exhaustiveness-check		💭
triple-slash-reference				🟩
typedef
unbound-method		💭		🟩
unified-signatures					🔵
use-unknown-in-catch-callback-variable	🆕	💭			🔵		too opinionated for recommended

[JoshuaKGoldberg]

Fun fact, I somewhat auto-generated this table. 😎 https://github.com/JoshuaKGoldberg/repros/tree/ts-eslint-v8-config-changes-generator

[kirkwaiblinger]

If no-useless-template-literal is destined to be renamed, should we sneak that in before it gets added to recommended to minimize impact of the renaming (on things like disable comments etc)?

#8821

[JoshuaKGoldberg]

Agreed, added to the v8 milestone. Good call!

[JoshuaKGoldberg]

Interesting note: prefer-find and prefer-includes at first seem like rules that would be in stylistic*. prefer-includes is currently in strict*. I don't mind keeping them in strict because they do help code be a little more performant... but I suspect the main benefits for users are stylistic. It'd be very rare for actual perf benefits to come out of them. So I'm leaning towards moving them to stylistic*. Does anybody have thoughts on this?

[kirkwaiblinger]

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.

[rubiesonthesky]

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 think prefer-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.

[JoshuaKGoldberg]

I'm leaning towards stylistic 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.

[hyoban]

Here are some rules I find handy

Add no-import-type-side-effects to the recommended config, and consistent-type-exports with consistent-type-imports to the stylistic config.

• https://typescript-eslint.io/blog/consistent-type-imports-and-exports-why-and-how
• https://youtu.be/5Uc6qDR10Vk?si=9RHfxoAVd2mxcmQv

method-signature-style

• https://www.totaltypescript.com/method-shorthand-syntax-considered-harmful

[bradzacher]

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 use import/consistent-type-specifier-style if they want to customise the style...

🤔

[bradzacher]

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

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

[rubiesonthesky]

Just heads up, ➕ and ➖ emojis are not visible on dark mode.

[JoshuaKGoldberg]

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

[rubiesonthesky]

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

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

[JoshuaKGoldberg]

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 🔼 / 🔽 .

[rubiesonthesky]

👍 / 👎 :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 easily https://github-emoji-picker.rickstaa.dev/ but emojis are pretty limited in this way)

[rubiesonthesky]

prefer-namespace-keyword

module will be probably marked as deprecated soon in typescript microsoft/TypeScript#57913

I wonder would it be helpful for ts-eslint users that this rule would be moved to recommended so they would get heads up beforehand? Of course, marking it as deprecated does not mean that it will stop working. :)

[JoshuaKGoldberg]

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.

[JoshuaKGoldberg]

Update (May 11th): with #8977's no-empty-object-type merged into v8, updating the table to include that being added to recommended.