fix(proxy): transparently forward errors when passing ofetch #466
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
π Linked issue
#464
β Type of change
π Description
As discussed in #464 and nitrojs/nitro#1489.
ProxyOptions
type updated to allow overriding the default value (true
).Is it breaking change?
I would say so, users may depend on error masking. This is not strictly a bug. Mandatory xkcd: https://xkcd.com/1172/
I personally dislike this solution a lot; if we allow freedom of passing fetch implementation, it should be up to the callee to configure the behavior of their implementation exactly as they like. If it's required to pass option to do so, they already can do so with
fetchOptions
.Forcing
ignoreResponseError: true
is implicitly re-configuring non-default user-passed implementation. I think better approach is to allow the freedom along with passing the responsibility. Another edge-case is when user passes fetch implementation which also supportsignoreResponseError
or throws on unknown parameters - both sound plausible to me.π Checklist