Since v5.6.0 `toBe()` returns `void` instead of `void | Promise<void>`

[gavvvr]

v5.5.0:

v5.6.x:

This leads to the following linting errors in my code:

   15:7   error  Unexpected `await` of a non-Promise (non-"Thenable") value                                              @typescript-eslint/await-thenable
   15:13  error  Placing a void expression inside another expression is forbidden. Move it to its own statement instead  @typescript-eslint/no-confusing-void-expression

[dprevost-LMI]

Thanks for the reports. The new typing was an intended change from this PR, where we realigned the types, since expect is not always a promise for non-promise types.

I suggest simply removing the const variable from the code to align with this new correct typing.
Are you seeing an underlying problem with this new approach that we might not have seen?

[gavvvr]

Hi @dprevost-LMI

I suggest simply removing the const variable from the code to align with this new correct typing.

I don't have consts in my real code. I added those constants to screenshot just to demonstrate the return type inferred. It was void | Promise<void>, but since v5.6.x it's just void.

My real code is just:

await expect(href).toBe('https://...')

since expect is not always a promise for non-promise types.

Ah, I think I understand now: expect() on string | null can't be inferred to Promise after calling .toBe() on it. Just checked the best practices page and await is not used on expect()-toBe() pair. It looks like the types have improved and I should just stop using await in such situations.

[dprevost-LMI]

Exactly non-promise type like string should not need await!
Let us know if you find any other problem, and I'll look into it!