@typescript-eslint/strict-boolean-expressions overly strict

[nokome]

I find the @typescript-eslint/strict-boolean-expressions lint rule a bit painful and have turned it off in Encoda because it makes heavy use of expressions like variable && variable.prop and variable || 'default'.

I cant' find a good rationale for this rule, especially for null and undefined. The TSLint docs, whence this rule came, offer no insight: https://palantir.github.io/tslint/rules/strict-boolean-expressions/.

Others also think this rule is too strict by default typescript-eslint/typescript-eslint#698. I suggest that until some of those options are available that we remove this rule.

[alex-ketch]

My motivation for enabling this rule is that I’ve encountered production bugs due to javascript’s implicit boolean casting, particularly easy to overlook when mapping over values where values like 0 and "" are falsy.

So things like this lead to bugs (Here third cell will incorrectly claim to be an empty cell):

const cells = [42, 15, 0, 12]
cells.map(cell => (
  <td>{cell ? cell : “Empty cell”}</td>
))

We dealt with it by using Lodash’s isNil helper to check whether a value was defined or not.

Some of the options do make it easier to breathe, but I would hesitate to disable the rule for new projects without knowing when/if those options will be added, since it’s easier to add these validations when writing the code rather than after the fact as you saw with Encoda.

[nokome]

Yeah, I can definitely see the use of this rule for 0 and "", but not so much for null and undefined. Yes, let's keep the rule, and this issue open, and see if those options get added - and review then. In the meantime, I'll try to change my habits, and use isNil.

[alex-ketch]

At first glance the new allowSafe option for strict-boolean-expressions rule seems like what we were looking for @nokome.
Will take a look and enable it if that's the case

Originally posted by @alex-ketch in #63 (comment)