👍 from me on most of that! Just one thread:

restrict-plus-operands

Is there a strong argument to have this and no-base-to-string in recommended? With no-base-to-string, the recommended config already catches any unsafe concatenations. So what's left is concatenating non-string primitives (bigint, boolean, null, number, undefined) with strings. Which I sometimes do want to do in code for stringification.

no-base-to-string doesn't have handling for a lot of + cases that restrict-plus-operands does:

declare const num: number;
declare const str: string;
declare const bool: boolean;
declare const obj: {};
declare const objToStr: { toString(): string };
declare const any: any;
declare const unk: unknown;

num + num;              // NO error
num + str;              // RPO error
// num + bool;          // TS error
// num + obj;           // TS error
// num + objToStr;      // TS error
num + any;              // RPO error
// num + unk;           // TS error

str + str;              // NO error
str + bool;             // RPO error
str + obj;              // NBTS + RPO error ////////// ONLY CASE NBTS ERRORS ON
str + objToStr;         // RPO error
str + any;              // RPO error
// str + unk;           // TS error

// bool + bool;         // TS error
// bool + obj;          // TS error
// bool + objToStr;     // TS error
bool + any;             // RPO error
// bool + unk;          // TS error

// obj + obj;           // TS error
// obj + objToStr;      // TS error
obj + any;              // RPO error
// obj + unk;           // TS error

// objToStr + objToStr; // TS error
objToStr + any;         // RPO error
// objToStr + unk;      // TS error

any + any;              // RPO error
any + unk;              // RPO error

// unk + unk;           // TS error

payground

Got it, thanks - that makes a lot of sense to me. Keeping in 👍

Filed #6110 to add some friendly options to it. I'll propose we enable those options for both rules by default.

ban-ts-comment ... using a new browser API that is not yet available in TS types or just properties or quirks of APIs that are missing from TS types, and it would be too onerous on developers to create replacement types every time

🤔 do you have any examples of this? Out of those two cases:

• using a new browser API that is not yet available in TS types: the right solution would be to create "polyfill" types. How often does this happen?
• properties or quirks of APIs that are missing from TS types: IME this is pretty rare, so I'd love to see examples of this happening in real world code.

no-non-null-assertion

Yeah this is unfortunate. I would really love to be able to enable something in the recommended ruleset that discourages type assertions - since they're almost always indicative of a flaw in the type system. But sometimes that flaw is in TypeScript itself, and/or something not really able to be overcome. Hence lumping it into strict-requiring-type-checking. Would love any ideas on other steps we could take!

Good question. We should document this somewhere! The description on https://typescript-eslint.io/linting/configs#recommended-configurations is a little vague:

Additional strict rules that can also catch bugs but are more opinionated than recommended rules.

The heuristics I've been using have been roughly:

• Rules in recommended, strict, and stylistic should apply >99% of the time to >99% of projects that follow reasonable configurations (i.e. don't do anything ridiculously spooky, such as non-standard modifications to global APIs)
• Rules in recommended should apply >99% of the time to projects that follow best practices most TypeScript developers should be comfortable with
• Rules in strict should apply >99% of the time to projects that follow best practices very experienced TypeScript developers should be comfortable with

How does that feel?

I am not an expert, but I think it is generally good.
I would have thought we could set a clear baseline, but it's hard to think about.

I've been thinking about the indicators of a very experienced TypeScript developer.

• Familiar with coding in Typescript
• Has a good understanding of the Typescript type system
• Can afford to rewrite old code
• Can afford to make an effort to typing as accurately as possible

@bradzacher sorry, i mean this to be a reply to your comment above but did it through my phone and realized just now it went as a new comment (thus creating even more noise). Feel free to mark this one off topic as well (or just completely delete it).

Ah good callout, thank you! It was merged after the last time I went over this list. Just updated now to indicate it's meant to move from strict to recommended-type-checked.

Is it possible that the other plugins are forcing it back to v5 because they need it as a dependency?

That is a possibility, yes. You can try debugging techniques such as npm ls or manually looking through your lockfile (package-lock.json/yarn.lock/pnpm-lock.yaml). If you want help, our Discord would be the right place to ask. Good question!

Oof, sorry for the delay @tylerlaprade - I'd missed this comment. I believe we're keeping it true by default for the same reason as allowNumber - that it's a bit too opinionated for folks. If you're interested in having this as a config change I'd suggest filing a new issue for it. We'd probably want to tackle it for v7.

Thanks for the reply, @JoshuaKGoldberg! I don't see those two options as equivalent nor as opinionated, though. As per the current documentation, allowNumber is safe to set to true:

while allowNullableEnum is unsafe:

The default for all other nullable primitives is false, as all of them are unsafe to set to true:

Apologies if I missed it, but what makes allowNullableEnum a different case from allowNullableString or allowNullableNumber?

D'oh! You're right, I mistook the two. Per #6760 we're going to want to make a few changes (or at least: I'll propose them). Linking here so it's not missed. Thanks!