-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enforce ES5 in all client files, fix usage in ES5 only browsers #1241
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1241 +/- ##
=======================================
Coverage 76.31% 76.31%
=======================================
Files 5 5
Lines 477 477
Branches 154 154
=======================================
Hits 364 364
Misses 113 113 Continue to review full report at Codecov.
|
@yyx990803 thanks for the PR, I do appreciate the effort. Unfortunately this isn't one we're going to be merging. It's a topic that's been discussed many times in the issues here. The readme outlines when this was done and what users needing to support unsupported platforms should do (use an older version). If a browser doesn't support |
This is extremely irresponsible and overly optimistic about the ES feature set being used around the globe. As I pointed out, UC Browser has 500 million downloads on Google Play which equates to millions of users worldwide. You are essentially shutting down all the developers working in those regions from being able to leverage To put it in more context, Using Node 4 as an analogy also doesn't fly - devs have the choice to upgrade their Node versions, but they don't necessarily have control over what browsers their users choose to use. I don't see any practical downside of using ES5 in the dev-server client code - JavaScript is always backwards compatible, so yes, "older platforms can be supported forever" in this case. |
I understand the argument, and as mentioned, this has been discussed at length in other issues. I would argue it's extremely irresponsible for a browser vendor to continue to distribute a product to 500 million users which is so far beyond modern standards, but there's not much I can say to that effect. These are the same arguments made when China was still predominately on IE6 not long ago. Vendors chose to move forward. At some point the line must be drawn. If users of WDS are stuck having to support very old (or very behind) browsers, they can use v2.7.1 or use workarounds such as this one. I also understand the weight your position in the two communities carries, and the water it typically moves. Unfortunately we have a difference of opinion. |
I still don't see a valid argument on why this should not be merged. Can you provide one such argument in prior discussions? |
I think what they mean is to force the browser and its users to improve, and the browser and its users are always easily turned into negative, backward... |
@shellscape I think this should be revisited since the ES5 compat is a minor change to the code base (mainly |
Front-end developers can chose Node.js version for themselves, but NOT browsers. Can't you simply babel your client side ES6 code to ES5? You can still move as fast as you wish without dropping anyone behind! |
A workaround exists for this issue. The webpack core team has taken up discussion of this. Please use the workaround in the meantime. Locking this thread before it goes bananas. |
What kind of change does this PR introduce?
bugfix
Did you add or update the
examples/
?No
Summary
There were prior issues regarding the client files, after being upgraded to ES6, not working properly in IE11 (#1084). However, the fix (c9d32f8) left
let
andconst
in the client codebase, which works in IE11, but not in other ES5 compliant browsers (IE<11, UC Browser on Android).Certain regions of the world, in particular China and developing countries, still has a large percentage of browsers that only support ES5 (UC Browser has over 500 million downloads on Google Play), so developers targeting customers in those countries still need to debug their applications in those browsers.
This PR ensures all client files are ES5 only (also enforces this via ESLint parser version).
Does this PR introduce a breaking change?
No.
Other information