strict-boolean-expressions)Forbids usage of non-boolean types in expressions where a boolean is expected. boolean and never types are always allowed. Additional types which are considered safe in a boolean context can be configured via options.
The following nodes are considered boolean expressions and their type is checked:
!arg).cond ? x : y).if, for, while, and do-while statements.lhs || rhs and lhs && rhs).Examples of incorrect code for this rule:
// nullable numbers are considered unsafe by default let num: number | undefined = 0; if (num) { console.log('num is defined'); } // nullable strings are considered unsafe by default let str: string | null = null; if (!str) { console.log('str is empty'); } // nullable booleans are considered unsafe by default function foo(bool?: boolean) { if (bool) { bar(); } } // `any`, unconstrained generics and unions of more than one primitive type are disallowed const foo = <T>(arg: T) => (arg ? 1 : 0); // always-truthy and always-falsy types are disallowed let obj = {}; while (obj) { obj = getObj(); }
Examples of correct code for this rule:
// Using logical operators for their side effects is allowed const Component = () => { const entry = map.get('foo') || {}; return entry && <p>Name: {entry.name}</p>; }; // nullable values should be checked explicitly against null or undefined let num: number | undefined = 0; if (num != null) { console.log('num is defined'); } let str: string | null = null; if (str != null && !str) { console.log('str is empty'); } function foo(bool?: boolean) { if (bool ?? false) { bar(); } } // `any` types should be cast to boolean explicitly const foo = (arg: any) => (Boolean(arg) ? 1 : 0);
type Options = { allowString?: boolean; allowNumber?: boolean; allowNullableObject?: boolean; allowNullableBoolean?: boolean; allowNullableString?: boolean; allowNullableNumber?: boolean; allowAny?: boolean; }; const defaultOptions: Options = { allowString: true, allowNumber: true, allowNullableObject: true, allowNullableBoolean: false, allowNullableString: false, allowNullableNumber: false, allowAny: false, allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing: false, };
allowStringAllows string in a boolean context. This is safe because strings have only one falsy value (""). Set this to false if you prefer the explicit str != "" or str.length > 0 style.
allowNumberAllows number in a boolean context. This is safe because numbers have only two falsy values (0 and NaN). Set this to false if you prefer the explicit num != 0 and !Number.isNaN(num) style.
allowNullableObjectAllows object | function | symbol | null | undefined in a boolean context. This is safe because objects, functions and symbols don't have falsy values. Set this to false if you prefer the explicit obj != null style.
allowNullableBooleanAllows boolean | null | undefined in a boolean context. This is unsafe because nullable booleans can be either false or nullish. Set this to false if you want to enforce explicit bool ?? false or bool ?? true style. Set this to true if you don't mind implicitly treating false the same as a nullish value.
allowNullableStringAllows string | null | undefined in a boolean context. This is unsafe because nullable strings can be either an empty string or nullish. Set this to true if you don't mind implicitly treating an empty string the same as a nullish value.
allowNullableNumberAllows number | null | undefined in a boolean context. This is unsafe because nullable numbers can be either a falsy number or nullish. Set this to true if you don't mind implicitly treating zero or NaN the same as a nullish value.
allowAnyAllows any in a boolean context. This is unsafe for obvious reasons. Set this to true at your own risk.
allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoingIf this is set to false, then the rule will error on every file whose tsconfig.json does not have the strictNullChecks compiler option (or strict) set to true.
Without strictNullChecks, TypeScript essentially erases undefined and null from the types. This means when this rule inspects the types from a variable, it will not be able to tell that the variable might be null or undefined, which essentially makes this rule a lot less useful.
You should be using strictNullChecks to ensure complete type-safety in your codebase.
If for some reason you cannot turn on strictNullChecks, but still want to use this rule - you can use this option to allow it - but know that the behavior of this rule is undefined with the compiler option turned off. We will not accept bug reports if you are using this option.
TSLint: strict-boolean-expressions
no-unnecessary-condition - Similar rule which reports always-truthy and always-falsy values in conditions