Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does the UglifyJsPlugin affect other loaders? #283

Closed
jhnns opened this issue May 27, 2014 · 10 comments
Closed

Why does the UglifyJsPlugin affect other loaders? #283

jhnns opened this issue May 27, 2014 · 10 comments

Comments

@jhnns
Copy link
Member

jhnns commented May 27, 2014

That's more of a question than an issue.

I was wondering why optimize.minimize has been removed in favor of the UglifyJsPlugin? I prefer plugins over big configuration options, but it seems not logically to me that the UglifyJsPlugin switches all other loaders (even those which don't generate JS) into min-mode.

@jhnns jhnns added the question label May 27, 2014
@jhnns
Copy link
Member Author

jhnns commented Jun 4, 2014

No opinions? 😸

@sokra sokra added bug and removed question labels Jun 4, 2014
@sokra
Copy link
Member

sokra commented Jun 4, 2014

Indeed I have. This need to be changed. The UglifyJsPlugin should only use uglify-js.

There are four options I have in mind:

  • An option module.loader: { } which adds properties to the loader context.
  • A plugin LoaderContextPlugin(context) which adds properties to the loader context.
  • A plugin LoaderMinimizePlugin() or similar, which only sets minimize on the loader context.
  • A plugin LoaderOptionsPlugin(regExp, query/obj) which adds options a specific loaders via query.

The debug option would also be affected by this.

@jhnns
Copy link
Member Author

jhnns commented Jun 4, 2014

The debug option would also be affected by this.

Makes sense.

The LoaderOptionsPlugin(regExp, query/obj) sounds reasonable. But I think most of the time you'll want to minify just all modules. So maybe there should be a LoaderMinimizePlugin() which uses internally the LoaderOptionsPlugin()?

@gaearon
Copy link
Contributor

gaearon commented Jan 8, 2015

Wow, this is quite unexpected!

@jhnns
Copy link
Member Author

jhnns commented Feb 3, 2016

Lately, I was thinking about this again. This is still misleading for newcomers. Wouldn't it be better to remove all the minification stuff from the loaders?

I think the best solution would be to have different plugins for all the various web-compatible output files, like MinifyJS, MinifyCSS, MinifyHTML, MinifyImages that are applied on all files that are about to be emitted. However, the minification should happen before the hash calculation.

@sokra
Copy link
Member

sokra commented Feb 3, 2016

I think the best solution would be to have different plugins for all the various web-compatible output files, like MinifyJS, MinifyCSS, MinifyHTML, MinifyImages that are applied on all files that are about to be emitted. However, the minification should happen before the hash calculation.

That doesn't work for inlined files... i. e. CSS or HTML inlined into JS.

Btw. This was changed in webpack. UglifyJs now only minimized js. A LoaderOptionsPlugin allows to switch on minimizing for loaders.

@barroudjo
Copy link

I wholeheartedly agree with the issue, so it's great if this has been solved, but I haven't seen it for the stable (1.x.x) version. Has this only been solved for the beta version ?
And by the way the fact that activating UglyfyJsPlugin currently puts all loaders in minify mode should be documented somewhere.

@sokra
Copy link
Member

sokra commented Feb 19, 2016

only in the 2.x version. It's a breaking change which cannot be done on 1.x version.

@uMaxmaxmaximus
Copy link

uMaxmaxmaximus commented Nov 3, 2016

And the content "JS" in the name of the plugin, all knocked me up, and I spent about two days in order to understand what was going on. in your html template I use camelCase attributes, and they all converted to lowercase. how many headaches I experienced you can not imagine. in the dev version all works, in the prod version all stops working.

What generally uneducated programmer invented it? As if that is specially made to harm.(...

@jellyfish-tom
Copy link

jellyfish-tom commented Nov 17, 2016

It s kinda shame that even though it has JS in name, it forces all loaders into minimize option.
Another shame is that it is not pointed in red, bold font on webpack page, but rather hidden somewhere between code snippets.

Good point and kind of 'the answer' (?) when uglifyJS messes your production build (as it does in ours project) is that minification of css can be disabled using -minimize option on css-loader.

Described here:
https://github.com/webpack/css-loader#minification

It overwrites uglifyJS forceful minification mode and in our case, let production build work as should.
Your CSS will be minified, just bit less (in my case it was 300kb and with minification disabled in css-loader 400kb). Better this than crashing project.

Which points me to a thought:

  1. Without uglifyJS, without -minimize flag on cssLoader - css weights ~5MB. (minimize disabled and not forced by uglifyJS - CSS works)
  2. With uglifyJS, without -minimize flag on cssLoader - css weights 350kb (minimize enabled - some CSS not working, JS fully functional)
  3. With uglifyJS, with -minimize flag on cssLoader - css weights 400kb (minimize disabled - CSS works)

Does uglifyJS minimize it twice or something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants