Repository navigation
Version update from 2.9.5 to 2.11.0 broke the build for IE11 #1278
Description
Activity
Same problem here, it is also caused by the use of es6 features :
https://github.com/webpack/webpack-dev-server/blob/v2.11.0/client-src/default/index.js#L68Unless your build transpile the dependencies it breaks.
I think 2.9.7 is the last version that works in IE11, because 2.10.0 updated strip-ansi from v3 to v4 which introduced ES2015 syntax. 00e8500#diff-b9cfc7f2cdf78a7f4b91a753d10865a2L67
Reacted by Cecile Muller and Patrick MowrerSo we can't use anything > 2.9.7? Many of us can't just drop IE 11 support. Are there other options? Why is strip-ansi using fat arrow functions instead of being compiled to ES5?
@mikeaustin it's better to ask
strip-ansidevelopersstrip-ansi is one of Sindre Sorhus' packages. As far as I can tell, he's been modernizing his modules, dropping support for older Node.js versions. This means being able to use more modern syntax. However, people occasionally use his modules in the browser. Using the tooling of today, such as webpack, it is not common to run your node_modules through Babel. So npm packages end up more or less as-is in the bundled code for browsers. There's a question about shipping transpiled versions of the modules on Sindre's AMA: sindresorhus/ama#446. His response is basically that the problem should be solved by tools such as webpack and Babel. Which is fair. And work is being done on running node_modules through Babel: react/create-react-app#3776
Until the then, though, I think it would make sense if webpack-dev-server works in IE11 out of the box. Everything else would be a breaking change (and should bump to 3.0.0).
My guess is that this was just an oversight. The commit I mentioned, commit 00e8500, has the commit message "updating deps and patching as necessary". In other words, one of those routine "let's update all the dependencies" type of thing we all do every once in a while in our projects. I think strip-ansi was updated without thinking about that it would end up in the browser.
I would suggest going back to strip-ansi@3. Looking at the commit log for strip-ansi, basically the only change between version 3 and 4 was requiring Node.js 4+ and using modern syntax. So we wouldn't miss out on anything.
It was also mentioned that webpack-dev-server's own source code uses ES2015 syntax, for example in https://github.com/webpack/webpack-dev-server/blob/v2.11.0/client-src/default/index.js#L68. However, that line was added in #1242, which seem to indicate that the code is run through Babel before shipping, so it should not be a problem.
Edit: Looks like other people made the same conclusion in #1273.
Reacted by ilana beer, Luke Robinson, Zoltán Bedi, Jirka Pinkas, Yacine Zalouani, Pedro Duarte and Mike AustinIs pinning the strip-ansi a solution at the moment? Or should we also just transpile out this code by including strip-ansi in the babel-loader process.
Pinning strip-ansi is definitely quickest quick-fix. Though I have to admit, I haven't tested for sure that strip-ansi contained the only syntax error in IE11. It could be that the parser will just get a little bit further to another syntax error in another updated dep. But I would guess not ;)
Published
webpack-dev-server@2.11.1with the fix, thanks again to @yyx990803!Reacted by Pedro Duarte, Djordje Ribac and CooperReacted by MaulikReacted by Simon Lydell, Heo, Mike Austin and CooperThanks, v2.11.1 works great! 🎉
Reacted by CooperI'm running into the same issue on 2.11.1 due to the ansi-regex file. If I convert the arrow function to a traditional function I can test locally.
'use strict'; module.exports = function() {//manually changed from () => const pattern = [ '[\\u001B\\u009B][[\\]()#;?]*(?:(?:(?:[a-zA-Z\\d]*(?:;[a-zA-Z\\d]*)*)?\\u0007)', '(?:(?:\\d{1,4}(?:;\\d{0,4})*)?[\\dA-PRZcf-ntqry=><~]))' ].join('|'); return new RegExp(pattern, 'g'); };But that is a manual change to the node_modules folder at: node_modules/ansi-regex/index.js
I'm experiencing this same issue again in webpack-dev-server@3.1.7
Reacted by w0q, Yaroslav Kuzyo, Jay Kim, Ciprian Mocanu, Joe Badaczewski and John Reynolds@TimvanScherpenzeel Did you manage to bypass this? I've been battling this for the last 2 days 😢
@nikini vuejs/vue-cli#1789 , maybe, it can help you.
I can confirm this is still an issue with version 3.1.14. Anybody have an alternative to developing with webpack in IE 11?
Update: I decided to move to
webpack-serveI can confirm this is still an issue with version 3.1.14. Anybody have an alternative to developing with Webpack in IE 11? Moving to
webpack-serveis not an option for me.@joe307bad did webpack-serve worked for you?
yarn add webpack-dev-server
Sorry for the lazy report, but I'm a tad busy to figure out what possibly causes this or provide an example project.
If someone could confirm this is broken for IE11 in general, thanks.
We tried update our webpack-dev-server from 2.9.5 to 2.11 and in IE11 it causes the following:
Expected Behavior
Actual Behavior
For Bugs; How can we reproduce the behavior?
For Features; What is the motivation and/or use-case for the feature?