Support for ES6 fields/decorators?

[Scott Wells]

Hi. I'm brand new here so apologies if I'm asking a question with an obvious answer. I have searched here and scoured the closure-compiler source code beforehand, but it's possible I'm just using the wrong terms.

I'd like to use the compiler to yield an AST that I can then use for an IDE-focused purpose, not as much for transpiling, etc. The particular dialect that I need to be able to support allows for ES6 fields, potentially with decorators, e.g.:

class MyClass {

    @decorator myField;

    ...

}

It doesn't appear that the closure-compiler parser allows that syntax, though, at least not given any of the compiler options I've specified. I'm hoping that I'm just missing some particular combination that does allow it.

For reference, the JavaScript scanner/parser in JetBrains IntelliJ IDEA Ultimate Edition (and WebStorm, etc.) tokenizes/parses "@decorator myField;" as (slightly simplified):

ES6FieldStatement

  ES6Decorator

    JsAt

    JsIdentifier

  ES6Field

    JsIdentifier

  JsSemicolon

Any insights you might have into how I might be able to configure closure-compiler parser to handle this properly--or perhaps just confirmation that it's definitely not (currently?) supported--is greatly appreciated.

Regards,

Scott

[zad0m]

Is a stupid syntax imho the manifestation of where the language has been taken by such useless group as tc39. JavaScript as a language was done in 2016 after Allen Wirfs-Brock left now it’s in the hands of the incompetent people who can’t create anything good but keep pushing new features for the mass of developers from the sectarian open source “community”

Sent from my iPhone

On 3 Nov 2020, at 19:49, Scott Wells <sc...@illuminatedcloud.com> wrote:

[Scott Wells]

Just to clarify, is the takeaway that the closure-compiler parser does not currently support such a syntax and cannot be configured to do so?

[zad0m]

I’m not a compiler representative sorry I’m just an angry developer who’s unhappy that a bunch of people have hijacked JS. Maybe it’s good that compiler doesn’t support it. You can decorate methods at runtime. Hell you can do anything at runtime with JS you just need to learn the basics of prototypes which is the strongest point of js that nobody knows about.

Check the protypes package https://artdeco.software/protypes/ and https://www.npmjs.com/package/protypes to do that. It’s basically a polyfill for decorators plus it has multiple inheritance. It’s compatible with closure too if you wish to purchase the source code it will raise no warnings. Pls email me to get a trial because the free version on npm doesn’t include decorators. I’ll give you access to full version  to evaluate if you email me. But then it’s not going to enable the @ syntax, it’s just a lib to decorate methods. Yeah sorry I confused you at first I just really really dislike tc39. Btw it’s run by a guy from Microsoft and they are trying to destroy js and make people switch to ts. 

Sent from my iPhone

On 3 Nov 2020, at 21:46, Scott Wells <sc...@illuminatedcloud.com> wrote:

[Scott Wells]

I certainly appreciate your perspective on this, but in my case I'm trying to provide IDE support for a dialect of ES6 that includes this particular language feature, so the parser I use would ideally support it. I'm not trying to transpile; I'm just trying to get as rich and accurate of an in-memory AST as possible for a source file against this particular dialect. I actually already have a "poor man's parser" that is about 95+% accurate in terms of grokking the type structure, and that's really all I need as I'm using the resulting information to provide (simple) code completion suggestions and to draw a structure view. It would be wonderful to have some form of type inference as well so I could provide more accurate code completions based on what's viable at the point of insertion, but that's a stretch goal.

It sounds like unless I want to pre-process the source before having closure-compiler parse it--likely by neutering these member variable declarations--it's probably not going to be a viable option for what I'm wanting to do. Not a big thing...I just thought I'd follow the investigation to its logical end in hopes that perhaps it was just some set of compiler options I wasn't setting properly.

Thanks for the info!

[zad0m]

I like how you use a simple parser for autocompletions. Type inference is what the compiler is capable of. And if you have a dialect of a language you’ll probably run into other features not supported by the compiler at some point, so you might as well look into its source code and debug it by running a java process against your input and seeing where it fails. Then you can see how the compiler builds its type skeleton, too, and to hot-compile your code on changed you’d want to use the lib instead of bin actually ... just 2 cents 

Sent from my iPhone

On 3 Nov 2020, at 22:49, Scott Wells <sc...@illuminatedcloud.com> wrote:

I certainly appreciate your perspective on this, but in my case I'm trying to provide IDE support for a dialect of ES6 that includes this particular language feature, so the parser I use would ideally support it. I'm not trying to transpile; I'm just trying to get as rich and accurate of an in-memory AST as possible for a source file against this particular dialect. I actually already have a "poor man's parser" that is about 95+% accurate in terms of grokking the type structure, and that's really all I need as I'm using the resulting information to provide (simple) code completion suggestions and to draw a structure view. It would be wonderful to have some form of type inference as well so I could provide more accurate code completions based on what's viable at the point of insertion, but that's a stretch goal.

--

---
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/b12b5fb0-5ee0-456f-98bc-41cbcfe48d1an%40googlegroups.com.

[Bradford Smith]

Hi Scott,

closure-compiler hasn't been updated to support class fields or decorators yet, so there's no way to get it to parse them for now.

The closure-compiler team aims to have support for a feature within a year after it becomes part of the officially released spec.

Fields and decorators aren't part of the 2020 version of the spec.

I expect that fields may well be in the 2021 version, but decorators are much further away from being standardized.

There's a very active community working on the proposal for decorators.

You can see the work being done on their GitHub repo and interact with them via the issues filed there if you're interested.

https://github.com/tc39/proposal-decorators

Best regards,

Bradford

[Scott Wells]

Thanks, Bradford. That's what I was hoping to learn. For a little additional context, my product is a plugin for the JetBrains family IDEs, both commercial and free (Community Edition). When my plugin is paired within a commercial IDE, the base IDE's own first-class JS parser is available to me, and it has full support for these features already; however, the free IDEs don't have any real first-class support for JS or CSS, so to provide a reasonable experience for my users I've implemented some of the IDE features for those languages myself. For earlier versions of JavaScript the original Rhino parser yields a nice AST, but when I have to parse this ES6 dialect that uses fields and decorators, obviously my options are more limited. As I mentioned previously, I've already implemented a poor man's parser for those files that extracts the skeletal structure of the ES6 class quite successfully. I'll stick with that for the time being and keep checking in occasionally to see if/when closure-compiler might have (even early) support for those features.

Thanks again and best regards,

Scott Wells

[closure.compiler.conduct]

Hello zad0m,

Please keep your posts here on topic and civil as is required by our Code of Conduct.

Best regards,

closure-compiler Code of Conduct Committee