Build succeeding with webpack fails with webpack-dev-server (Unexpected token)

[about-code]

• Operating System: Ubuntu 16.04 LTS
• Node Version: 8.0.0
• NPM Version: 5.4.2
• webpack Version: 3.6.0
• webpack-dev-server Version: 2.8.0

• This is a feature request
• This is a bug

Expected Behavior

webpack-dev-server shouldn't break builds

Actual Behavior

Build succeeding with webpack fails with the same config with webpack-dev-server. Message

ERROR in theme.76a4a23d58ebccf23fb4.js from UglifyJs
Unexpected token: name (urlParts) [theme.76a4a23d58ebccf23fb4.js:1957,4]

How can we reproduce the behavior?

• clone or download this repo at version 1.0.0-alpha.6
• npm install dependencies
• npm list webpack and make sure webpack was installed at 3.6.0
• npm list webpack-dev-server and make sure webpack-dev-server was installed at 2.8.0 or 2.8.1
• Have a look at package.json. There are two relevant scripts:
  • npm run build builds production bundles using webpack (succeeds)
  • npm start builds with webpack-dev-server using the same config as build script but fails, unexpectedly

The issue must have been introduced with webpack-dev-server 2.8.0. To validate

• npm install webpack-dev-server@~2.7.0
• npm start (succeeds)

Summary of workarounds from the discussion below

• Downgrade to 2.7.1 (see duhalme)
• or install UglifyJS-Plugin separately (see shellscape)
• or temporarily remove UglifyJS-Plugin until webpack includes an es6-capable version
• or transpile webpack-dev-server (see Turncoat)

[shellscape]

@about-code we're going to need a much simpler repo to triage the issue on our end; the one you provided is quite complex for drilling down and nailing an edge case like this. that doesn't mean we don't encourage you to look into it further. this is almost certainly a config, loader/plugin, dependency, or environment issue over your way, as these kinds of edge cases tend to be. (if this would have been widespread there'd be pitchforks, torches, and angry mobs at the door). I'll leave this open in the event you, or anyone else, can find the cause and it's fixable.

[about-code]

I can try to create a less complex repro dropping some webpack plugins. However, did you even try above reproduction steps, at all? The issue can be reproducably narrowed down to some change in webpack-dev-server 2.8.0. Changeset for 2.8.0 is quite small. The error must be related to some contribution affecting code injected by webpack(-dev-server).

Removing the UglifyJS-Plugin makes the error go away, but of course that doesn't really fix the issue, I think.

if this would have been widespread there'd be pitchforks, torches, and angry mobs at the door

2.8.0 is only 4 days from now, where two of them have been weekend. Maybe its a bit early to qualify the issue as an edge case just because the mob has not yet arrived? 😉

[shellscape]

@about-code the mob shows up quite quickly on a project so widely-used, believe that. As a rule I tend not to dive into complex example repos because they're a really large time commitment. (that's why we ask for a simple repo right there in the issue template!) every collaborator and maintainer here volunteers their spare time when they can, so we try to work as efficiently as possible. With the influx of issues we get on a weekly basis, it's a necessity. When we say that things are edge cases, we speak from a basis of experience with the large amount of issues that get created here. These kinds of things are almost always edge cases. I personally can't recall the last time an issue like this didn't boil down to a config/loader issue, once the reporting user simplified their use-case and slowly added components back in. So the whole point of this is to say; that something is an edge case doesn't make it any less valid an issue, it only means that it's something not affecting a large group of users as yet.

I would disagree that the changeset between 2.7.1 and 2.8.2 is small, but the enthusiasm is awesome and you should totally deep dive this. It might make a great first contribution if you find the cause!

[about-code]

As a rule I tend not to dive into complex example repos because they're a really large time commitment.

I accept that and wouldn't expect you to dig into the nitty gritty of the repo in the first place - even not on Sunday, but you could have saved you some time by just reading the issue completely, before posting. I tried my best to list every single action to reproduce the issue which boils down to running a few npm commands on the repo to find out that its not a configuration problem. The fact that the same config works with webpack as well as webpack-dev-server v2.7.1 but not with 2.8.0 isn't a sign of misconfiguration on my side but a sign of a bug or breaking-change introduced with wds 2.8.0.

I would disagree that the changeset between 2.7.1 and 2.8.2 is small

but its a little smaller between 2.7.1 and 2.8.0.

It might make a great first contribution if you find the cause!

Believe me, I don't stop at posting issues. Wouldn't be my first contrib to the webpack org.

every collaborator and maintainer here volunteers their spare time when they can, so we try to work as efficiently as possible

I know and appreciate that. So do I. Therefore, this dispute aside I still whish you a nice Sunday. ❤️

[ThomasG77]

I encountered the same issue with one of my side project https://github.com/ThomasG77/mapboxgl-webpack and solved it locally doing the same way as @about-code (downgrading to 2.7.1)

git clone https://github.com/ThomasG77/mapboxgl-webpack.git && cd mapboxgl-webpack && git checkout webpack-dev-server-2.8
npm install
npm run build # Build directly with webpack with no problem
npm start # Fails with attached stack trace below

I'm not in hurry for a fix as I'm able to avoid the issue temporarily (and the release is too fresh :)) . I just posted to confirm I also ran into the same issue & to provide another code repo sample to reproduce.

[shellscape]

@about-code

but you could have saved you some time by just reading the issue completely, before posting

I really take exception to that. Perhaps the language chosen doesn't reflect the tone or message you were going for, but I find it really off-putting. Pushing a volunteer like that isn't a great way to go about seeking help.

[Filip0]

I have the same bug in my project and I believe the bug may be related to #1058. Been googling alot around this error and it appears to be related to uglify being unable to process ES6. The mentioned PR transforms client/index.js from ES5 to ES6

I haven't done a deep dive in the webpack code so not sure where the uglify process is being run. @shellscape do you have any idea?

[kucukkanat]

Is there a stable version anybody knows to prevent this ? I have had the same issue for 2 weeks now and about to be fired from my job 😄

[shellscape]

@Filip0 that could present a problem, depending on the setup. the current beta of uglifyjs-webpack-plugin supports const and let (which is what you're referring to as "being unable to process ES6"). The current stable version of that same plugin works with ES6, but requires an extra install step. Check out the Important! note in the Install section of the README on that link for the extra steps if using the stable version of uglifyjs-webpack-plugin.

[beckerei]

We had the same issue, and did a hotfix by transpiling webpack-dev-server as well.

{
      test: /\.js$/,
      use: [{ loader: 'babel-loader', options: { cacheDirectory: true } }],
      exclude: /node_modules(?!\/webpack-dev-server)/,
    },

[about-code]

@shellscape I didn't have the impression the issue was taken seriously but being disqualified as an edge-case and config-problem just a few minutes later without a real attempt to understand the problem. Not being taken seriously is when I become less motivated to remain polite. I didn't seek for help but wanted to provide help with a repo and a precise repro. That's more than simply asking you to solve my problems. I apologize if I was a little too offensive. Try to understand it as my way of being honest to you about my feelings. I guess we both have no interest in going on fighting over words. I don't want to push you because I honour your work. So If you're okay with it, let's just forget about it and try get the issue closed. I am going to investigate it either.

[ThomasG77]

I've tried @turncoat hotfix and it works with latest webpack-dev-server version e.g 2.8.2.

[duhaime]

I rolled back to 2.7.1 and all was well:

npm uninstall webpack-dev-server
npm install -D webpack-dev-server@2.7.1