Ignoring warnings from third party libraries - not working

657 views
Skip to first unread message

sagar...@gmail.com

unread,
Apr 23, 2014, 3:35:00 PM4/23/14
to closure-comp...@googlegroups.com
Hi Guys,

We are using the latest build of closure compiler [7th April 2014]. We also happen to use some 3rd party javascript libraries, for which the closure compiler gives a warning and we want to ignore them.

For this I tried the warning white-list option, but it doesn't seem to work. Below are the warnings from 3rd part libraries that we get 

java -jar lib/compiler.jar --js toMin.js --js_output_file ./src/main/static/webapp/js/min.js


toMin.js:490: WARNING - Type annotations are not allowed here. Are you missing parentheses?
      var arr = /**@type {Array.<number|string|boolean>}*/this.buffer_;
^

toMin.js:2944: WARNING - Suspicious code. The result of the 'getprop' operator is not being used.
  arr[ preferredDoc.childNodes.length ].nodeType;
  ^

toMin.js:4103: WARNING - Suspicious code. This code lacks side-effects. Is there a bug?
      if ( elem.parentNode ) {
      ^

toMin.js:4104: WARNING - Suspicious code. The result of the 'getprop' operator is not being used.
        elem.parentNode.selectedIndex;
        ^

toMin.js:9288: WARNING - Suspicious code. This code lacks side-effects. Is there a bug?
      if ( parent && parent.parentNode ) {
      ^

toMin.js:9289: WARNING - Suspicious code. The result of the 'getprop' operator is not being used.
        parent.parentNode.selectedIndex;
        ^

toMin.js:16037: WARNING - If this if/for/while really shouldnt have a body, use {}
        if (self.messageCallback && $.isFunction(self.messageCallback));
                                                                       ^

toMin.js:16121: WARNING - unreachable code
      return true;


I created a white-list file of warnings, based on the above format

toMin.js:490 Type annotations are not allowed here. Are you missing parentheses?
toMin.js:2944 Suspicious code. The result of the 'getprop' operator is not being used.
toMin.js:4103 Suspicious code. This code lacks side-effects. Is there a bug?
toMin.js:4104 Suspicious code. The result of the 'getprop' operator is not being used.
toMin.js:9288 Suspicious code. This code lacks side-effects. Is there a bug?
toMin.js:9289 Suspicious code. The result of the 'getprop' operator is not being used.
toMin.js:16037 If this if/for/while really shouldnt have a body, use {}
toMin.js:16121 unreachable code

I re-ran with the white-list option, but it didn't seem to like it 

java -jar lib/compiler.jar --warnings_whitelist_file closure_third_party_warning_whitelist --js toMin.js --js_output_file ./src/main/static/webapp/js/min.js

Can someone let me know what am I missing here?

The warning_level QUIET option works but we don't want to ignore warnings in our own code and only third party code.

Sagar

Dimitris Vardoulakis

unread,
Apr 23, 2014, 5:12:39 PM4/23/14
to closure-comp...@googlegroups.com
(I haven't tried whitelists before, so I'm not totally sure that the following is correct.)

My understanding is that you can use whitelists to demote errors to warnings, but you can't use it to make warnings disappear. See:

The file format you're using is correct. The hack to accompilish what you want is:

java -jar build/compiler.jar --jscomp_error=checkTypes --warnings_whitelist_file=pathToFile --compilation_level ADVANCED_OPTIMIZATIONS --js pathToFile 2>&1 | grep -A 2 ERROR

Basically, tells the compiler to report type issues as errors, then the whitelist demotes the issues in the file to warnings, and then you grep for ERROR to only see the ones that weren't demoted.




--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Dimitris

Sagar Mehta

unread,
Apr 23, 2014, 6:41:18 PM4/23/14
to closure-comp...@googlegroups.com
Hi Dimitris,

Thanks for your prompt reply!!

This looks like a decent hack although we don't want to ignore checkType issues in our own code. And also looks like I might have to beef up the --jscomp_error list to add more types to cover other areas.

I think the help is a bit mis-leading because it says something like 

--warnings_whitelist_file VAL          : A file containing warnings to
                                          suppress. Each line should be of the
                                          form
                                          <file-name>:<line-number>?  <warning-d
                                          escription>

The impression from this is whatever warnings are there in the white-list file will be suppressed and this is exactly what we want.

We would really appreciate if the option worked as advertised and a fix was released in the next release of the compiler. This feature also makes sense since a lot of time you use 3rd party codes like jquery et al and you don't really want to spend time fixing issues in some other library especially if they are warning level.

Is there a way for me to make a bug/feature request for this?

Best,
Sagar
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Dimitris

Dimitris Vardoulakis

unread,
Apr 23, 2014, 6:50:28 PM4/23/14
to closure-comp...@googlegroups.com
It's unlikely that the behavior will change. The code that I linked implies that the decision to not suppress completely is intentional. The reason is that people use scripts to generate their whitelists automatically, and these scripts scrape the compiler output, so all warnings should be there.

But yes, the doc is misleading and we should change it to reflect what actually happens.


On Wed, Apr 23, 2014 at 3:41 PM, Sagar Mehta <sagar...@gmail.com> wrote:
Hi Dimitris,

Thanks for your prompt reply!!

This looks like a decent hack although we don't want to ignore checkType issues in our own code.

With the way I suggested, you don't miss issues in your own code. By promoting all type warnings to errors and then demoting only the ones in the whitelist and greping, you see exactly the ones you need.



 
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Dimitris

Sagar Mehta

unread,
Apr 23, 2014, 6:59:55 PM4/23/14
to closure-comp...@googlegroups.com
yeah all warnings should be there by default and all the scraping and compiler output parsing scripts work fine - so far so good.

However if an option is explicitly passed to ignore certain warnings in the 3rd party javascripts that I'm compiling, it should ignore them. Promoting warnings to errors and then grepping stuff out sounds pretty hacky to me.

No worries we will deal with it for now and thanks for you help!!

Sagar
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Dimitris

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Dimitris
Reply all
Reply to author
Forward
0 new messages