Umbrella issue for v1.0.0

[Khaledgarbaya]

Summary

This issue is an umbrella for the next release of axios. We might add more issues to the issues to fix list.

Pull Requests

• Babel & Webpack 3
• ESLint shared config (standard)
• Migrate nodeunit to jasmine
• Karma with Webpack config
• Adjust specs to work with new lib interface
• Substitute custom utils with lodash
• Move core / adapters to ESM
• Move helpers to ESM
• Remove lodash helpers from utils
• Move cancel module to ESM
• Change external surface

Issues to fix

Build system

• Use webpack 3 for bundling #1209
• [DOCS] Add instructions to configure Axios when used with Rollup #1259

Utils:

• Expose Util and Default methods from the Axios module #1298

Default instances / Config merge:

• Fixing #385 - instance.defaults changes global object #533
• seperate Axios instances are sharing data (Headers) #1239 - closed in favor of instance.defaults changes global object #385
• Headers should be compared with case ignored #1237
• Fix issues with global and instance defaults #812
• defaults.headers.common doesn't work but defaults.headers does #369
• cannot send post method in "request" function from Axios instance #723
• maybe undefined headers #498
• instance.defaults changes global object #385
• Don't send default header #382
• maybe Stack overflow error when overwriting a default agent option #370
• defaults.headers.common doesn't work but defaults.headers does #369
• Headers malformed - identical Postman/Fetch request succeeds #809
• consider export default configs? #688
• I set withCredentials is true, but cross-site requests failed. I can't find why... #587
• Remove axios.all and axios.spread #1042

Proxy:

• Need to bypass proxy #434
• Error with Proxy #1243
• how can I request use a socksv5 #636

Default adapter / Weird aliasing:

• Axios defaults to xhrAdapter (no stream) when http available #1284

Fixed due to old IE support removal:

• CORS did't work on IE，header did't sent #807
• ie9 axios post request return 415 #764

Other candidates for 1.0.0

Parse response based on responseType

• https://github.com/axios/axios/issues/811 (links 5 other issues with similar problem)
• Infer responseType from response headers? #793
• "responseType" param is unavailable #765
• No default value for responseType config option #724

After branches have been merged

• last verification of code integrety / bugfixes
• proper CHANGELOG.md
• migration hints in README.md
• Setup coverage via CodeCov
• Investigate necessity of banner usage (could be solved via BannerPlugin)
• Add a NPM script for running the TypeScript test
• Remove Bower distribution
• Documentation Docs Website #257

When alpha has been released

• mention potentially fixed issues to get some usage

[axe312ger]

as soon #1334 reaches master, we would close #1209

@Khaledgarbaya maybe add it to the umbrella including a [x] :)

[zcei]

Let's just mention them as fixed, but I wouldn't necessarily close them before it lands in master / the first alpha is released

[Khaledgarbaya]

Closing will happen later when we have the alpha release

[mividtim]

Also consider #1286 please (a PR is available here: #1287). Any idea on time-frame?

[zcei]

@mividtim those three lines should still be merge-able afterwards, the HTTP adapter won't change much.

For a timeline, there's nothing specific, but we have everything mentioned in Pull Requests ready. The branches will be updated one-by-one to the latest of release/1.0.0 when I open them as PRs. Then it's mainly about reviews - and for the last one (Change external surface) I expect some discussions (but the overall direction was discussed with Matt already).

After that, we should give people some time trying the alpha, which will be the most blocking part time-wise I guess.

[emilyemorehouse]

Do we have a way of tracking deprecations/breaking changes for 1.0.0?

[Khaledgarbaya]

@emilyemorehouse we'll add a CHANGELOG soon to the release/1.0.0 branch. @zcei has already something in place in his machine

[emilyemorehouse]

@Khaledgarbaya perfect. Wanted to make sure #1042 / #1234 can be tracked and deprecated properly. Thanks!

[zcei]

Ah there are even issues for that - thanks for pointing out. @Khaledgarbaya can add them to the list of issues.

[jcrben]

Can we agree that no (or extremely limited) breaking changes will be made in 1.0 and instead only deprecation warnings will be added? Then the code can be removed in 2.0.

This is how both Ember.js (example) and React (example) typically handle deprecations / removals.

[zcei]

As noted in the readme & how SemVer works, we could do a 0.18 with the deprecations, once we have a quite stable alpha for 1.0, and know exactly which implications will happen.
I personally don't see the value in losing the "symbolic act" of a v1.0 to only add deprecations.

Everything that we're planning to get rid of can be achieved today, expect for a more deterministic global config (no mutation, changed defaults don't propagate to already created instances).

Any idea how we could track that people use defaults that have been added after an instance has been created? Then we could trigger a deprecation warning only for these use-cases. And already provide the method to change defaults instead of the axios.defaults assignments.

[jcrben]

The 0 major version rule for semver catches some people off-guards, but 0.18 sounds OK - I'm just hoping can run the new stuff and the old stuff at the same time for a version. Then introducing deprecations along the way in 1.0 and removed in 2.0...

