[strict-boolean-expressions] allowSafe should allow safe literal string/number types

[ericbf]

Repro

{
  "rules": {
    "@typescript-eslint/strict-boolean-expressions": ["error", { "allowSafe": true }]
  }
}

declare let x: 1 | false
declare let y: "hello" | false

if (x) { ... }
if (y) { ... }

Expected Result
The if checks of the literal types should not have any error, as they are safe checks.

Actual Result
The if checks are flagged as if they weren't safe (as if they were not the literal types, but instead were string or number, which would not be safe).

Versions

package	version
@typescript-eslint/eslint-plugin	2.17.0
@typescript-eslint/parser	2.17.0
TypeScript	3.7.5
ESLint	6.8.0
node	13.7.0
npm	6.13.6

[bradzacher]

merging into #1515

[ericbf]

@bradzacher this isn't really part of reworking the options, but rather an oversight (bug) in the current implementation of an existing option. Are we saying that (potential) bugs in the existing options will not be fixed in favor of the rework options issue?

[bradzacher]

Adding this in will be a relatively non-trivial amount of work, so I figured that considering there's already a PR for the rework open, that it was better to consolidate discussion and work there.

However, if you're happy to work on a PR to add this check into the current rule, then happy to accept a PR.
We're a community run project, so if you're not up to PRing it, then it likely won't get worked on.

[bradzacher]

Reopening this as we'll defer this work until after #1515 is closed.

[phaux]

this was fixed long time ago in #3236

[JoshuaKGoldberg]

I think this is a different issue. #3115->#3236 were about number | undefined & similar; this one is reporting number | false & similar.

With "allowNullableNumber": true:

• number | false: gives a complaint
• number | undefined: does not give a complaint

...but, while this isn't quite the same, I think this is more of a feature request than a bug. The rule's intent is to stop you from directly checking values with types like number | false in conditionals. It'd be a feature request to add it in.

Since there has been almost no noise on this issue since it was posted 2.5 years ago, we've reworked the rule since this issue, similar situations are fixed, and the workaround is pretty trivial (add !!), I'm going to go ahead and close this issue. If you'd like to see it happen, please file a new issue.

Thanks all!