Give ts error when using optional chaining or nullish coalescing on nonnullable object

[fa93hws]

Suggestion

It sometimes happens that a variable / prop was original nullable, but evolved to be non-nullable, but there are places using it with ? not removed.

🔍 Search Terms

optional chainning, feature request, nonnullable

✅ 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

Gives ts error when optional chaining is used on a nonnullable object.

📃 Motivating Example

const a: {
  b: number;
} | undefined;

const bar = a?.b;
const foo = a ?? { b: 2 };

After few iteration, a becomes nonnullable:

const a: {
  b: number
}

However, we are not aware of those usages. This can help to reduce the output JS file size by removing unnecessary code.

💻 Use Cases

We want use this to remove unnecessary code and hence reduce the size of emitted JS file.

[nmain]

Closely related to #11920

[DanielRosenwasser]

Also, the question of "does this introduce undefined to the type doesn't already include undefined?" was a little tied in, and I think it's unfortunate that we didn't make it do that for the "defensive code when the types are wrong" use-case.

#36623

[soffes]

I recently ran into a bug caused by this. I updated my case before the ?? and didn't realize it would never fall through. Coming from Swift, I expected this to be an error if I did it wrong so I didn't look closely at this part of the code when debugging.

I personally love errors whenever code is unreachable. Totally understand if this isn't always possible in TypeScript.

[andrewbranch]

Also related to

• flag to check for type-unreachable code #45267
• Apply uncalled function checks to boolean expressions (ts2774) #46051
• Inverted Promise should warn like it does without inverting #46140
• Check truthy/falsy-ness for non-primitives to identify unreachable code #44840
• !constant in boolean expression not reported (function not called error) #45667

Lots of recent demand both for identifying more code branches as unreachable and for stricter handling of unreachable expressions.