Web Inspector: implement JavaScript beautifier based on UglifyJS library
Created attachment 75143 [details] Patch.
Comment on attachment 75143 [details] Patch. We can't take this as includes code distributed under the ZLIB license, which is not one of the allowed licenses. It also seems odd to add another JS parser to the project, why not try and reuse the one in JSC?
*** This bug has been marked as a duplicate of bug 14469 ***
(In reply to comment #2) > (From update of attachment 75143 [details]) > We can't take this as includes code distributed under the ZLIB license, which is not one of the allowed licenses. It also seems odd to add another JS parser to the project, why not try and reuse the one in JSC? We are going to use JS parser for editing purposes, so we'll need a full-featured parser/formatter. It would be quite hard to implement it in native code and expose to front-end. Also, we'll need to implement this for both JSC and v8, which is not as nice as having a single JavaScript implementation.
> Also, we'll need to implement this for both JSC and v8, which is not as nice as having a single JavaScript implementation. I would describe the same situation differently: the WebKit project will need to maintain three distinct JS parsers, instead of two.
(In reply to comment #2) > (From update of attachment 75143 [details]) > We can't take this as includes code distributed under the ZLIB license, which is not one of the allowed licenses. It also seems odd to add another JS parser to the project, why not try and reuse the one in JSC? I do understand your point and I share it. However, I am not sure whether JSC's AST will be sufficient for our needs longer term. A thin String JSC::beautify(String) API is not sufficient for providing JavaScript outline (a classes / members view), so we need to expose AST. AST is a much broader interface and it'll be hard to abstract it well. But even AST might be not sufficient: we are currently thinking of introducing editing aspects into the inspector and hence we need a very good parser recovery. In general, most IDEs are using their own parsers with advanced recovery while working with code. In other words, if our needs were limited to beautification, we would definitely go for native parser reuse. But given our editing ambitions, we should probably use parser designed for our domain. We'll probably get in touch with uglify people for the BSD license to see if that is an option.