Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://eslint.org/docs/latest/rules/no-restricted-syntax

Description

I've noticed folks getting around the no-base-to-string rule by using the String constructor.

Fail

// Passing an object or class instance to string concatenation:
'' + String({});

class MyClass {}
const value = new MyClass();
String(value) + '';

// Interpolation and manual .toString() calls too:
`Value: ${String(value)}`;
(String({}).toString());

Pass

// These types all have useful .toString()s
'Text' + true;
`Value: ${123}`;
`Arrays too: ${[1, 2, 3]}`;
(() => {}).toString();

// Defining a custom .toString class is considered acceptable
class CustomToString {
  toString() {
    return 'Hello, world!';
  }
}
`Value: ${new CustomToString()}`;

const literalWithToString = {
  toString: () => 'Hello, world!',
};

`Value: ${literalWithToString}`;

Additional Info

Banning the String constructor could probably be achieved through no-restricted-syntax, but I can't think of a reason anyone would use it in the first place except to get around this rule. And no-restricted-syntax doesn't mesh well with shared configs.

The built-in no-implicit-coercion rule actually encourages the use of String. It's a blunt instrument that makes sense in JavaScript, where static analysis in most cases can't guarantee that .toString() won't throw a runtime error.

The Number constructor is similarly (ab)used. I have an idea of what to do about that, but one thing at a time.