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

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)/,
    },

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

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.

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 😄

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

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

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

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. ❤️

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

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

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? 😉