webpack: Ensure webpack users don't unknowingly use uglify-es
We keep getting bug reports in the React repo that turn out to be uglify-es bugs. It seems that many people use uglify-es through webpack without realizing it’s been abandoned and is known to be buggy and produce incorrect code.
While I know you’re switching to terser in 5.x IMO this is not sufficient. Ideally it would be great if there was a way for users of webpack 4.x to:
- Easily opt into a “safe” minifier like
uglify-jsorterser, ideally with a one-line change - See a deprecation warning if they’re running
uglify-esencouraging to do the step above
Without a deprecation warning, it’s likely people will keep bumping into these bugs for a few more years.
Does this sound like something you would consider?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 44
- Comments: 24 (9 by maintainers)
Ok you’ve got me. Let’s switch to terser for webpack 4 and don’t care if it might be a breaking change…
If we could add an npm deprecation note to all 1.x versions of uglifyjs-webpack-plugin (which use uglify-es), it would be a little noisy, but I think that could help a lot.
Nobody is working on
uglify-es. It’s abandoned.terserresolved some of the bugs inuglify-es, but the more important part is that it’s being actively maintained.I think emitting a warning in the plugin makes most sense.
I’m trying to understand why suddenly everyone started switching to terser. I understand that this is supposed to be a drop-in replacement for uglify-es and, hence, a transparent change to most of us. However, for projects like CKEditor 5, it means updating and explaining the change to our users (we want to recommend the same setup which webpack uses by default so people are familiar with it).
My point is – I’m not against making such changes – I completely understand that to move forward we need to change things. What I’m trying to understand, though, is the background behind this decision. Is terser better than uglify-es only because it resolved some existing issues (which makes it a better choice at the moment)? Or did it ensure stable funding and we finally have a standard minifier for JS? I keep my 🤞 for the latter because such a critical tool for the entire JS ecosystem should be backed somehow.
BTW, before I found this ticket I thought that only webpack 5 will be switching to terser. Now, I understand that webpack 4 will do that too. But when? To be honest, it would be good if there was a bit more transparency in such cases.
terser, likeuglify-jsanduglify-esbefore it don’t receive any funding of any kind. It’s solely an unpaid volunteer effort. If you’re looking for some sort of guarantee of long term maintenance with this or any OSS packages, you are mistaken.This discussion is about changing the default minifier from an abandoned one to one that is maintained. Does
terserhave fewer bugs thanuglify-es? Most certainly. Isterserbug free? Of course not. If the webpack project thinks it will be better served by babel-minify, butternut, google closure or prepack - by all means go for it.Thanks for the clarification. Seeing the sudden adoption of terser, I hoped that it got some sustainable funding or other kind of support from some companies/organizations. I’m just worried that terser is being actively maintained for now, just like all other projects were at their time.
I can see that terser is currently maintained by @fabiosantoscode and @kzc – maybe you could shed some light on this, guys? It’s of mutual interest for all of us to secure the position of the JavaScript standard minifier. Perhaps we could help?
@evilebottnawi There’s no need to disparage
uglify-jsor its maintainer.@kzc
maintained, but very bad
The bug in question was in
reduce_funcsinuglify-es@3.3.9and is still present inwebpack@4by default. It is not related to theinlineoption which was partially disabled inuglifyjs-webpack-plugin@1.But this specific bug is immaterial. Dozens of bugs in
uglify-es@3.3.9have been fixed interser- including several bugs that still exist inuglify-js.