feat(axios-to-whatwg-fetch): introduce #269
Conversation
|
omg please yes |
|
cc @nodejs/userland-migrations can I have first review on this one |
There was a problem hiding this comment.
This is a great initial implementation 🙂
I think it would be better to consolidate the config handling into a helper since all axios methods support it.
Blocker: There are some axios config options that are not supported here, and, if present in userland code, the absence of support will surely break that userland code. For instance:
transformResponse I think that can probably just be converted to an initial then() prepended to the outputted fetch?
transformRequest I think this can be handled by merely setting fetch's init.body like body: transformRequest(bodyExpression). That would probably also work for paramsSerializer.
If we don't want to handle those more exotic axios config options initially, I think that's okay, but the migration needs to detect them and abort.
| }, | ||
| }, | ||
| { | ||
| oldBind: '$.request', |
There was a problem hiding this comment.
Let's include the axios.request or its location (file.ext:row:col) in the warning output here so the user knows what triggered.
Also, I think maybe these should be console.error instead of warning because part of the migration failed.
There was a problem hiding this comment.
Let's include the axios.request or its location (file.ext:row:col) in the warning output here so the user knows what triggered.
I didn't get this
There was a problem hiding this comment.
Which part don't you get?
There was a problem hiding this comment.
it's what "warnWithLocation" do so i don't get what should i change
Co-authored-by: Jacob Smith <3012099+JakobJingleheimer@users.noreply.github.com>
Co-authored-by: Jacob Smith <3012099+JakobJingleheimer@users.noreply.github.com>
Co-authored-by: Jacob Smith <3012099+JakobJingleheimer@users.noreply.github.com>
Co-authored-by: Jacob Smith <3012099+JakobJingleheimer@users.noreply.github.com>
|
@JakobJingleheimer I tried to apply all of your proposal. But why the ci didn't ran ? |
|
It looks like CI did run? If not, was this whilst I was fiddling with the repo permissions? (I specifically told you on slack you'd temporarily have |
it's ran after the merge commit. idk what really happened but it's work now ! it's didn't help since I dunno why windows is doing windows thing |
JakobJingleheimer
left a comment
There was a problem hiding this comment.
Great tidy!
It's still missing handling for transformRequest, transformResponse, paramsSerializer, etc, which was the blocker before. It needs to either
- support them
- detect them and abort/fail the migration
Doing neither will result in broken userland code.
Related issue
close #191