You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 5, 2021. It is now read-only.
I'm not sure whether this is out of scope for this project, but I think it would be interesting to collect passed types even in places where type information is already supplied in the source code and then check whether the typings in the source code are actually correct.
The text was updated successfully, but these errors were encountered:
Sounds like an interesting direction - especially when working with server-side API for which the types have been specified manually. I'm keeping this open in case someone wants to take a stab at it.
What do we do in a case where the two don't match? Do we attempt to fix it, just emit a warning when running the fixes file? Emit a warning in runtime?
I think for developer convenience it would be nice if conflicting / non assignable types were added as a union type. That way one can use ones favorite vcs tool to compare all type changes. As a stretch goal it would obviously also be nice fo have some logging output which shows the type observed and the corresponding call stack so one can determine where it came from and if perhaps the caller is passing the wrong type. That said, I'm not aure whether this can be achieved without deeply integrating into the respective browsers developer tools.
I'm not sure whether this is out of scope for this project, but I think it would be interesting to collect passed types even in places where type information is already supplied in the source code and then check whether the typings in the source code are actually correct.
The text was updated successfully, but these errors were encountered: