Webpack-dev-server: 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
• [x] 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? :wink:

[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. :heart:

[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 [email protected]

[tombarton]

Apologies, I'm very new to webpack and webpack-dev-server but I think I might have a super simple repo that replicates this issue:

https://github.com/tombarton/webpack-uglify-issue

npm install
node_modules/.bin/webpack-dev-server

Once again, I'm sorry if I waste anyone's time on a config issue.

[shellscape]

@tombarton see this comment a few comments ahead of yours. uglifyjs-webpack-plugin@beta is gonna be the way to go.

[shellscape]

Just updated the README with a Caveats section that outlines the thought, cause, and workaround for this issue. Please feel free to continue discussion, however.

[pastelsky]

This does seem like unpleasant limitation which makes it tough to test sites in browsers as recent as even Safari 9.

Given that it's not a breaking change with the core lib itself, but because of ES6 syntax, does it not make more sense to transpile this / write it in ES5?

Would you be willing to accept a PR for the same?

[asadighi]

@shellscape I highly encourage you to incorporate es2015 within your package:

https://www.npmjs.com/package/es2015-packages-best-practices-t

Even though It is all about semantics but I can argue this was a breaking change. I for one (on behalf of the corporation I work for) have pinned my package to 2.7.1 and I don't see that I can upgrade to newer versions anytime soon (per browser compatibility requirements) unless if you have es2015 enabled in your package.

[eteeselink]

@shellscape First off, thanks for your tremendous work. Maintaining a tool as popular and central as this must be a hard and thankless job.

I hope to convince you to answer "yes" to @pastelsky's question: Would you accept a PR that makes webpack-dev-server ES5 compatible again (either through a prepublish compile step or by hand-editing the code). Thing is, yes, Safari 9 and IE10 are "officially unsupported" but at the same time, they did not magically disappear from people's computers.

I hate IE as much as the next guy, but this change makes it even harder to keep things working there; not easier. If I read things right, I have two options:

• downgrade to 2.7.1 and hope I'll never need some webpack feature that depends on a newer version
• dev/debug/etc on IE/Safari without the devserver reload script - not the end of the world tbh, but a fair amount of setup and configuration that I'd rather not touch. Given Webpack's movement toward good low-config defaults (such as v4's new mode field), this feels like the wrong direction.

I bet I'm not the only Webpack user targeting browsers like IE10 and Safari 9. If Webpack and its devserver are tools meant to make the lives of developers easier, not harder, then wouldn't keeping ES5 compat be a no-brainer?

I'd be happy to contribute a PR that fixes this, if @pastelsky doesn't beat me to it. Particularly, I can't personally see a big downside to running the injected script through Babel prepublish. But maybe I'm missing something?

But I prefer to save the effort if you're on some holy war against old browsers and the devs that wish to support them :-)

Thanks!