Skip to content

Conversation

@johnkrzywanek
Copy link

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

@austince
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants