webpack-dev-server: IE11 fails to load with Invalid character error

@sebtoun that browser version is nearly 3 years old!. while the changes that @yyx990803 made in his PR should in theory support that browser… good lord download an update!

My previous comment contains the solution. Webpack needs to be told how to compile the client entries automatically added to the config. If I had more time I’d walk you through it. Big life change coming up so I’m crazy short on it right now.

@shellscape I don’t get your aggressiveness in all of this - I know you might have life stress, but as a maintainer myself I just have different perspectives on how the tradeoffs should be weighed. I tried to figure out a better solution after the first PR was rejected. I didn’t even get a chance to defend the 2nd PR before you locked it. I simply disagree with your proposed solution of including babel as direct dependencies, for the reasons I outlined above. We are all just trying to find reasonable solutions to fix the problem for the users, and sometimes that means we may disagree on how that should be done, but that doesn’t mean it’s ok to just give in to your emotions instead of debating the actual problems. If you are busy with your life, maybe it is indeed time you take a break and let someone else take care of this project.

@yyx990803 honestly guy. you pushed for your changes. the team caved to them. your changes broke a ton of implementations. I gave you the entirely reasonable fix I want to see (in multiple places) and now you’re gonna push back against that.

You carry a lot of weight in the community due to Vue. I get it. But I’m done. Perhaps someone more amicable to your way will pick up maintenance of the project. ✌ out.

@acierto my 1st PR was converting all the client code back to ES5, but it was rejected likely because the maintainers didn’t want to have to write ES5 only in one part of the codebase.

The break in 2.10 wasn’t intentional, it was a regression introduced by my 2nd PR which attempted to transpile the client-side code with babel, so that all client source code can remain ES2015. However the bundling setup was actually used only in live mode and caused CLI inline mode to use the raw ES2015 files.

This should be fixed properly in #1270 though.

Shipping babel-core + babel-loader + babel-preset-env as dependencies of webpack-dev-server is definitely worse than just importing the pre-built bundle.

What are the downsides of including a bundle in a bundle? If webpack can handle that properly, then the only issue is it being “bad practice”, which does not affect the user in anyway.

On the other hand, including the whole babel suite as dependencies means you are shipping ~30Mb of extra payload if the user doesn’t use babel, or uses an incompatible version of babel. This amounts to wasted bandwidth cost and installation time, and it compounds during CI jobs. This is a much more practical problem than having a bundle in a bundle.

See #1270, which avoids “bundle in a bundle” and “babel as dependency” at the same time.