I've been debugging an issue where the await-interactions rule and @typescript-eslint/await-thenable conflict.
The type declarations of userEvent.click state that it returns void and so adding an await causes the typescript rule to complain.
Trying to pick apart the code, as far as I can tell once a function, fn, is wrapped in instrument it will return a promise if and only if the original fn returned a promise. So assuming that it is always awaitable seems wrong.
Certainly, when I run and debug userEvent.click() in my story it returns 'undefined' rather than a Promise.
If the types in @storybook/testing-library are correct then @typescript-eslint/no-floating-promises would ensure that all Promises are awaited and the await-interactions rule seems redundant.
I've been debugging an issue where the
await-interactionsrule and@typescript-eslint/await-thenableconflict. The type declarations ofuserEvent.clickstate that it returns void and so adding anawaitcauses the typescript rule to complain.Trying to pick apart the code, as far as I can tell once a function,
fn, is wrapped ininstrumentit will return a promise if and only if the originalfnreturned a promise. So assuming that it is always awaitable seems wrong.Certainly, when I run and debug
userEvent.click()in my story it returns 'undefined' rather than a Promise.If the types in @storybook/testing-library are correct then
@typescript-eslint/no-floating-promiseswould ensure that all Promises are awaited and theawait-interactionsrule seems redundant.