Re-export reqwest crate #158
Conversation
In a large project, it's not unheard of for multiple mutually-incompatible versions of a major crate like `reqwest` to end up in the mix. By re-exporting the version of `reqwest` used by `reqwest-middleware`, we can be sure we're referring to the *correct* `reqwest`, rather than some other, incompatible, `reqwest`.
There was a problem hiding this comment.
my 2 cents, this is a good idea
sometimes people don't want to re-export dependencies because whatever you export publicly is part of your API. So if you bump your dependency for breaking changes, and you export it publicly, that becomes a breaking change to your API as well, automatically, even though it might otherwise not be.
In this case though, the reqwest-middleware crate already wraps the entire API of reqwest and exports an equivalent API, and it re-exports many of its types already. It seems like any breaking change to reqwest API will necessarily lead to a breaking change happening in this crate too if it keeps API parity. So there seems to be little reason not to re-export reqwest
There was a problem hiding this comment.
Thank you for this 👍
I was a little unsure about re-exporting reqwest since I haven't seen this type of re-export very often in the ecosystem. Thank you very much @cbeck88 for leaving your review, it was helpful for me in making a decision.
In a large project, it's not unheard of for multiple mutually-incompatible versions of a major crate like
reqwestto end up in the mix. By re-exporting the version ofreqwestused byreqwest-middleware, we can be sure we're referring to the correctreqwest, rather than some other, incompatible,reqwest.