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

restrict-plus-operands

Is there a strong argument to have thisandno-base-to-string in recommended? Withno-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) withstrings. Which I sometimes do want to do in code for stringification.

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

declareconstnum:number;declareconststr:string;declareconstbool:boolean;declareconstobj:{};declareconstobjToStr:{toString():string};declareconstany:any;declareconstunk:unknown;num+num;// NO errornum+str;// RPO error// num + bool;          // TS error// num + obj;           // TS error// num + objToStr;      // TS errornum+any;// RPO error// num + unk;           // TS errorstr+str;// NO errorstr+bool;// RPO errorstr+obj;// NBTS + RPO error ////////// ONLY CASE NBTS ERRORS ONstr+objToStr;// RPO errorstr+any;// RPO error// str + unk;           // TS error// bool + bool;         // TS error// bool + obj;          // TS error// bool + objToStr;     // TS errorbool+any;// RPO error// bool + unk;          // TS error// obj + obj;           // TS error// obj + objToStr;      // TS errorobj+any;// RPO error// obj + unk;           // TS error// objToStr + objToStr; // TS errorobjToStr+any;// RPO error// objToStr + unk;      // TS errorany+any;// RPO errorany+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 enablesomething in the recommended ruleset that discourages type assertions - since they'realmost 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 intostrict-requiring-type-checking. Would love any ideas on other steps we could take!

Good question. We should document this somewhere! The description onhttps://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 practicesmost TypeScript developers should be comfortable with
• Rules in strict should apply >99% of the time to projects that follow best practicesvery 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 avery 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 fromstrict torecommended-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 asnpm 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 ittrue by default for the same reason asallowNumber - that it's a bittoo 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 totrue:

whileallowNullableEnum is unsafe:

The default for all other nullable primitives isfalse, as all of them are unsafe to set totrue:

Apologies if I missed it, but what makesallowNullableEnum a different case fromallowNullableString orallowNullableNumber?

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!