Nowhere in the readme do I state that redaxios is intended to be identical to Axios. That would make the module pointless.

It doesn't make sense to replicate Axios' documentation here, because redaxios is a strict subset of its functionality. A list of compatibility notes would be better, I simply haven't had the time to write it and currently would prefer to spend that time merging the open PRs that ultimately reduce those differences.

I don't think there is any readme text that would address the issue of folks believing that this is somehow a simultaneously
a byte-for-byte identical clone of axios and 80% smaller than axios. There's no magic that makes things free, everything is a tradeoff - pretty much every project I maintain can be considered to have that disclaimer.

Absolutely. My comment was not intended do bash the project or something.

I did comment because in the company where I work, we choose to change axios to redaxios because of what is stated in the readme. These were the selling points for us:

Axios has a great API [...] Redaxios provides that API in 800 bytes [...]
[...] Redaxios exists so that you can use that same API [...]
import axios from 'redaxios';
// use as you would normally

Based on those points, seems that redaxios IS a drop-in replacement.

I will prepare a PR with compatibility notes.

Anyway, thank you for your time and the library.
We are still currently using redaxios in production, but axios if we need onUploadProgress.

Is the goal to be 100% compatible with axios? #14

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions