I wonder if this could be expanded beyond comparison operators and apply to expressions in general. Expressions that evaluate to truthy/falsy would be common scenarios, but the scope would probably go beyond that.

A couple of examples:

This would flag as an issue:

if (this.mySignal)

This would also flag as an issue:

const myComputed = computed(() => this.mySignal + 1);

The rule could be disabled like other lint rules such as for the line that follows or whole sections of code. This could be an opt-out for the unlikely scenarios where we intend to check the signal reference itself instead of its unwrapped value.

Yes, i have exactly this problem with the if statement.

At our company we transfer a lot of components to signals but simply changing the inputs results in a lot of these cases, where the input is simply checkt for truthy/falsy in an if statement.
Got some sample code from Stackoverflow: https://stackoverflow.com/questions/78038046/how-to-prevent-angular-signal-references-being-used-instead-of-signal-values

public conditionalSignal = signal(false);
...

// Accidentally using the reference:
if (conditionalSignal) {
  ...
}

// Instead of something like this:
if (conditionalSignal()) {
  ...
}

This is really dangerous, as it's not easy to spot the wrong behavior while rewriting the components, especially when rewriting lots of components in a row.

I'd really like to have an es-lint rule for that.

I agree with expanding it to more places, similar to what was requested in #1891.

I've update no-misused-signals proposal. I think this issue can be closed.

Should be added. can cause a lot bugs !

I'll consolidate into #1891, thanks all