search

chaijs / chai-http

HTTP Response assertions for the Chai Assertion Library.
http://chaijs.com/plugins/chai-http
633 stars 113 forks source link

Updated superagent dependency #265

Closed johnkrzywanek closed 3 years ago

johnkrzywanek commented 4 years ago

This will updated superagent dependency to avoid deprecation warnings disclosed in this issue: https://github.com/chaijs/chai-http/issues/262

austince commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.