banTruthyFunction, ban functions from being coerced to boolean in if, switch statements

[jpike88]

A rule that makes it difficult to accidentaly perform a truthy check on a function is ideal.

We're working with signals where every signal is a function, and it's often normal to do truthy checks on the values of that signal. It's also easy to forget calling the signal to get its actual value.

Yes, this means that it discourages the use of truthy checks if the function is an optional property check (in which case I'd rather have it be the exception, rather than the rule).

const foo = {
	bar: () => {
          //doSomething 
    }
}

if(foo.bar){ // this is not desired

}

if(foo.bar()){ // this is what we really want

}

[arendjr]

This sounds a lot like typescript-eslint's strict-boolean-expressions rule, although that one is a bit more generic. I agree such a Biome version called useStrictBooleanExpressions would make sense to have.

[jpike88]

I think it's worth in the tests ensuring that it can cover signals as I'm not sure they fit the classic definition of a function, the base type of signals are below:

type Signal<T> = (() => T) & {
    [SIGNAL]: unknown;
};

If you need a simple repo to test against I can help

[jpike88]

based on #7326 (reply in thread), looks like signal types do inherit from function as I was able to succesfully ban use of length property by editing the ambient Function type provided by typescript