Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://typescript-eslint.io/rules/strict-boolean-expressions below:

strict-boolean-expressions | typescript-eslint

Disallow certain types in boolean expressions.

💡

Some problems reported by this rule are manually fixable by editor suggestions.

💭

This rule requires type information to run, which comes with performance tradeoffs.

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:

• Argument to the logical negation operator (!arg).
• The condition in a conditional expression (cond ? x : y).
• Conditions for if, for, while, and do-while statements.
• Operands of logical binary operators (lhs || rhs and lhs && rhs).
  • Right-hand side operand is ignored when it's not a descendant of another boolean expression. This is to allow usage of boolean operators for their short-circuiting behavior.
• Asserted argument of an assertion function (assert(arg)).
• Return type of array predicate functions such as filter(), some(), etc.

• Flat Config
• Legacy Config

eslint.config.mjs

export default tseslint.config({
  rules: {
    "@typescript-eslint/strict-boolean-expressions": "error"
  }
});

.eslintrc.cjs

module.exports = {
  "rules": {
    "@typescript-eslint/strict-boolean-expressions": "error"
  }
};

• ❌ Incorrect
• ✅ Correct

declare const num: number | undefined;
if (num) {
  console.log('num is defined');
}


declare const str: string | null;
if (!str) {
  console.log('str is empty');
}


function foo(bool?: boolean) {
  if (bool) {
    bar();
  }
}


const foo = <T>(arg: T) => (arg ? 1 : 0);


let obj = {};
while (obj) {
  obj = getObj();
}


declare function assert(value: unknown): asserts value;
let maybeString = Math.random() > 0.5 ? '' : undefined;
assert(maybeString);


['one', null].filter(x => x);

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();
  }
}


const foo = (arg: any) => (Boolean(arg) ? 1 : 0);

This rule accepts the following options:

type Options = [
  {
    
    allowAny?: boolean;
    
    allowNullableBoolean?: boolean;
    
    allowNullableEnum?: boolean;
    
    allowNullableNumber?: boolean;
    
    allowNullableObject?: boolean;
    
    allowNullableString?: boolean;
    
    allowNumber?: boolean;
    
    allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing?: boolean;
    
    allowString?: boolean;
  },
];

const defaultOptions: Options = [
  {
    allowAny: false,
    allowNullableBoolean: false,
    allowNullableEnum: false,
    allowNullableNumber: false,
    allowNullableObject: true,
    allowNullableString: false,
    allowNumber: true,
    allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing: false,
    allowString: true,
  },
];

Whether to allow strings in a boolean context. Default: true.

This can be safe because strings have only one falsy value (""). Set this to false if you prefer the explicit str != "" or str.length > 0 style.

Whether to allow numbers in a boolean context. Default: true.

This can be 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.

Whether to allow nullable objects, symbols, and functions in a boolean context. Default: true.

This can be safe because objects, functions, and symbols don't have falsy values. Set this to false if you prefer the explicit obj != null style.

Whether to allow nullable booleans in a boolean context. Default: false.

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.

Whether to allow nullable strings in a boolean context. Default: false.

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.

Whether to allow nullable numbers in a boolean context. Default: false.

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.

Whether to allow nullable enums in a boolean context. Default: false.

This is unsafe because nullable enums can be either a falsy number or nullish. Set this to true if you don't mind implicitly treating an enum whose value is zero the same as a nullish value.

Whether to allow anys in a boolean context. Default: false.

This is unsafe for because any allows any values and disables many type checking checks. Set this to true at your own risk.

Unless this is set to true, the rule will error on every file whose tsconfig.json does not have the strictNullChecks compiler option (or strict) set to true. Default: false.

Deprecated

This option will be removed in the next major version of typescript-eslint.

If 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.

If your project isn't likely to experience bugs from falsy non-boolean values being used in logical conditions, you can skip enabling this rule.

Otherwise, this rule can be quite strict around requiring exact comparisons in logical checks. If you prefer more succinct checks over more precise boolean logic, this rule might not be for you.

• no-unnecessary-condition - Similar rule which reports always-truthy and always-falsy values in conditions

Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.

See Troubleshooting > Linting with Type Information > Performance if you experience performance degradations after enabling type checked rules.

• Rule source
• Test source

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4