This is also similar to eslint's eslint.org/docs/latest/rules/no-extra-boolean-cast, which I'm actually not sure how they achieve without typescript, but that rule makes a lot of sense to me as well.

That rule exists just to do "if the Boolean() call is within a conditional test - error". It doesn't need types because it doesn't check the value passed at all.

A similar rule for String would be "if the String() call is within a sum with a string - error" (eg String(x) + '' would always error).

but it appears there're some issues with doing this with numbers that I don't think applies to strings

I'm not sure what "issues" you're referring to.
But IMO the same arguments apply here. EG similar to what is mentioned in #6385 (comment) -- step 1 of the string coercion algorithm is "if string return" - so there's near zero perf hit from an unnecessary String() call - it's just a stylistic thing.

Otherwise our big argument was that it's not super common to use String()/Number()/Boolean() in modern TS, let alone having provably useless calls - so a rule warning against unnecessary calls isn't super high-value. Just not sure if people would find value in such a rule.

Thank you for the clarification on the Boolean rule! I do think then that something like this could cover !!, Boolean(), and as boolean casts of booleans as well.

The issue I was referring to was that for numbers, Number() has problems if it takes things like strings of spaces, so parseInt() is a better idea, and since parseInt() does not accept a string the rule is unnecessary. On the other hand for strings, String() and .toString() both work with string | number and I don't think they have any weird issues for numbers, at least for integers. For booleans as well, the dynamic casts react to many types intuitively.

