Make fail() to break the typescript's control flow

[xamgore]

Imagine we have a code like this. If expect.fail() returns R, we won't be able to call val.slice as val may be null, thus we get a compiler error.

    test('example', async () => {
      const val = foo() // string | null
      if (!val) expect.fail('string expected, got null')
      
      val.slice(5) // some operations with the string
      // ...
    })

Though, if we change expect.fail() return type to never, typescript will start understanding the further execution won't be possible with val === null, so the val.slice is exactly string::slice call. And there won't be any compilation errors.

[xamgore]

@mattphillips are you ok with this?

[WORMSS]

would you need not.pass() also?

[WORMSS]

I thought this sounded familiar

#204

#204 (comment)

https://github.com/keeganwitt/jest-extended/pull/26

Seems fail is currently a no-op according to the code?

[xamgore]

would you need not.pass() also?

I would consider only fail to increase the probability of this PR getting merged.

[SimenB]

Hmm, this isn't implemented according to the docs. Should we just remove it from the types?

https://github.com/jest-community/jest-extended#failmessage

[SimenB]

Landed #204, so this makes sense now. Thanks!