Add missing `toString` declarations for base types that have them

Search Terms

toString, RegExp, Regular Expression, Boolean, Error

Suggestion

In @typescript-eslint, we have a rule no-base-to-string. This rule ensures that any value that’s being coerced to a string has a toString method defined on it. This is to help catch cases where you accidentally coerce something to a string, and end up with an [object Object] in your strings.

This rule has a pretty simple implementation - it just gets the declarations of the toString method on the type, and ensures that none of the declarations belong to the Object type. The logic relies upon the fact that every type that actually has a toString method explicitly declares a toString method.

A few of our users ran into cases that were reporting errors for them, even though they shouldn’t (https://github.com/typescript-eslint/typescript-eslint/issues/1655). There’s one that specifically has caused people some issues: Boolean/boolean.

I eyeballed the docs and the types, and I am pretty certain there are only 3 types that are missing a toString declaration:

• RegExp: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/toString
• Boolean: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean/toString
• Error: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/toString

Related

PR: #37839

Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript/JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

[cnshenj]

In this case, the built-in declaration is wrong, why it shouldn’t be fixed? Boolean type has a toString method: Boolean.prototype.toString(). Even without considering linting, I can’t write true.toString(), which is perfectly valid JavaScript and (should be) TypeScript code.

[Oaphi]

Regarding the missing definition for the Boolean interface, it would also be nice if the return type of the method was defined as a string literal union "true" | "false" and not just string (as in the PR) since even the spec considers “true” and “false” to be the only possible outcomes of step 2 of the method algorithm.

This would allow patterns like this (valid in JS) without having to resort to declaration merging in user code:

type SorterMap<T> = Record<"true" | "false", (a: T, b: T) => number>;

const makeTdStrSorter = ({ up = true }) => <
  T extends string
>(
  a: T,
  b: T
) => {
  const dirMap: SorterMap<T> = {
    true: (a, b) => (a < b ? -1 : a > b ? 1 : 0),
    false: (a, b) => (a > b ? -1 : a < b ? 1 : 0),
  };

  return dirMap[up.toString()](a, b); //expression of type 'string' can't be used to index type 'SorterMap<T>'
};

I do understand and appreciate the concern that changes to the standard library may cause things to break, but this is about adding something that should’ve probably been there from the get-go, so if it does break something, it is better to know it now than further down the road.