TypeScript: "This condition will always return 'false'" but returns true at runtime
TypeScript Version: 3.1.0-dev.20180818
Code
function sanityCheck(s: string): string {
return s == 0 ? "I must be going insane" : "I'm fine";
}
console.log(sanityCheck(""));
Expected behavior:
Error message is 100% accurate.
Actual behavior:
src/a.ts:2:9 - error TS2367: This condition will always return 'false' since the types 'string' and 'number' have no overlap.
The == operator in JavaScript converts its arguments – some developers apparently rely on this behavior (not naming names but I noticed this in real JavaScript code that I pasted into a TypeScript file).
The error message might recommend using an explicit conversion such as Number(s) to get this to compile in TypeScript.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 21
- Comments: 24 (5 by maintainers)
Is this not getting fixed?
It has never been the case that no JS you could possibly write would issue zero errors in TypeScript, nor would this make any sense. See https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean
It really annoys me that this has been a bug for years and looks like the devs here have no interest in resolving it. Not only is the error message misleading and wrong, TypeScript is failing to be a superset of JavaScript as it’s not allowing me to do perfectly valid JavaScript.
Frankly whether anyone considers it to be bad practice to allow an implicit conversion or not is irrelevant. We who are developing our own code should be allowed to make that choice for ourselves. I as the developer should be able to choose what parts of the language I use to the fullest.
Can someone point more specifically to where this error-check happens, to facilitate a PR that disables the check for == and != cases? I’m not able to find it, even in code search. To see that this bug has been known for years with an intentional decision to just not fix it until there were a sufficiently large number of errors - and then it not being fixed after that threshold was exceeded - really communicates that TypeScript isn’t ready for prime-time use or production code yet.
I started to use @typescript-eslint/strict-boolean-expressions after I found a silly mistake in my code that could have costed me a lot of money, as I did a
numberOrUndefinedVar ? X : Y, and 0 was not intentionally falling into Y, and it was making hundreds of DB calls.This rule is very good, but, doesn’t work very good with TS due to a current fact: If you want to check a falsy value (e.g. empty string and undefined), with
== false, TS will throwThis condition will always return 'false' since the types 'string | undefined' and 'boolean' have no overlap.ts(2367).I have made, before this
== falseidea, a question in Stackoverflow about it, how to check for falsy value using this rule. While the two current answers are valid, they really aren’t good to use outside your own code, where you know why you are using it and won’t need to comment why you did those strange workarounds.So,
== falseshould be TS friendly, as it works as expected in JS.Current TS version: 4.1.2
May be better to write
MyEnum.Value1 as MyEnumbecause that at least specifies it asMyEnumrather thannumber.I get the same error message for the following code:
Yeah, we discussed
==and!=making the statement technically incorrect and decided to wait for the first bug report before addressing it.