Enhancement: [strict-boolean-expressions] Check truthiness assertion functions

[alecmev]

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

For example, ok from node:assert has the following shape:

function ok(value: unknown, message?: string | Error): asserts value;

It appears that currently the rule just looks at value, sees unknown, and moves on. So it's possible to write this:

const foo: string | undefined = 'bar';
if (foo) ... // Error
ok(foo); // Fine

Instead, it would be nice if it also looked at the return type and took asserts value into account, treating it as if (!value) throw. There's more to asserts than just checking truthiness, but handling the simplest case (no is) would already go a long way, as that covers all ok-like assertion functions out there.

Fail

const foo: string | undefined = 'bar';
ok(foo);

Pass

const foo: string | undefined = 'bar';
ok(foo !== undefined);

Additional Info

No response

[kirkwaiblinger]

I'm +0.5 to this, since I've run into this as well, and been annoyed by it. The +0.5 rather than +1 is due to the fact that it's an easy and obvious place to use aneslint-disable comment, since I can only imagine this coming up in the first place in isolated, conspicuous scenarios.

EDIT - I crossed wires with something else when writing that. Reading more closely, I'm fully +1 on this. An assertion function argument is a boolean context, complete with narrowing.

We'll see what others think!

[bradzacher]

I'd never really thought about it like this.
I guess that asserts foo is defined by the type system to mean if not foo then throw - regardless of the underlying implementation of the assertion function.
And it looks like TS does essentially treat it like a boolean context where the code after the call is the "condition was true" branch.

It may be a bit weird for people to think of assertions like this but I think there's value in it.

Though note that we would only check asserts foo functions and not asserts foo is bar functions.