Support props in ESLint-based rules

[vilchik-elena]

No description provided.

[vilchik-elena]

class A {
   static foo = 42; // fails with "Unexpected token = "
}

class A {
   foo = 42; // fails with "Unexpected token = "
}

espree does not parse it, but babel-eslint does. But as we use babel-eslint only to parse flow we fail to parse this syntax.

Proposition https://github.com/tc39/proposal-class-fields

[simonedavico]

Wouldn't this be as simple as always using babel-eslint for parsing? Would you accept a PR?

[vilchik-elena]

@simonedavico good point, but are you sure there is no such syntax supported by espree and not supported by babel?

[simonedavico]

Unfortunately I am not an expert in js/es parsers...for sure, babelsupports syntax up to stage-3, while espree does not. This is an issue at my company because we are using arrow functions as class properties, which are supported by babel but not espree. They are also shipped with hugely popular tools (as in create react app), so I think providing support is for the best.

I opened PR #1143 , would you be so kind to take a look and give some feedback?

[rstrahl]

We're encountering the same issue in our project, and its halted usage on front-end analysis for us.
As far as I can see in the tooling implementation tracking issue reports as of this writing, espree does not support class fields. A quick check in the espree issue/PR tracker appears to support this.

Ref: tc39/proposal-class-fields#57

[gersongoulart]

I agree @simonedavico 's PR is all ok from the implementation point of view.

If that solution is not feasible for some reason, would this be the case of making the parse and parser options at https://github.com/SonarSource/SonarJS/blob/master/eslint-bridge/src/parser.ts#L41 configurable for the time being until the team has the confidence necessary to make necessary adjustments?

Allowing for the parser to be a configurable aspect of Sonar JS could also open up the solution for greater configurability — https://eslint.org/docs/user-guide/configuring#specifying-parser

[simonedavico]

@gersongoulart I actually wanted to make it configurable, but it would be more difficult to implement tests for each parser, since they are not feature equivalent. Of course with additional effort it could be achieved.

[slikts]

It would be nice if SonarJS would be able to reuse the ESLint configuration regarding which parser to use (since SonarJS uses ESLint's Espree anyway, so there's obvious overlap) and which files to include or exclude. It would make using SonarJS more streamlined and avoid having to duplicate settings, on top of supporting proposed JS features.