HoriSun / closure-compiler

Automatically exported from code.google.com/p/closure-compiler
0 stars 0 forks source link

In SIMPLE mode, skip optimization that change, add or remove name in scopes containing with or eval() #602

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
eval() is EVIL :-), I know, but many "old" scripts still uses this construct. 
Issue with eval() and Closure Compiler is well-known. This code e.g.

var node = getNode();
eval('myHandler(node)');

will not wotk after optimization because the variable 'node' gets optimized (is 
shorten) and the string 'myHandler(node)' stays unchanged. Constructs like

eval('a.' + b)

are problematic as well. Sure, writing a[b] is better, but we can not do that 
for third-party libraries. I propose to use the same approach applied by 
UglifyJS 
http://badassjs.com/post/971960912/uglifyjs-a-fast-new-javascript-compressor-for
-node-js The good approach is:

"If eval() or with{} are used in some scope, then all variables in that scope 
and any variables in the parent scopes will remain unmangled, and any 
references to such variables remain unmangled as well."

I really like that. What do you think?

Original issue reported on code.google.com by ovarak...@googlemail.com on 18 Nov 2011 at 2:59

GoogleCodeExporter commented 9 years ago
This is what YUI does. It is very doable in simple mode.  The approach goes 
something like this:
- tag scopes containing eval and with
- modify all passes used in that may introduce or remove names, or cause 
renaming to skip scopes so tagged (aka a ScopeSkippingCallback).

Someone just needs to be motivated to do it.

Original comment by concavel...@gmail.com on 18 Nov 2011 at 4:28

GoogleCodeExporter commented 9 years ago
That's a discussion that comes up very often.

You are right. The general problem with EVAL is hard and is easily proven 
uncomputable. My previous intern Fadi tried applied Regular Expression to 
tackle it but had very little success in the static compiler.

I am sort of against this type of special casing (although I can be convinced 
see below). It creates inconsistent cases where advance mode would work with 
eval in some situation and some not instead of the "oh you used eval besides 
json and your code will probably break" rule.

Let me clarify what John meant by motivated: 

http://code.google.com/p/closure-compiler/wiki/FAQ#How_do_I_submit_a_feature_req
uest_for_a_new_type_of_optimization

Original comment by acle...@google.com on 18 Nov 2011 at 10:09

GoogleCodeExporter commented 9 years ago

Original comment by concavel...@gmail.com on 23 Nov 2011 at 10:05

GoogleCodeExporter commented 9 years ago
That would be nice to skip this optimization. The compression rate will be 
almost the same because eval() cases are rare cases. In my web projects I have 
probably 2-4 occurrences of eval() for 100 JS files. Just one occurrence breaks 
the entire web project because compiler optimizes it. So, skipping of this 
optimization in SIMPLE mode doesn't hurt and is a good approach IMHO.

Thanks a lot in advance for your effort.

BTW, I have wrote a new Maven plugin by using of Google Closure Compiler (docu 
is in progress): 
http://code.google.com/p/primefaces-extensions/wiki/http://code.google.com/p/pri
mefaces-extensions/wiki/GettingStartedClosureCompiler   

Original comment by ovarak...@googlemail.com on 23 Nov 2011 at 10:18

GoogleCodeExporter commented 9 years ago
Issue tracking has been migrated to github. Please make any further comments on 
this issue through https://github.com/google/closure-compiler/issues

Original comment by blic...@google.com on 1 May 2014 at 6:31

GoogleCodeExporter commented 9 years ago

Original comment by blic...@google.com on 1 May 2014 at 6:34