fix(types) Correct overload order for act without strictNullChecks in TypeScript#622
Conversation
|
@mpeyper I've followed the contributors doc for this, but it looks like you're using a bot for adding contributors now. Do I need to strip that change out? |
|
No you don't, the bot is just to help us if someone forgets! |
Codecov Report
@@ Coverage Diff @@
## main #622 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 15 15
Lines 218 218
Branches 26 26
=========================================
Hits 218 218 Continue to review full report at Codecov.
|
|
Thanks @andyrooger, I can see there is actually a note about this very issue in react's own types for |
|
@mpeyper so they do! That could have saved me the long explanation. Thanks for the merge :) |
|
🎉 This PR is included in version 5.1.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What:
Correct the TypeScript definitions, so that we produce the correct return type for
act(...)calls whenstrictNullChecksis turned off.Why:
Take the following code
With
strictNullChecksturned on, the type ofresultisPromise<undefined>as you would expect.Turn
strictNullChecksoff, and the type ofresultis nowvoid.This is particularly highlighted in my case as the project I'm working on has eslint rules that will complain if we try to await a value it thinks is not thenable.
How:
It seems the issue is that with
strictNullChecks, the two overloads foract(...)do not have a lot of overlap so the order we specify them in doesn't matter. WithoutstrictNullChecks, anything that matches the async overload also matches the sync overload. Since the sync overload is specified first, it is always chosen.I've just swapped the overloads around so that the more specific one with Promises is checked first.
Checklist: