Truthy/Falsy checks don't actually understand JavaScript === false and === true leads to !isSomething

[kof]

Bug Report

When comparing values with if (isTrue === true) and if (isTrue) or if (isTrue=== false) and if (!isTrue), TS doesn't understand those are the same thing.

This is in particular a problem because a standard naming convention for booleans is isSomething and when used with negation you get !isSomething .... !i is terrible to read with most popular syntax highlighters and fonts and because of this bug, we can't actually NOT use !isSomething

🔎 Search Terms

truth, falsy

🕗 Version & Regression Information

4.9.5 and 5.1.0-dev.20230308

Please keep and fill in the line that best applies:

• This is a crash - no
• This changed between versions - no
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about - yes
• I was unable to test this on prior versions because - always been like this

⏯ Playground Link

Playground link with relevant code

💻 Code

declare function isTruthy(obj: unknown): obj is {}

declare const obj: { foo: string; } | null

if (isTruthy(obj)) {
  obj.foo
}

if (isTruthy(obj) === true) {
  obj.foo // is going to fail because TypeScript doesn't understand the truth check above
}

🙁 Actual behavior

It didn't see the === true or ===false check but works with !isSomething

🙂 Expected behavior

Supposed to work with === true or == true and same for false, because these are standard js expressions

[fatcerberus]

Duplicate of #31105/#9508 and more recently, #53093.

[kof]

wow exists since 2016 in #9508 and now open again I hope this issue explained why I am not using !isSomething since @RyanCavanaugh seem to be unaware that this is unreadable

[RyanCavanaugh]

Maybe try a different font? 😜

#31105 is open and approved, I don't know what more you want me to do. This isn't a higher-priority work item than other stuff the team is doing. Someone can send a PR when they'd like to.

[kof]

@RyanCavanaugh I wish I could, the problem is at scale, reading code on github, reading it in editors we don't control, font isn't even the main issue, syntax highlighters are, but yeah, its not something code authors can control.

@Andarist agreed to work on it if its approved by the team, so this is great news and all we needed to fix it

[fatcerberus]

I mean even if typescript supports x === false as a type guard tomorrow, that’s not going to stop people from writing !x in their own code if that’s their preference, so if your problem is other people’s code is unreadable I’m afraid you may be barking up the wrong tree.

[kof]

@fatcerberus sure, its for a codebase that wants to enforce a convention through linters on per org basis

[kof]

also @fatcerberus thanks for explaining to me what my problem is in such a nice tone

[fatcerberus]

thanks for explaining to me what my problem is in such a nice tone

Sorry, I didn’t mean that to come off as presumptuous/condescending—that’s why I specifically said “IF that’s your problem”