As far as tracking assignment to global defaults (https://github.com/axios/axios/tree/14057dc0bd9811a9fda773588f66de9f4aa0f617#global-axios-defaults), maybe a setter with defineProperty() or a proxy?

[zcei]

Proxy was my first thought as well, but might be hard to bring to older versions of browsers. (Polyfills / transpilations could increase bundle size to an unknown extend).
defineProperty setter sounds good, but then we can only give a generic deprecation, that one should use <insertYetToBeDefinedMethodNameHere> instead of mutating - doesn't fix the case of warnings for using modified defaults in an instance that was created before.

[mividtim]

@jcrben @zcei I've run into a similar situation in a separate, logging project before (global configuration that can be updated at runtime), and discovered this pattern, which may be useful to you: https://stackoverflow.com/questions/40271823/es6-emitting-events-from-static-methods

Basically, new up a private static emitter = new EventEmitter() on the class, and all instances can then listen for it: AxiosInstance.emitter.on('configChanged') or something similar. The risk here, of course, is cleanup. If all instances have a reference to a static event emitter, and the emitter never loses scope, none of the instances will ever be cleaned up. It's a conundrum.

[darren128]

@zcei #1298 looks like it's checked off, but the utils aren't actually being exported from the module. Is this in the plans?

[emilyemorehouse]

@darren128 is this what you're looking for? check out the current utils, there are methods exported: https://github.com/axios/axios/blob/release/1.0.0/lib/utils.js

edit: by 'current' i mean in the 1.0.0 branch

[zcei]

The module doesn't re-export the utils, you'd need to require/import into the actual files. We can think about a top-level file that re-exports them, so you don't need to tap into dist.

Wondering whether the use-case of #1298 could be solved with interceptors or adding another request/response transformer. The config accepts an array, so you can utilize the default and your custom processing on top.

[darren128]

We decided to use the interceptor to solve the issue outlined in #1298. But we are now using a copy / pasted version of the is* utils to determine what to / not to batch. For example, we are not batching file uploads. We just need to determine this before we send the batch off to axios, thus why an interceptor doesn't work for this case.

[danieladams456]

Would #959 be close enough for the 1.0.0 release? It would help when developing within a corporate network.

[mjhenkes]

Just checking in, Are there still plans to release a 1.0.0 of axios?

[axe312ger]

Alright, after working on this 2 years ago and the situation overall not changing:

I drop out of working further on axios.

This lib is mostly needed for enterprises to get requests running through their in-house proxies or support very old browsers. (At least that was my experience when maintaining libs depending on axios)

These companies should take over and/or pay further development of axios. The whole issue queue is packed with people complaining instead of fixing, or forking and rereleasing. This is open source, if you need it so much, take the time, the money or find smb doing it for u.

Everybody else not needing the exotic axios features, might just go with node-fetch, fetch and all the other, way less monolithic and smaller options to do a HTTP request in 2019

Docs: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Support: https://caniuse.com/#feat=fetch
Polyfill: https://github.com/developit/unfetch
Node: https://www.npmjs.com/package/node-fetch

[axe312ger]

Even unstarred the repo. Hopefully never bloating my projects with it again 😁

Wtf there are 1,485,321 projects using this and nobody feels responsible or the real need to fix this 😅

[levrik]

@axe312ger no enterprise here!
mainly using axios because of default configuration and interceptors.
I'm fine with the current version of axios, so why should I stop using it?

[ThiefMaster]

@axe312ger you sound a bit salty... reasons to not use fetch directly:

• no nice api to turn an object into a query string
• no interceptors (very convenient to make the user login again and then just continue whatever request failed due to an expired session)
• nicer API (getting json quickly without two awaits)

[schmod]

More conversation over in #2265.

If we aren't making any progress on these major changes, that's fine – let's just bump our current version to 1.0.0, and release these changes as a 2.x branch when they're ready. The 0.18 branch is one of the most heavily-used and well-tested pieces of software in the JavaScript ecosystem. A lack of activity isn't necessarily a bad thing -- it means stability! Let's just formalize the status-quo and slap the 1.0.0 designation onto the current release.

[43081j]

Just came across this randomly so here's an opinion:

This issue is 2 years old almost, you have almost certainly reached the dangling-branch/tech debt point where you should probably throw much of this away and do a better, more modern v1. Things have changed since you opened this.

For example, since you made your now-dated v1 branch, all browsers and node support ESM. you have no reason to be still writing commonjs for what is aimed at browsers. Your branch is so old it is only going to hold you back from modernising your already aged codebase.

IMO you should make v1 in ESM and have a rollup (tree-shaking enabled) bundle for older browsers (all those enterprise users using axios).

Similarly, a move to lodash seems like a step backwards. Most of what you're pulling out of lodash exists in the platform now or is at most one line of extra code (you even pull in a trim...)

[jasonsaayman]

HI all, thanks for the work done on here but for now I am going to close this issue.

I think that we first need to gain stability in Axios and a v1.0.0 is probably a bit away. I am hoping it would be an overall of parts of the API and code base and include much needed modernisation.

For now our main goal should be to present a v0.20.0 to the community that will mend all instability as well as features that break from version to version in Axios and then start working on new features from there.

Thank you everyone that was involved here but for now I am going to close this and will open a new project for a v1.0.0 as soon as possible.