Skip to content

Draft: Fix strict boolean eslint

Marwan Zibaoui requested to merge fix-strict-boolean into next

Why are we doing this to ourselves?

We have to actually change the logic of our app, so potentially introducing new bugs (or admittedly fixing some unknown ones) bu changing Falsy/Truthy checks to explicit null+undefined checks. We sometime have to rely on casting with as (a cardinal sin in typescript) to fix the linting problems.

This all seems like a net negative to me. I don't view Truthy/Falsy checks as a bad things in JS/TS, it's imho a nice things about the language that helps brings some sanity to the whole undefined/null/empty strings/0 madness in JS. Admittedly, using truthy/falsy also implies that as JS developers we actually deeply understand how everything is being dynamically typecasted to boolean.

I'm not sure what's the way forward, if the majority of people think that enforcing this rule is a good idea then i'll abide by it. Maybe we have some wiggle room with the options from the rule to make it a little bit less madenning? Personally I think the strict: true ts option, which we have enabled, and enables strictNullChecks, is enough 🤷

Some options on the table:

  • First enforce no-explicit-any rule, i.e. remove ALL any from the codebase. This is not an easy task but I believe this is much more worthy that the work we would do on that rule. I don't think this strict null check with all options enabled make any sense with explicit anys (see this comment)
  • Make a few utility functions that would help a lot: namely isNullOrEmpty and boolean type guard function.
Edited by Marwan Zibaoui

Merge request reports