4.9 regression with in operator: object is incorrectly narrowed to never

[OliverJAsh]

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

• This changed between versions 4.8 and 4.9

⏯ Playground Link

Playground link with relevant code

💻 Code

export const checkIsTouchDevice = () =>
    "ontouchstart" in window ||
    "msMaxTouchPoints" in
        // ❌ Unexpected TS error: Property 'navigator' does not exist on type 'never'
        window.navigator;

I've reduced it down to this:

declare const obj: { a: unknown; b: unknown };

"a" in obj ||
    "prop" in
        // ❌ Unexpected TS error: Property 'b' does not exist on type 'never'
        obj.b;

[ahejlsberg]

This is an effect of #50666.

The error in the second example looks correct. The type { a: unknown, b: unknown } specifies that property a is always present, and thus the false branch of || is assumed to be unreachable. If you change the declaration to a?: unknown, the false branch is assumed to be reachable (which produces a different error because obj could be a non-object).

However, we do have an issue in the first example. The window variable has type Window & typeof globalThis and the ontouchstart property is indeed marked optional in the Window type. However, typeof globalThis is constructed from the types of all global var declarations, and it isn't possible to mark those optional. So, the var declaration for ontouchstart in lib.dom.d.ts causes the checker to assume the window.ontouchstart property is always present. And that causes the problem. Looks like we need to imply optionality when the global variable type includes undefined.

[fatcerberus]

… property a is always present, and thus the false branch of || is assumed to be unreachable …

Couldn’t this be a problem for feature tests? i.e. testing for existence of methods or properties that are always-present according to the types, but the program wants to gracefully degrade if the browser doesn’t support them. That’s what I assumed the ontouchstart check in the OP was, actually.

[ahejlsberg]

Well, there's sort of a gray area when it comes to non-optional properties of type any, unknown, or types that include undefined. We could limit the narrowing to only happen in cases where the type unequivocally indicates the property can't be undefined and therefore must be present. This of course would come at the cost of not being able to have narrowing occur based on in tests of properties of possibly-undefined types.

[ahejlsberg]

Hmm, turns out our compiler itself actually contains code that depends on narrowing based on in checks for properties that can be undefined. So, it seems we need to stay with the absence of a ? modifier being an indicator that a property is always present (regardless of its type) such that in tests for that property can guide narrowing.