Yeah I've found it more and more confusing over the years when to use which rule. They're technically different rules but generally cover the same area of responsibility. I struggle to imagine a case where a project would strongly want one and not the other. 👍 from me with a request for more input from @typescript-eslint/triage-team.

no-base-to-string is a correctness rule. There's no reason you would disable it, as the reports indicate actual bugs in your code ("[object Object]" showing up). (There are unfixable bugs with this rule too, like certain types lacking toString() declaration, but you can configure them away.)

restrict-template-expression, and its sister restrict-plus-operands, are stylistic rules. While their union catches a subset of the mistakes caught by no-base-to-string, their main purpose is to allowlist displayable types, while no-base-to-string creates a blocklist of non-displayable types. By this nature, not everyone would be happy with these two rules (especially when we restrict common things like never and arrays by default, as well as many others that rely on implicit string coercion).

Yeah there's significant overlap but there's also distinction. Josh's description is apt.

I think a good summary - no-base-to-string is about code correctness, restrict-template-expressions is about presentational correctness.

It's often that I'd disable the latter but I'd rarely disable the former.

restrict-template-expression, and its sister restrict-plus-operands, are stylistic rules

Should we move them into the stylisticTypeChecked config then? (I'd think not, they catch actual bugs)

I think my root issue with the no-base-to-string rule is that both its name and functionality appear to be roughly the union of restrict-plus-operands & restrict-template-expressions.

While their union catches a subset of the mistakes caught by no-base-to-string

Just confirming: it looks to me like the only part of no-base-to-string not covered by the other two rules is explicit .toString() calls. Am I missing anything?

I'm wondering now, if we remove the plus operand and template expression checking from no-base-to-string, would the three rules no longer have any overlap? And if so, would that fix the common confusions around them?

Just confirming: it looks to me like the only part of no-base-to-string not covered by the other two rules is explicit .toString() calls. Am I missing anything?

It would, by principle, catch other things that do stringification, including #4314 and #3388.

I'm wondering now, if we remove the plus operand and template expression checking from no-base-to-string, would the three rules no longer have any overlap? And if so, would that fix the common confusions around them?

No, because then you would not have a rule that only enforces "no "[object Object]" in string values". Again: the two stylistic rules are too strict to be considered correctness only (they have correctness components, sure, but they check beyond that). If we add options like allowCustomStringifiers to these two rules, then it may work, though in general I don't find it appetizing.

Just confirming: it looks to me like the only part of no-base-to-string not covered by the other two rules is explicit .toString() calls. Am I missing anything?

It would, by principle, catch other things that do stringification, including #4314 and #3388.

Ah, gotcha, in that case we can consider my proposal to be explicit .toString() calls and similar, such as String(...).

they check beyond that

Just for clarity, what do you see as the stylistic points beyond the correctness checking?

I'm having a hard time conceptualizing why console.log("Value: " + []) is different from console.log(`Value: ${[]}`) (and equivalent array/etc. values).

The point is that console.log(`Value: ${{ toString: () => "Hi" }}`) should be allowed by default, which is the case with no-base-to-string. Banning it and requiring an explicit String() or toString() is a stylistic preference.

This proposal asks us to merge restrict-template-expression into this rule, which would be even more confusing, since no-base-to-string, according to its name, forbids one thing: the use of Object.prototype.toString. The only change I find sensible is to amalgamate all of them into a single rule, no-unexpected-stringification, which:

• Bans the use of Object.prototype.toString under any circumstance
• Bans implicit string coercion, behind an option

I agree with you that restrict-template-expression and restrict-plus-operands should probably be a single rule, though.

😅 I'm having a hard time keeping track of the different areas of concerns across:

• Logical vs. stylistic
• Object.prototype.toString vs implicit string coercion
• Numeric vs. stringification

...given that this impacts at least:

• no-base-to-string
• restrict-plus-operands
• restrict-template-expressions

I also personally am focusing on other work around project services and Promises over this issue area.

It'd be useful if someone could summarize all the things that we would want to lint for, along with whether they're logical or stylistic, and which rule(s) catch them now.

This is a stylistic case:

const obj = { toString: () => "foo" };
`${obj}`; // restrict-template-expressions
`${obj.toString()}`; // all happy
obj + ""; // restrict-plus-operands
obj.toString(); // all happy

This is a correctness case:

const obj = {};
`${obj}`; // restrict-template-expressions + no-base-to-string
`${obj.toString()}`; // no-base-to-string
obj + ""; // restrict-plus-operands + no-base-to-string
obj.toString(); // no-base-to-string

This is a stylistic (arguably) case:

const obj = 1;
`${obj}`; // restrict-template-expressions
`${obj.toString()}`; // all happy
obj + ""; // restrict-plus-operands
obj.toString(); // all happy

TLDR is that no-base-to-string catches a well-defined set of cases known to be wrong, while restrict-* allows a well-defined set of cases known to be right.

TLDR is that no-base-to-string catches a well-defined set of cases known to be wrong, while restrict-* allows a well-defined set of cases known to be right.

This delineation I like. I also like the delineation from #9644 (comment) as one area being logical, the other stylistic.

Proposal @typescript-eslint/triage-team: let's mark this as accepting PRs for our next breaking-changes-allowed major to:

• Solidify the general concatenation/stringification/template-strings rules into two rules
• Have one of those rules be logical, the other stylistic
• Write detailed docs and a blog post explaining the history of them

?

We chatted internally. There doesn't seem to be consensus on a best way to delineate these rules' areas of functionality. It's not really clearly split between "logical" and "stylistic". I'm out of ideas and pretty much fine having them remain as-is.

We're pretty certain that if something does happen, it won't be a rule deprecation. If anybody else has a clear proposal for how to do things, please do feel free to file a new issue. This one is getting long 😅.

Thanks all for the discussion!