Backwards compatibility (es6)
See original GitHub issueHey, I just wanted to comment to start a discussion on backwards compatibility and what the best approach would be. We recently upgraded to the version that was refactored to ES6 and this broke Internet Explorer because they obviously don’t work with it.
Do you think you could ship a compiled version of your library in npm, or do you prefer we compile it on our end? For now we’ve special cased it:
include: [
path.resolve(__dirname, 'static/js'),
path.resolve(__dirname, 'node_modules/gettext-parser'),
],
but I think its more common to ship a web ready version that doesn’t require processing
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Hesitant to learn ES6 due to the backwards compatibility issue
"Many ES6 features are not backward compatible and will only work in an ES6 JS engine. If your code runs in a browser,...
Read more >2. FAQ: ECMAScript 6 - Exploring JS
How exactly ES6 stays completely backward-compatible is explained in the chapter on “One JavaScript”. 2.4 Does it still make sense to learn ECMAScript...
Read more >Understanding JavaScript Backward Compatibility And The ...
When I started reading about the new version of JavaScript (ES6 or ES2015) I was conflicted about how adding new keywords to the...
Read more >JS compatibility - Medium
Backwards-compatibility means that a JS environment supporting a given specification should be able to run a program compatible with any past or ...
Read more >Backwards & Forwards Compatibility in JavaScript
Backwards Compatibility. JavaScript is backwards-compatible. This means that once something is accepted as valid JS, there will not be a future ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thank you for bringing this up. I didn’t expect the need for an ES5 version as I (erroneously) assumed there wouldn’t be much browser usage for this library. I’ll add a build step and release 4.1.0 soon.
I’m going to return on my initial answer. An ES5 version is probably not worth the (small) maintenance burden. IE usage is likely insignificant. And you have a rather ok solution with compiling it yourself. Additionally, you can also pin to version 3.x as version 4 (currently) doesn’t really offer anything new.
Feel free to disagree though (now or in the future). Always open for discussion.