Skip to content

refactor: resolve strict-boolean-expression warnings [#1596]

This MR resolves the warnings caused by the strict-boolean-expression warnings.

Whenever possible, I figured out what the actual potential values of the variable in question could be, and added according checks.

For cases where I couldn't figure it out, or where the original intention behind the check wasn't clear, I disabled the rule (didn't happen often, though). For the composer feature, which has type checking turned off, I also turned off the strict-boolean-expression rule – the latter doesn't really make sense without the former. We'll get to this when we tackle the composer feature itself.

The intention was to keep the old logic. However, there is one logic change, where I think it now meets the original intention (I think it's also a good example why the rule makes sense): The values 0, false and null are no longer considered valid domainLists or licenseStateLists. We might want to align the AdBlock implementation one day.

Finally, I removed the rule relaxation (from error to warning) from the ESLint config file.

Merge request reports