Bug: [no-unnecessary-boolean-literal-compare] False positive and unsafe fix with exactOptionalPropertyTypes about typescript-eslint HOT 6 CLOSED

It looks like this is the related TypeScript bug:

• microsoft/TypeScript#58174

from typescript-eslint.

Both members of the intersection have flag?: …, not flag: …. So the property is allowed to be absent.

Which is why you can write options.flag.valueOf() without any guards and TS will not error.

This does seem like a TypeScript bug.

When we inspect the types for .flag, TS tells us its type is just boolean. It says there's no possibility of it being undefined. Hence the rule errors.

That shows (property) flag?: boolean. The ? indicates that TypeScript knows the property might be absent.

from typescript-eslint.

That shows (property) flag?: boolean

Yes - that's because TS's "intellisense printer" shows you the type AND the context. So when it shows you the context (the property name) it also needs to show the "divider". When it prints the divider it also inspects the flags for the property to determine if it should also print the ? in addition to the standard :.

microsoft/TypeScript#58174 looks to be the culprit - that's why it works without the intersection but breaks it with it.

So I'll close this as a bug in TS.

from typescript-eslint.

This is actually working as expected.

When you intersect two union types the resulting type is the intersection of the unions - i.e. the types that exist in both unions.
For example - type T = (number | undefined) & number; - T === number.

When you intersect two object types TS will include all the unique properties between the two types, and then it will intersect the common properties. So what you end up with in your example is boolean & (boolean | undefined) - i.e. boolean.

Which is why you can write options.flag.valueOf() without any guards and TS will not error.

When we inspect the types for .flag, TS tells us its type is just boolean. It says there's no possibility of it being undefined. Hence the rule errors.

If you tweak the types slightly you'll see that rules like no-unnecessary-condition will also error here because the types tell us there's no undefined.

IDK if the behaviour is correct from TS's side here - surely it should be erroring on the property / saying the type is undefined at read time?
I don't know for sure - would require an issue to discuss with them.

from typescript-eslint.

@bradzacher but granted it's an optional property the two intersection parts are basically identical unless you have the --exactOptionalPropertyTypes flag right?

FWIW our code just doesn't handle intersections at all, see

Also, side note, this seems like the type of case that would benefit from assignability checking a la microsoft/TypeScript#56448. Is there an issue on our side for introducing that into the codebase now that it's landing/landed?

from typescript-eslint.

Disregard my comment, didn't realize --exactOptionalPropertyTypes is set

from typescript-eslint.