Closed JustinBeckwith closed 6 years ago
hmmm, I'm not sure if this is a good decision, I mean for our case, we have users who stick with IE (we don't really control them, they are somewhere else around the world).
I think it'll be better to separate the IE support on a different module, so if others would need it, then we just have to install that module and plug it as a plugin
or adapter
.
Pasting in my comment from an unrelated PR:
the IE 9 build broke--seems like 10 and 11 are fine. However it seems worth noting that Microsoft has ended support for IE versions before 11 over 2 years ago. Would it be reasonable to drop IE 9, bump to 0.19, and note the change in the CHANGELOG?
It seems reasonable enough to ask those who target old, unsupported versions of IE to use old versions of axios.
If you need to support such an old version of IE without vendor support, you most likely have to stick with older versions of dependencies / do not even provide further development and ist just "stays as is".
For a viable ecosystem, I feel like we need to end support at some point. Even SSL has been deprecated in favor of TLS.
@sprlwrksAprilmintacpineda An adapter is unlikely to work, as newer syntax and behavior will eventually surround such adapter, making Axios incompatible with the targeted browsers of said adapter.
Maybe we can find a transpiler preset that would make the code work with IE <11, with the trade-off of increased bundle size? // cc @axe312ger
I am pretty sure it is possible to have some babel plugins to get it working with IE<11.
Did we identify which code is atm crashing IE9 and which workarounds for IE<11 are in the code? That would help a lot to judge the effort that needs to be done.
It seems to be in the config merging, which sounds to me like the semantics for object operations weren't the same for IE than for modern JS. The tests are failing with "got object but expected string" errors. Maybe some method isn't defined that leads to improper serialization.
The workarounds seem to be not that many:
https://github.com/axios/axios/search?q=ie&unscoped_q=ie https://github.com/axios/axios/search?q=internet+explorer&unscoped_q=internet+explorer https://github.com/axios/axios/search?utf8=%E2%9C%93&q=isOldIE&type= https://github.com/axios/axios/search?q=MSIE&unscoped_q=MSIE
Is there consensus here or anyone in a position to make a call on this one way or the other? I would be happy to do whatever I can to help bring this project back in a state where it's fit for publishing--whether that is removing IE 9 or booting up a VM with IE 9 on it to triage and fix the IE 9 issues.
I think my PR takes care of the IE8/9 workarounds for the published code, and there's just a few things in test code that could go away.
At the moment I'm in a position where in order to make use of some recent axios improvements I'd be forced to depend on a GitHub reference or publish a forked version, and I'd like to avoid those options if possible.
@Khaledgarbaya @axe312ger & me have been in a conversation with Matt (the author of the lib) about the future, where our - very ambitious - 1.0 plan came from. For that we agreed on dropping IE <11 support.
So I think even for a 0.x we could decide to already go for it. Better than keeping master blocked for ages, imho.
I'll make one more pass over the PR to remove any other old IE stuff--I'll consider IE 10 fair game to remove--and then ping you for feedback.
@RikkiGibson go for it 💪
So this is a little self serving, but I think we should consider dropping support for IE9. The data is interesting. I'm seeing a 0.6% browser market share for IE9.
What's neat about that data is that IE8 has twice the usage of IE9 🤷♂️ And IE10 has only 0.54% market share! I could make a reasonable argument for dropping both IE9 and IE10.
Of course, I'm only looking at this because I'd very much like to ship a new npm module with a few recently merged changes, and the IE9 tests are failing :)
What are folks thoughts? Does anyone feel strongly about the IE support matrix as it stands today?
@nickuraltsev @mzabriskie