SonarJS and ES2017 Decorators

(Melissa) #1

It doesn’t appear that the latest versions of the sonar scanner support ES2017 class decorations, despite evidence to the contrary. Is this correct? Or am I misconfiguring something?

I’m using SonarQube with latest updated plugins, and the most recent version of the dotnet-sonarscanner global tool:

dotnet sonarscanner begin /k:"Server" /n:"Server" /d:sonar.login="%sonar.key%" /"http://sonarqube:9000" /d:sonar.cs.opencover.reportsPaths="coverage/*.xml" /d:sonar.pullrequest.base="$base" /d:sonar.pullrequest.key="$number" /d:sonar.pullrequest.branch="$branch" /d:sonar.typescript.lcov.reportPaths="Assets/private/aurelia/coverage/" /d:sonar.javascript.lcov.reportPaths="Assets/private/aurelia/coverage/"

When I run an analysis, I am flooded with messages like
[Step 9/10] ERROR: Failed to parse file [file:///src/UI/Assets/private/aurelia/src/utils/util.js] at line 22: Unexpected character ‘@’

It looks like support for this was added back in 2016 ( but I don’t see it working in our scanner runs. I also don’t see any relevant settings that might help in our Sonarqube profile configurations. Am I missing some setting?

(Andrea Guarino) #2

Hi @queen-of-code,
welcome to our community.
Regarding SonarJS, we’re currently working on replacing our “homemade” parser with a community-based one espree (the one used by ESLint).

As we didn’t complete the full migration, we try first to parse with espree parser: if we have a parse error, we log an error message and we fallback to our “homemade” parser.
If I’m not wrong decorators are still at stage 2, so they’re not considered standard JS syntax (hence espree doesn’t support them).

However, despite having those parse errors logged, your analysis should still be successful at the end. Could you please confirm if that’s the case?