changcheng / wro4j

Automatically exported from code.google.com/p/wro4j
0 stars 0 forks source link

Add options to the uglifyJs processor or an uglifyJsAdvanced processor #443

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Currently the uglifyJs processor minifies JavaScript a lot less efficient, than 
it could. For example variable and function names are not mangled. Eventhough 
some of the possible optimizations might cause problems with certain JavaScript 
code most of them are quite safe.

It would be nice to have a chance of configuring certain of those options for 
the execution.

Furthermore the default configuration/behaviour of uglifyJs should be identical 
to the one documented on the project page, for the nodejs command line version. 
Maybe a second processor should be created like uglifyJsAdvanced, which has 
those optimizations enabled, like it has been done with googleClosureAdvanced.

Original issue reported on code.google.com by jakob.we...@gmail.com on 21 May 2012 at 12:56

GoogleCodeExporter commented 9 years ago
Would it be enough to make the default version of the uglifyJs processor more 
efficient by enabling mangling? Or it would be better to keep default version 
as it is and provide a way to customize processor?

Original comment by alex.obj...@gmail.com on 21 May 2012 at 1:00

GoogleCodeExporter commented 9 years ago
Issue 213 has been merged into this issue.

Original comment by alex.obj...@gmail.com on 21 May 2012 at 1:00

GoogleCodeExporter commented 9 years ago
I think it would be enough to make the current processor behave like a default 
execution of the uglifyJs command line utility (with nodejs), as this is what 
is used in mostly any project I know.

Maybe the configuration, which is loaded if the original utility is called with 
the ´--unsafe´ argument could be made accessible using another processor like 
it is done with googles Closure Compiler. I think that would be a solution, 
which should work for 99% of the cases uglifyJs is used. 

A separate configuration wouldn't be necessary then, as this would cause 
further problems, like adapting all kinds of interfaces (direct api, maven, 
cli, ...)

Original comment by jakob.we...@gmail.com on 21 May 2012 at 4:20

GoogleCodeExporter commented 9 years ago
Can you point an example of default uglifyJS configurations? Thanks!

Original comment by alex.obj...@gmail.com on 21 May 2012 at 4:23

GoogleCodeExporter commented 9 years ago
Of course. The nodejs command line utility 
(https://github.com/mishoo/UglifyJS/blob/master/bin/uglifyjs) has a set of 
default options preconfigured. I have extracted the most important ones below, 
with a short explanation of what each of them does:

- consolidate: false:
   Consolidates null, Boolean, and String values. Known as aliasing in the Closure Compiler. Worsens the data compression ratio of gzip.

- mangle: true:
   Mangle names in local function scope. This is what most of todays minifiers do. Has no side effects, but reduces code size tremendously

- mangle_toplevel: false:
   Name mangling on the top function level. This might produce smaller code, but mostly breaks all code, by destroying exposed API. (This is one of the advanced optimizations googles closure compiler executes. It should not be enabled in most cases)

- no_mangle_functions: false:
   Only mangle variable names, not function names. This does not really make sense, therefore function mangling should be enabled, by default.

- squeeze: true:
   Apply multiple optimizations against the AST. This is a safe operation, but produces less readable code. It should be executed by default, as it minifies the given JavaScript even further without side effects.

- make_seqs: true:
   Transform sequential blocks into a single statement, to remove unnecessary curly braces. This should be safe and is therefore enabled by default.

- dead_code: true:
   Eliminate obviously dead code (eg. expressions after a return, ... )

- show_copyright: true:
   Do not eliminate the first comment found in the js file to keep the copyright and licensing information, while still removing all other comments to preserve space.

- unsafe: false:
   Execute certain advanced optimizations in order to reduce code size even more. In most cases those optimizations should work without a problem, but there are some cases, where they cause certain unwanted side effects. Therefore this option is off by default. (It would be great to have some uglifyJsUnsafe processor, which is identical to the default one, but with this option enabled)

- lift_vars: false:
   Apply certain transformations to variable declarations, like combining all var statements into one at the beginning of each function scope, and a lot of other stuff. This might cause problems in code, which does not adhere to certain coding guidelines, therefore it is disabled by default.

- quote_keys: false:
   Whether or not to quote keys of objects. The default is to only quote reserved words, but not every key. This is a safe and yet size optimized decision.

As described above those are the relevant default options of the nodejs 
uglifyJs command line util. The function ´squeeze_it`, which can be found in 
the before linked file does give a quite useful overview of how those options 
interfere with the minifying process. It should give some hints on how to 
execute a mostly identical process within wro4j,

Original comment by jakob.we...@gmail.com on 21 May 2012 at 4:51

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 24 May 2012 at 9:19

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 25 May 2012 at 2:58

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 25 May 2012 at 2:59

GoogleCodeExporter commented 9 years ago
Now uglifyJs has a new method:
protected String createOptionsAsJson() throws IOException

which is responsible for providing the options for uglifyJs engine. The default 
options were changed according to comments from this issue. 

The code is available in branch 1.4.x

Original comment by alex.obj...@gmail.com on 29 May 2012 at 11:37

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 29 May 2012 at 11:37