the same as a nullish value.

### `allowAny`

Allows `any` in a boolean context.
This is unsafe for obvious reasons.
Set this to `true` at your own risk.

### `allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing`

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.

## Fixes and Suggestions

This rule provides following fixes and suggestions for particular types in boolean context:

- `boolean` - Always allowed - no fix needed.
- `string` - (when `allowString` is `false`) - Provides following suggestions:
  - Change condition to check string's length (`str` → `str.length > 0`)
  - Change condition to check for empty string (`str` → `str !== ""`)
  - Explicitly cast value to a boolean (`str` → `Boolean(str)`)
- `number` - (when `allowNumber` is `false`):
  - For `array.length` - Provides **autofix**:
    - Change condition to check for 0 (`array.length` → `array.length > 0`)
  - For other number values - Provides following suggestions:
    - Change condition to check for 0 (`num` → `num !== 0`)
    - Change condition to check for NaN (`num` → `!Number.isNaN(num)`)
    - Explicitly cast value to a boolean (`num` → `Boolean(num)`)
- `object | null | undefined` - (when `allowNullableObject` is `false`) - Provides **autofix**:
  - Change condition to check for null/undefined (`maybeObj` → `maybeObj != null`)
- `boolean | null | undefined` - Provides following suggestions:
  - Explicitly treat nullish value the same as false (`maybeBool` → `maybeBool ?? false`)
  - Change condition to check for true/false (`maybeBool` → `maybeBool === true`)
- `string | null | undefined` - Provides following suggestions:
  - Change condition to check for null/undefined (`maybeStr` → `maybeStr != null`)
  - Explicitly treat nullish value the same as an empty string (`maybeStr` → `maybeStr ?? ""`)
  - Explicitly cast value to a boolean (`maybeStr` → `Boolean(maybeStr)`)
- `number | null | undefined` - Provides following suggestions:
  - Change condition to check for null/undefined (`maybeNum` → `maybeNum != null`)
  - Explicitly treat nullish value the same as 0 (`maybeNum` → `maybeNum ?? 0`)
  - Explicitly cast value to a boolean (`maybeNum` → `Boolean(maybeNum)`)
- `any` and `unknown` - Provides following suggestions:
  - Explicitly cast value to a boolean (`value` → `Boolean(value)`)

## When Not To Use It

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.

## Related To

- [no-unnecessary-condition](./no-unnecessary-condition.md) - Similar rule which reports always-truthy and always-falsy values in conditions