Bug 66655
| Summary: | Web Inspector: [meta] compile front-end using closure compiler. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Pavel Feldman <pfeldman> |
| Component: | Web Inspector (Deprecated) | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | apavlov, bweinstein, efidler, joepeck, keishi, loislo, pfeldman, pmuellr, rik, yurys |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | 66656 | ||
| Bug Blocks: | 66670 | ||
Pavel Feldman
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Patrick Mueller
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.
Pavel Feldman
(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.
Brian Burg
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.