-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Axios new options definition #3681
Axios new options definition #3681
Conversation
Full disclosure: I helped @quanlinc with this out of band. For what it's worth, it looks good to me :) |
@@ -4,16 +4,16 @@ declare module 'axios' { | |||
|
|||
declare type AxiosTransformer<T> = ( | |||
data: T, | |||
headers?: { [key: string]: any } | |||
) => any; | |||
headers?: {| [key: string]: mixed |}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think an exact object works here.
Later in the diff you used { [key: string]: mixed, ...}
for such case, any special thing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call, I think the original thought was flow will match up the type instead of literal key string, will this fixed and test covered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I misunderstood your comment, @quanlinc, but I'd like to clarify: We don't want to enumerate the possible keys here (they can be anything). I think we just need to make this inexact instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be just me not expressing myself clearly, I agree with what @pascalduez said, I had a wrong interpretation of using exact type, inexact is the way to go.
@quanlinc , with
|
@PresentProgrammer Sorry for breaking your build, didn't expect someone is still using 0.81, when inexact type is not introduced. I could fix this issue by splitting Axios libdef into two pieces like most other libraries do. But I also think it's consumers extra support burdens when using an older version of flow, or any tool. Which also reveals there's a gap in test between different flow-typed versions, which didn't catch your problem. I've done the work with the best of my knowledge by then and passed all tests. I'll leave the discussion to the community, at what extent do we need to support old version given this PR is already merged(Exactly how you run into this issue I presume) |
Sorry that slipped through my review. |
#3689 — related issue |
Should be fixed now. |
Yes, issue with Flow 0.81 solved. Thank you! |
Other notes:
Also did a little bit refactor to remove "any" type in definition and get tests passed