For official packages the process of update is still ongoing. I haven’t had time to get back to it for a while. For other accounts packages I have only fixed those that I have under control.
For the warnings that @waldgeist is referring to, if they are still using http v1.x, then there is your culprit. Beyond that it means that they are using the native http which throws the warning. If you could narrow it down to specific package then we could open an issue on the repository and move towards a fix.
Yes, I know, I have checked them. And I think it’s a good idea to show a deprecation message. My only issue here is: It does not show only once every session, but multiple times. This clutters the console. Can’t the package just store a flag that it has already warned the developer for the running session?
My bigger concern, however, is that the new http package is not 100% backwards compatible, which might be unnoticed. I don’t know how many community packages are actually using npmRequestOptions. But if they do, there might be unwanted side-effects. In my case, I needed this to get the raw data (buffer) of a downloaded (Zip) file. Which might not be the most prominent use-case, but is also not uncommon.
Of course, if package maintainers explicitly upgrade the dependency to 2.0+, I would expect them to check these limitations. However, I also found packages that just set http as a dependency, i.e. without any version. These would then auto-upgrade without any further notice, I guess.
Maybe the new http package could warn if the npmRequestOptions option is passed in?
Had some spare time during the holidays and thought I’d take a shot at uplifting the HTTP package if anyone wants a replacement. Can use callbacks or async/await without Fibers.
Hey, just wrapping up the option for rawResponse which will allow you to get the raw data as an ArrayBuffer. Maybe it’ll help or maybe a bit too late .
.