Enhancement: [strict-boolean-expressions] options for operators/positions

[That-Guy977]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/strict-boolean-expressions

Description

strict-boolean-expressions should offer granular options for allowing/disallowing non-booleans in certain positions, such as the conditional position of a if statement or ternary, or when using specific boolean operators.

Fail

/* eslint
  "@typescript-eslint/strict-boolean-expressions": ["error", { "!": false }]
*/

!0n;
!{};

/* eslint
  "@typescript-eslint/strict-boolean-expressions": ["error", {
    "!": { "allowNumber": true, "allowString": false }
  }]
*/

!"";
// unspecified operators/options use default
!0n;
0n && true;

Pass

/* eslint
  "@typescript-eslint/strict-boolean-expressions": ["error", { "!": true }]
*/

!0n;
!{};

/* eslint
  "@typescript-eslint/strict-boolean-expressions": ["error", {
    "!": { "allowNumber": true, "allowString": false }
  }]
*/

!0;
// unspecified operators use default
if ("");
0 && "";

Additional Info

This is motivated by a recent inquiry on the TypeScript Community Discord server, wanting A to be linted, in favor of B:

declare const x: number;

// A
<>{x && <SomeElement />}</>;

// B
<>{!!x && <SomeElement />}</>

Currently, with allowNumber: false, the rule will correctly error on A, but will not allow the preferred fix.

I'm not sure what format of options would be ideal for granular control while also being compatible with the current options, so the options in the example are just for demonstration.

[bradzacher]

Duplicate of #2770

[That-Guy977]

I might be missing the point of that issue, isn't that more specifically targeting JSX? This is a suggestion for more granularity within the option, just motivated by the same issue