Bug: [no-unnecessary-boolean-literal-compare] False positive and unsafe fix with exactOptionalPropertyTypes

[andersk]

Before You File a Bug Report Please Confirm You Have Done The Following...

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have searched for related issues and found none that matched my issue.
• I have read the FAQ and my problem is not listed.

Playground Link

https://typescript-eslint.io/play/#ts=5.3.2&fileType=.tsx&code=MYewdgzgLgBCAOUCW4IC4YG8YDMA2AhgOYD8GARiCHgKYFgwC%2BMAZFroaRVbfTAD4wArmAAmNHEjA1RTGAF4sjANwAoUJGo0AdHhBEAFAmSpt%2BYgvmKcBPBBoBKNUA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Jge1tiacTJTIAhtEK0ARhw5IhTWo3yJoQ%2BLTIcAtsRGJ0UJdA7RI4MAF8QZoA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEk6AHgIbR64HGOoAKmsiWeAJ4AVQfzKU8mAK7oANOBqQSU5CwpgpsxQF8QOoA&tokens=false

Repro Code

const options: { flag?: boolean } & { flag?: boolean | undefined } = {};
console.log(options.flag === false);

ESLint Config

module.exports = {
  "rules": {
    "@typescript-eslint/no-unnecessary-boolean-literal-compare": "error"
  }
}

tsconfig

{
  "compilerOptions": {
    "exactOptionalPropertyTypes": true,
    "strict": true
  }
}

Expected Result

No errors. I haven’t changed the default options { allowComparingNullableBooleansToTrue: true, allowComparingNullableBooleansToFalse: true }, so comparing boolean | undefined to false should be allowed.

Actual Result

  2:13  error  This expression unnecessarily compares a boolean value to a boolean instead of using it directly  @typescript-eslint/no-unnecessary-boolean-literal-compare

The rule automatically applies an incorrect fix options.flag === false → !options.flag, which changes the output of the code from false to true.

Additional Info

No response

[bradzacher]

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.

[andersk]

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.

[andersk]

It looks like this is the related TypeScript bug:

• Type Intersection incorrect for optional parameters in functions with exactOptionalPropertyTypes: true. undefined type is flip based off Intersection types microsoft/TypeScript#58174

[kirkwaiblinger]

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

[bradzacher]

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.