I don't have a sense for how common it is to do casts to strings or otherwise. I feel like the rule is nice for as string/as number/as boolean as well, and I feel like it must be quite common for at least one kind of cast, whether it's JS or TS, to happen at the interface with form elements. It seems like it's easy for this problem to happen when a type changes from string | number to string, or from any broad type to a specific type and you don't realize you were doing a cast somewhere, and it's unambiguous that it's wrong to cast a thing to its own type too I think. As a user I kind of expect a linter to lean towards detecting things that are very obviously wrong rather than things that are very common (though "very harmful" makes sense as a metric too, and I agree that these mistakes aren't particularly harmful). Makes sense that you'd want community support, but I'd be happy to try the implementation myself too if it's about managing what you spend time on.

Aside: this is a good example of why I'm real strict about separating "type assertion" and "cast" as terms. This issue is correct and talking about casting. But a lot of TS devs refer to type assertions as casting as well. They're not the same!

(ignore me, just ranting some contextual information)

In my head I kind of use "dynamic casting" for String() and "static casting" for as string, but yeah very important to distinguish them! I feel like this rule could work for both which furthers the confusion but yeah.

Another case occured to me that is in-line with my feelings on this, and apparently is already covered by another rule:
https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-unnecessary-condition.md

From my perspective, checking to see if something is already guaranteed to be a string when it is cast to or asserted to be a string is similar to checking if something is already guaranteed not to be undefined or null when used, for instance, with the optional chaining (?.) operator. I understand that branching conditionally on the type of a value is a thing that is yet again different from both casting a value and asserting a value's type, but in practice they are all ways for a user to get typescript to believe that a variable is a certain type, and I think linting rules are helpful which let a user know that typescript already believes them and they don't need the branch, cast, or type assertion.

Maybe neither here nor there, but just a thought.

I missed somehow that no-unnecessary-type-assertion is already a rule, so this would indeed apply only to actual runtime casting. I was able to set up a development environment and started trying to make an implementation, I know there's a good chance that this will be closed without community support but I'd like the rule anyway so I'm going to give it a shot.

I'm +1 on this. The typescript-eslint codebase itself has unnecessary !! that could be linted out, see

Duplicate of #3204

Closed the other one

For the record I'm strongly in favor of reporting all unnecessary type coercions. Not just String() but +, !!, BigInt etc. too

I implemented this, with tests, fix functions, and docs which pass yarn test, over at https://github.com/skondrashov/typescript-eslint

It gives autofixable errors for:

// setup
let str = "string";
const num = 1;
const bool = true;
const big = BigInt(1);

// begin invalid cases

String("hello");
"hello".toString();
"" + "hello";
"hello" + "";

String(1 + "");
(1 + "").toString();
"" + (1 + "");
1 + "" + "";

String(str);
str.toString();
"" + str;
str + "";
str += "";

Number(+"1");
+(+"1");
~~+"1";

Number(num);
+num;
~~num;

Boolean(bool);
!!bool;

BigInt(big);

and allows:

// setup
let str = Math.random() > 0.5 ? "string" : 1;
const num = Math.random() > 0.5 ? 1 : "1";
const bool = Math.random() > 0.5 ? true : 1;
const big = Math.random() > 0.5 ? BigInt(1) : 1;

// begin valid cases

String(str);
str.toString();
`${str}`;
"" + str;
str + "";
str += "";

new String("asdf");

Number(num);
+num;
~~num;
~1;

Boolean(bool);
!!bool;
!false;

BigInt(big);

It does not do anything with Symbol() because everything weird I tried to do with symbols was already a typescript error. Similarly, a sizable set of conversions to number via coercion are also forbidden by typescript ("The left-hand side of an arithmetic operation must be of type 'any', 'number', 'bigint' or an enum type."), including:

"123" * 1;
"123" / 1;
"123" - 0;
"123" | 0;

It also doesn't cover `${"123"}`, because that overlaps with the no-useless-template-literals rule and I don't know how to resolve that.

One thing is I don't think the word "coercion" is entirely accurate for this rule. I think "conversion" or even "type conversion idiom" might be the most precise, because .toString() for example doesn't rely on coercion, and while !!value and !value both coerce the type of value to a boolean, it's the property of the idiom !! that it can be used for type conversion that puts it under the umbrella of this rule. So I think no-unnecessary-type-conversion is a better name for this, given the things that I'm currently having it check for.

I haven't opened a PR since this isn't currently accepting PRs, but I'm close to being ready to.

Catches these errors within @typescript-eslint, which appear to be valid except for no-duplicate-enum-values where it's not clear to me what the author intended:

eslint-plugin\src\rules\adjacent-overload-signatures.ts
  79:21  error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
  97:21  error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
eslint-plugin\src\rules\explicit-function-return-type.ts
  170:27  error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
  177:9   error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
eslint-plugin\src\rules\member-ordering.ts
  486:14  error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
eslint-plugin\src\rules\no-duplicate-enum-values.ts
  50:21  error  Passing a string to String() does not change the type or value of the string  @typescript-eslint/no-unnecessary-coercion
  52:21  error  Passing a number to Number() does not change the type or value of the number  @typescript-eslint/no-unnecessary-coercion
eslint-plugin\src\rules\no-empty-interface.ts
  83:44  error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
eslint-plugin\src\rules\no-redundant-type-constituents.ts
  172:10  error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
eslint-plugin\src\rules\no-shadow.ts
  90:47  error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
eslint-plugin\src\rules\no-unsafe-assignment.ts
  202:17  error  Passing a string to String() does not change the type or value of the string  @typescript-eslint/no-unnecessary-coercion
eslint-plugin\src\rules\prefer-return-this-type.ts
  64:14  error  Using !! on a boolean does not change the type or value of the boolean  @typescript-eslint/no-unnecessary-coercion
website\src\components\ast\HiddenItem.tsx
  45:14  error  Passing a string to String() does not change the type or value of the string  @typescript-eslint/no-unnecessary-coercion
website\src\components\config\ConfigEditor.tsx
  39:9  error  Passing a string to String() does not change the type or value of the string  @typescript-eslint/no-unnecessary-coercion

@skondrashov Nice work btw 🙂. It's cool to see the number of spots within the typescript-eslint codebase that get fixed by your implementation (and IMO a good demo in favor of the rule).

Noting that I think replacing explicit conversion/coercion with a satisfies expression would be a helpful suggestion to add to this rule (in addition to simply removing the conversion).

Yeah I'm also in favor of this. Each individual case (Number(), !!, ...) doesn't bring much value, but I'm constantly running into them in assorted projects. The fact that we had violations is great evidence, +1!

This might be the first time in recent memory (or ever?) an evaluating community engagement issue ended up getting a lot of 👍s and accepted.

@skondrashov If you'd like, feel free to send a PR with your implementation 🙂

#10182

thanks for the warm feedback, appreciate it