Axios next

[jasonsaayman]

Over the next few months I will be working on a new version of Axios, a v1 release bringing a vast amount of modernisations and bringing the library up to date with modern JS practices.

I would like people to please add any suggestions they have to this mega thread for discussion.

During this period I will also start closing any issues/pull requests that are related to future proposals or new features that are not backward compatible.

[jasonsaayman]

See history at #4209

[cgarrovillo]

Ill start off.

1. An adapter API like you mentioned here, which was part of discussing using undici as an adapter.
2. Retryables, Like how axios-retry adds this functionality

In all of this, it would be nice to see consistency across package namings, like how eslint configs have to prefixed with eslint-config, or homebridge with -homebridge etc. Minor picky thing, but I think it increases cohesiveness of axios as a module and the community behind it.

[cgarrovillo]

Oh and a pretty major one, type declarations for TypeScript.

[jasonsaayman]

Yes type declarations is something I will really be working on as it is a point of much contention and normally a breaking change.

[jasonsaayman]

I would like to make axios the base, as mentioned before and then publish modules (interceptors, transforms etc). This would allow the scope of axios to increase vastly in time. It also would largely foster the community adding to axios as there would be an easy way to collaborate without a large learning overhead.

Ideally a base module would exist as a template repo from which new modules can be made, in this we will enforce our code style etc.

[yulodl]

fetch based adapter and native abortion on client side

[rekmarks]

+1 for the fetch adapter.

@jasonsaayman, do you have any old tickets that could help third parties asses how big of an effort the fetch adapter would be?

[cgarrovillo]

We almost need a laundry-list type of thing going. Ultimately not sure on what the foundation would look like since I'm assuming we want to make it easy to build adapters for it.

A good example is react-hook-form's ability to add validation libraries as their "adapters"

[jasonsaayman]

This is where I would like to go with this, a simple base axios and then authored adapters, transforms and plugins that can be used.

[cgarrovillo]

What's the next step in the process? and how do we move forward from this ideas discussion?

[jasonsaayman]

I think we will need to create a project and then start adding any issues in the old issues that are related to this version to that project. I will add a branch soon to start work in.

[reichhartd]

@jasonsaayman Have you made a decision regarding TypeScript migration?
I'm referring to #4209 (comment), #4209 (comment) and #4209 (comment).
Once a decision is made, I'm happy to take over the migration and submit a PR.

[jasonsaayman]

@reichhartd sure, I am going to invite you to the slack channel asap and we can do some discussion, please email me so I can add you

[reichhartd]

@jasonsaayman Sent you an email 👍

[jasonsaayman]

Thanks will get to it asap

[megahertz]

It would be very nice to keep the library as tiny as possible when dependencies like form-data are installed manually. But sometimes it's hard to find the best balance between size and usability.

[DigitalBrainJS]

This is relevant only for the client build, but it does not have any dependencies.

[megahertz]

I mean node.js environment where form-data is installed together with axios even if the application doesn't need multipart/form-data requests

[jimmywarting]

Some few standard web things that should be supported:

• Post/Get Blob/Files
• Post spec compatible FormData (NodeJS have that built in now...)
• Use fetch instead of XMLHttpRequest to support cloudflare workers and service worker. (NodeJS have fetch built in now)
• Ditch CancelToken in fav of AbortSignal
• Maybe remove all XMLHttpRequest stuff all together and ditch IE support totally?
• Stop using Buffer and instead use Uint8Array
• normalize responseType: "arraybuffer" to actually return a ArrayBuffer and be consistent in browser and NodeJS and not giving a Buffer
• Maybe support Deno as well?
• ESM syntax

[chriscalo]

+1 for fetch. Or at least provide a built-in adapter like @vespaiach/axios-fetch-adapter so this doesn't have to happen in user space.

[jasonsaayman]

This is a good list thanks for that

[chriscalo]

Should Axios support being passed standard Request objects and returning standard Response objects?

[DigitalBrainJS]

IMHO, if Axios moves to a fetch API with Response and Request objects, the existence of this project will become pretty pointless. Users consider one promise per request and cross-platform to be the most important advantages of Axios, but if we do this, we will literally get another fetch library with interceptors. Such projects already exist. Axios should find its own way to simplify the user experience in order to make their day-to-day work easier.

[jimmywarting]

there are several positive thing by using fetch instead of over XMLHttpRequest.

• Sticking with XMLHttpRequest won't make it work in service worker. Service worker only have the fetch
• Browsers can only stream content using the fetch api. something you can't do with xhr.
• using fetch means axios can work in Deno as well.
• using fetch also means that you do not have to deal with supporting Blob, Files, FormData, URLSearchParams yourself and having to transform or encode FormData yourself...
• NodeJS have now already shipped fetch api into nodejs core.

So it's simply just more easier to just use one adapter instead of having node:http, node:https, xhr and also a fetch adapter to make it work in service worker or cloudflare. it still much possible to have the same existing axios architecture on top of fetch.
Plus they work grate with the cache storage

[DigitalBrainJS]

This is only easy in an ideal world where you can use the latest Node build or browser, but in that case, you could use fetch directly or use some kind of fetch wrapper with interceptors from npm.
Supporting the new adapter and replacing the public Axios API are two different things. Axios is a cross-platform wrapper/facade for adapters with some helpers. Adding a fetch adapter is not a big deal, the challenge is to keep Axios cross-platform with the same API and give it flexibility and extensibility because there are actually more than 2 platforms already and there is no guarantee that in the future we won't want to support another new platform (#4349).
Also, using fetch without fallback to XMLHttpRequest&http means we are dropping support for rare mobile browsers, legacy browsers, Node older than v18, and proprietary platforms. So in practice, we will have to implement backward compatibility and support at least 3 adapters.