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

[creage]

• Operating System: Windows 10
• Node Version: 9.3.0
• NPM Version: 5.5.1
• webpack Version: 3.10.0
• webpack-dev-server Version: 2.10.0

• [x] This is a bug
• [ ] This is a modification request

Expected Behavior

Webpack-dev-server allows running my app in IE11

Actual Behavior

This code makes webpack based development impossible to run in IE11, as it fails with error SCRIPT1014: Invalid character, index.js (361,13)

For Bugs; How can we reproduce the behavior?

Start any basic example of webpack-dev-server in IE11

[shellscape]

@creage thanks for the report. this is a great opportunity for a first pull request. We'd happily review one.

[shellscape]

It would seem that #1242 introduced an incomplete compilation using babel. Rules need to be injected into the config around here https://github.com/webpack/webpack-dev-server/blob/master/lib/util/addDevServerEntrypoints.js#L20 to compile the client scripts in the bundle. Something like:

    const rule = {
      test: /\/client\/.*\.js$/,
      exclude: /(node_modules|bower_components)/,
      use: {
        loader: 'babel-loader',
        options: {
          presets: [
            ['env']
          ]
        }
      }
    };

That also means that the babel dependencies need to be moved to dependencies rather than devDeps.

[sebtoun]

I have the same issue using Firefox 38.4.0: injected client code is not transpiled to es5.
As a result firefox complains that let is a reserved keyword.

The faulty injected code resides in client/index.js.
I'm new to webpack and have not grasped its internals yet but there seems to be already some rules in client/webpack.config.js that handles this file and the transpiled file (index.bundle.js) is laying in the node_module/webpack-dev-server/client but this is not the file that is injected in my entry point.
I don't know what to do to fix and would appreciate any help...

[shellscape]

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

[sebtoun]

My client company has a very restrictive work environment upgrade policies, I have to support that exact firefox version. It is thus safer for me to develop on the exact same environment and not having livereload really bothers me. I use webpack-dev-server v2.7.1 in the meantime but will upgrade to latest when this is fixed.

Despite your comment, I still don't get why node_module/webpack-dev-server contains both client/index.js and client/index.bundle.js (As far as I understand, those are the same code : the source version and the transpiled version) and I can't find where the client/index.js version is used and why it is used in this version (not the transpiled one). Again, I don't really grasp how webpack-dev-server is working in its entirety.

[shellscape]

client/index.bundle.js is for folks that use inline: false and such. There are examples demonstrating that in the repo. If you search for "index.bundle.js" at the top, in this repo, you'll find the examples that use it.

[sebtoun]

Why not using client/index.bundle.js instead of client/index.js when using inline: true ? Aren't those two versions the same code before and after transpilation|minification ?

[shellscape]

Because you'd be importing a webpack bundle into a webpack bundle as a module. It's just bad practice.

[yyx990803]

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

[shellscape]

@yyx990803 disagree. it's a dev tool. babel is a dev tool. same arena, the cost comes with the changes that were made.

[yyx990803]

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.

[shellscape]

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

[yyx990803]

@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]

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

[acierto]

What is the problem to do a concatenation of that line instead of interpolation to avoid this issue for IE11?

[sebtoun]

The problem is more general than that line and IE11, it is an incompatibility between the whole client code (written with es6) and browsers that do not support all es6 features used.

[acierto]

That's true, but if you don't want to transpile your code with heavy weight tools, why not just keep then the code in es5?
This problem was introduced in v2.8.0 and fixed afterwards, but by some reason it was decided to break it again from the version v2.10.0.

From my point of you, the complains are quite reasonable. The current decision of introducing that problem just holding from updating to the latest version. Or forces to create yet another 600+ fork to fix that issue for ones who have a product with customers using IE.

[yyx990803]

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