Add missing `toString` declarations for base types that have them
See original GitHub issueSearch 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.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:12
- Comments:6 (3 by maintainers)
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 writetrue.toString()
, which is perfectly valid JavaScript and (should be) TypeScript code.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 juststring
(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:
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.