Skip to content
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

Version update from 2.9.5 to 2.11.0 broke the build for IE11 #1278

Closed
1 of 2 tasks
badpunman opened this issue Jan 16, 2018 · 19 comments
Closed
1 of 2 tasks

Version update from 2.9.5 to 2.11.0 broke the build for IE11 #1278

badpunman opened this issue Jan 16, 2018 · 19 comments

Comments

@badpunman
Copy link

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:
image

  • 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
Copy link

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
Copy link

lydell commented Jan 17, 2018

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
Copy link

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
Copy link
Member

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

@lydell
Copy link

lydell commented Jan 17, 2018

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
Copy link

lydell commented Jan 18, 2018

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

@TheLarkInn
Copy link
Member

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
Copy link

lydell commented Jan 19, 2018

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
Copy link
Member

Published webpack-dev-server@2.11.1 with the fix, thanks again to @yyx990803!

@lydell
Copy link

lydell commented Jan 22, 2018

Thanks, v2.11.1 works great! 🎉

@jjacode
Copy link

jjacode commented May 31, 2018

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
Copy link

I'm experiencing this same issue again in webpack-dev-server@3.1.7

screen shot 2018-08-30 at 13 22 15

screen shot 2018-08-30 at 13 22 04

@nikini
Copy link

nikini commented Nov 13, 2018

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

@dbwcooper
Copy link

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

@joe307bad
Copy link

joe307bad commented Dec 27, 2018

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
Copy link

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
Copy link

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

@codingimages
Copy link

@joe307bad did webpack-serve worked for you?

@chotimonaom
Copy link

yarn add webpack-dev-server

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests