Updated superagent dependency

[johnkrzywanek]

This will updated superagent dependency to avoid deprecation warnings disclosed in this issue: #262

[austince]

Thanks for the PR @johnkrzywanek ! Can you link to the breaking changes between superagent 3 and 5? Also, if no code changes are necessary, what do you think about supporting superagent >=3 instead of locking it to 5?

[johnkrzywanek]

Sure thing @austince! Here are the changes, taken from: https://github.com/visionmedia/superagent/releases?after=v5.0.3

Breaking changes
Node.js v4 has reached it's end of life, so we no longer support it. It's v6+ or later. We recommend Node.js 10.
We now use ES6 in the browser code, too.
If you're using Browserify or Webpack to package code for Internet Explorer, you will also have to use Babel.
The pre-built node_modules/superagent.js is still ES5-compatible.
.end(…) returns undefined instead of the request. If you need the request object after calling .end() (and you probably don't), save it in a variable and call request.end(…). Consider not using .end() at all, and migrating to promises by calling .then() instead.
In Node, responses with unknown MIME type are buffered by default. To get old behavior, if you use custom unbuffered parsers, add .buffer(false) to requests or set superagent.buffer[yourMimeType] = false.
Invalid uses of .pipe() throw.

And I agree with supporting >=3, however it seems that tests are failing on setCookies method, didn't have time to investigate it further though.

[austince]

Sounds good, no rush! I'm not sure what to do about the .end(...) changes, as they could be breaking for some people. I'm also not sure about the repercussions of the MIME type. @keithamus do you think it's worth trying to support this? I know we've talked about trying to move away from superagent all together in favor of Fetch, I just haven't had the time to finish that project...

[schrodervictor]

If I can drop my two cents here, moving away from superagent would greatly help to avoid breaking changes and conflicting dependencies in the future, allowing the library to evolve more freely.