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!

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.

Question - do we think that we should check this context analogously in no-unnecessary-condition? @bradzacher @alecmev
(can spin off a new issue if it warrants nontrivial discussion)

(playground)

function assert(x: unknown): asserts x {
  // eslint-disable-next-line @typescript-eslint/strict-boolean-expressions
  if (!x) {
    throw new Error('assertion');
  }
}

const truthyString = 'string';
if (truthyString) { }
    ~~~~~~~~~~~~

const alsoTruthyString = 'string';
assert(alsoTruthyString)

I'm of the opinion that we should, though it's less easy of a call to make than for the strict-boolean-expressions case, and I think it might warrant an option in that rule. In any case, we can dig into that further after seeing what people's initial impressions are.

Sounds like a valuable thing yeah.
Part of me thinks it might want an option for that rule though - I could see people using assertion functions to enforce "always true" invariants.

Sounds like a valuable thing yeah. Part of me thinks it might want an option for that rule though - I could see people using assertion functions to enforce "always true" invariants.

Yep, that's exactly my reservation as well, having used assertions myself to defend against regressions due to types at runtime not matching their declared types. Will file dedicated issue for that.

Do you think there ought to be an option for this rule as well?

nah this rule is straight-forward. It's not going to ban an assertion - just ensure you're using it strictly.