Inverted `Promise` should warn like it does without inverting

Suggestion

🔍 Search Terms

This condition will always return true since this ‘Promise<string | undefined>’ is always defined.(2801) Did you forget to use ‘await’?

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

⭐ Suggestion

When checking the inverted truthyness if something returned from an async function without calling await, it should warn you you forgot await. This works without inverting.

📃 Motivating Example

async function foo(): Promise<string | undefined> {
    return
}

const value = foo()
if (!value) { // <-- fails silently
    // ...
}

const awaitedValue = await foo()
if (awaitedValue) { // <-- Emits ts2801
    // ...
}

Playground

💻 Use Cases

In my use, I had a function that returned a User | undefined and I was doing something if there wasn’t a user returned. Later, I made the function async and forgot to update this since it was failing silently.

[Miodec]

Any update? Just ran into this issue. Tried 4.6.4 and its still a problem.

The bug I found today:

...
  if (!isNameAvailable(name)) {
    throw new MonkeyError(409, "Username already taken", name);
  }
...

isNameAvailable returns a promise, and so the throw line will never execute.

Removing the inversion highlights this error correctly:

if (isNameAvailable(name)) {

This condition will always return true since this 'Promise<boolean>' is always defined.ts(2801)
user.ts(54, 7): Did you forget to use 'await'?

Another interesting fact is that using === also highlights this error correctly:

if (!isNameAvailable(name) === true) {

This condition will always return 'false' since the types 'false' and 'true' have no overlap.ts(2367)

But, as mentioned, the first code block is silently always false, causing headaches 😄

[andrewbranch]

Yeah, there are several issues asking us to be more aggressive about either recognizing code as unreachable or issuing errors when we already do (like here—value is successfully narrowed to never inside if (!value), but the user has no way of noticing that because they think they just detected it to be undefined, so of course they’re not going to try to use it). But I like this issue because the scope is very narrow, and seems to sit well within the unawaited Promise / uncalled function checks we already have.

Also related is #45267