Repository navigation
Build succeeding with webpack fails with webpack-dev-server (Unexpected token) #1101
Description
Activity
@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.
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? 😉
Reacted by David Walton@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!
Reacted by David WaltonAs 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. ❤️
Reacted by Mark and David WaltonI 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.
Reacted by Christian Naths, Alex Banks, AndrzejT, Paul Dao Nhan Nguyen, Travis Lindsey, Aleksey Filippov, Руслан Мингазов, David Walton, Ievgenii Krevenets and Mykola Androsovychbut 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.
Reacted by David Walton, Ievgenii Krevenets, Mykola Androsovych, Lucas Brandt, IamTheHttp, Rafael Salguero Iturrios and Renato Francia CastilloI 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.jsfrom ES5 to ES6I 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?
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 😄
Reacted by Dipesh Acharya, Oscar Lodriguez, David Walton, eclipse_sv, yoowinsu, Lucas Brandt and Dmitry Poliyivets@Filip0 that could present a problem, depending on the setup. the current beta of uglifyjs-webpack-plugin supports
constandlet(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.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)/, },Reacted by Taufan Arsyad, Travis Lindsey, James Cross, Bruce, Shubham Kanodia, Emerson Thompson, abbr, Carlito Platanito, Burhan Mubarok, SCD and 25 moreReacted by Travis Lindsey, Emerson Thompson, Bruno Oliveira, Tyler Boyd, Nathan Lyle Black, Rodolfo Silva, David Walton, tejon-melero and conceptdeluxeReacted by Emerson Thompson, @nrei, Bruno Oliveira, Tyler Boyd, Bruno Henrique de Souza, Rodolfo Silva, tejon-melero, conceptdeluxe and Michael Ashton@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.
Reacted by David WaltonI rolled back to 2.7.1 and all was well:
npm uninstall webpack-dev-server npm install -D webpack-dev-server@2.7.1Reacted by Alex Banks, Dmitri Christopher, Alexander Mitelman, Tarvo R., Federico E. Morales, Richard Leap, Vitaliy Isikov, Erlend Vestad, Phillip Long, Todor and 24 moreReacted by David Walton, Vieko Franetovic, pcmquizon, Pedro H. Santiago, sssswwww, vguzev and Tanmay BhattReacted by Pedro H. Santiago, Belal Al Mazlom, sssswwww, vguzev, John Roa and Tanmay Bhatt- changed the title
[-]Build succeeding with webpack fails with webpack-dev-server[/-][+]Build succeeding with webpack fails with webpack-dev-server (Unexpected token)[/+]on Sep 23, 2017 - added a commit that references this issue
on Sep 23, 2017 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.
@tombarton see this comment a few comments ahead of yours. uglifyjs-webpack-plugin@beta is gonna be the way to go.
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.
- added 2 commits that reference this issue
on Oct 10, 2017 - added a commit that references this issue
on Oct 10, 2017 - added a commit that references this issue
on Oct 10, 2017 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?
@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.
Reacted by Maxim Karpov and David WaltonReacted by Olle Bröms@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
modefield), 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!
Reacted by Guillaume Bilodeau, Olle Bröms, Aurelio, Lucas Brandt, Carlos Quiroz and Anton Konovalov
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
How can we reproduce the behavior?
npm installdependenciesnpm list webpackand make sure webpack was installed at 3.6.0npm list webpack-dev-serverand make sure webpack-dev-server was installed at 2.8.0 or 2.8.1package.json. There are two relevant scripts:npm run buildbuilds production bundles using webpack (succeeds)npm startbuilds with webpack-dev-server using the same config asbuildscript but fails, unexpectedlyThe issue must have been introduced with webpack-dev-server 2.8.0. To validate
npm install webpack-dev-server@~2.7.0npm start(succeeds)Summary of workarounds from the discussion below