66655 2011-08-22 03:12:41 -0700 Web Inspector: [meta] compile front-end using closure compiler. 2014-12-12 14:10:15 -0800 1 1 1 Unclassified WebKit Web Inspector (Deprecated) 528+ (Nightly build) All All RESOLVED INVALID P2 Normal --- 66656 66670 0 pfeldman webkit-unassigned apavlov bweinstein efidler joepeck keishi loislo pfeldman pmuellr rik yurys oldest_to_newest 454513 0 pfeldman 2011-08-22 03:12:41 -0700 I've been experimenting with closure compiler and have found a number of errors in the front-end with its help. Now that closure compiler supports getters and setters, I think it is time to give it another try. Here is what needs to be done: 1. Implement a python script that either compiles front-end using java library or sends files to the closure compiler service 2. Start annotating "@constructor" and "@extends" as suggested at http://code.google.com/closure/compiler/docs/js-for-compiler.html 3. Slowly compile files one by one, eliminating dependencies as we go There are two potential problems as I see them: 1. We can't make compilation a build stage yet (either needs a java library or web service available) 2. Closure does not support "const". I think this is a fine price to pay given that we can annotate it with /** @const */ and migrate back once const hits the standard. Given the amount of effort I put into it vs the errors that I discovered, I think it is worth it. 454585 1 pmuellr 2011-08-22 07:21:31 -0700 Sounds great. I'd be interested in seeing the list of the problems it found, or just a generic list of them. Just curious what it CAN find. While we might not be able to make this a formal build stage yet, seems like we could somehow make it optional. Even just a separate script that you can run somehow. I'd prefer the Java approach, but that's mainly because I have Java installed on all my machines. 456066 2 pfeldman 2011-08-24 05:59:23 -0700 (In reply to comment #1) > Sounds great. > > I'd be interested in seeing the list of the problems it found, or just a generic list of them. Just curious what it CAN find. > - DOMAgent.js, was using undefined "node" (instead of this) in ::appropriateSelectorFor (was never running due to non-empty localName) SoftContextMenu.js was not passing event into the ::_discardMenu when going through _triggerAction (new) SourceFile.js was using sourceId instead of scriptId (that one got renamed) (was not yet used) > While we might not be able to make this a formal build stage yet, seems like we could somehow make it optional. Even just a separate script that you can run somehow. I'd prefer the Java approach, but that's mainly because I have Java installed on all my machines. Yep. There is a compile-front-end.sh in the inspector/ folder that you can run if you have Javas. 1055147 3 burg 2014-12-12 14:10:15 -0800 Closing as invalid, as this bug pertains to the old inspector UI and/or its tests. Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.