Version update from 2.9.5 to 2.11.0 broke the build for IE11

[badpunman]

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:

• Operating System: Windows 10
• Node Version: 6.9.1
• NPM Version: 3.10.8
• webpack Version: 3.10.0
• webpack-dev-server Version: 2.11.0

• This is a bug
• This is a modification request

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?

[pgn-vole]

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#L68

Unless your build transpile the dependencies it breaks.

[lydell]

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

[mikeaustin]

So 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?

[alexander-akait]

@mikeaustin it's better to ask strip-ansi developers

[lydell]

strip-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: facebook/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.

[lydell]

Just noticed there’s a PR for this: #1279. It runs node_modules code through Babel. Cool!

[TheLarkInn]

Is 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.

[lydell]

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 ;)

[SpaceK33z]

Published [email protected] with the fix, thanks again to @yyx990803!

[lydell]

Thanks, v2.11.1 works great! 🎉

[jjacode]

I'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

[TimvanScherpenzeel]

I'm experiencing this same issue again in [email protected]

[nikini]

@TimvanScherpenzeel Did you manage to bypass this? I've been battling this for the last 2 days 😢

[dbwcooper]

@nikini vuejs/vue-cli#1789 , maybe, it can help you.

[joe307bad]

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-serve

[dep-deprecated]

I 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-serve is not an option for me.

[joe307bad]

@dep it looks like this is slated to be fixed in 3.2
#1286

[codingimages]

@joe307bad did webpack-serve worked for you?

[chotimonaom]

yarn add webpack-dev-server