search

ctimmerm / axios-mock-adapter

Axios adapter that allows to easily mock requests
MIT License
3.44k stars 241 forks source link

Support for validateStatus: null #296

Closed marcbachmann closed 3 years ago

marcbachmann commented 3 years ago

I've observed some issue where non-200 responses got rejected with an error object instead of an error instance. This was caused by the current settle implementation, which didn't support the validateStatus config completely.

I've also removed support for axios < 0.16 as all the tests were failing with it and it's not worth to fix them. Axios 0.19 got released 5 years ago. Maybe we could also drop older versions as they aren't tested.

Changelog

marcbachmann commented 3 years ago

@ctimmerm how do we move forward here? looks like you're busy with other things.

should we fork this repo to improve the compatibility with recent versions of axios?

maybe just an agreement and some companies behind this or another repo already help a lot.

ctimmerm commented 3 years ago

Sorry for not getting back to you earlier and losing track of this.

Even though the tests are written against newer versions of axios, the library should still work with older versions. The problem with dropping support for older axios versions is that it's technically a breaking change that would require a major version bump for axios-mock-adapter.

If we do a major version bump, there were some other things that I wanted to include at the same time, like making the different HTTP verbs work in a more consistent way, using axios internal methods instead of reimplementing e.g. settle, switching to TypeScript to provide first-class types, and a few other smaller things. I started working on a v2 with those changes some time ago, but unfortunately did not find time to finish it.

If there are interested parties, I'm also open to moving the repository to its own organization and grant access to other maintainers.

marcbachmann commented 3 years ago

I agree that the breaking change should be done separately in that case. 👍 I've force pushed the changes and made it compatible with older versions.

You have quite a lot planned and smaller incremental steps might be easier 😃 😉 . It doesn't really matter how many breaking changes there are. As long as the project is making progress. I'd just tackle then breaking change first, remove the support for all the old code and only after that migrate to typescript.

Feel free to add me as contributor if you like, but it probably won't help much for now. I'm a bad candidate to help on the work with typescript 😓 .