-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
[no-base-to-string] doesn't catch String(…)
#4314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Personally I would just ban the usage of |
Bumping, because this rule has just become "error" in recommended set. |
@bradzacher I'm really curious: what do you recommend as an alternative? MDN (which is... written by me) recommends using |
@Josh-Cena it depends on the intent of the code as to exactly what you want to use. For stringification you can break it down into three usecases:
User visible strings shouldn't ever use System visible strings are less strict - but it's similarly doubtful you're going to be stringifying an unknown value for your system. If you are generally you want a comprehensive and consistent form like Dev visible strings are just logs and really "anything goes". It's not common to stringify an unknown value for this case. Again however With all that said - realistically the usecases for actually wanting |
As per our contributing guide please don't leave bump comments. They don't actually increase priority they just spam everyone subscribed to the thread. We are a community run project. The volunteer maintainers spend most of their time triaging issues and reviewing PRs. This means that most issues will not progress unless a member of the community steps up and champions it. If this issue is important to you — consider being that champion. |
Repro
Expected Result
2 warnings about
foo
being stringified to[object Object]
.Actual Result
Only the first statement triggers a warning, the second does not.
Additional Info
MDN documentation for
String(…)
: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/StringSimilar to #2440 and (to a lesser extent) #3388.
The text was updated successfully, but these errors were encountered: