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 7.7.0.23042 with latest updated plugins, and the most recent version of the dotnet-sonarscanner global tool:
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 (https://github.com/SonarSource/SonarJS/pull/327) 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?
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?
I’m having the same issue as OP, where sonar scanner can’t parse decorators. The parser probably won’t support decorators until they officially make it into the spec, which is totally fine. Despite having the errors the analysis still succeeds, which is good. Is there a way to support this (maybe a plugin?) or leave it alone until the parser supports decorators?
We rely on espree and babel parsers under the hood.
Could you elaborate more which exactly syntax are you using? Examples would help. Also please tell which transpiler are you using.
In fact babel parser supports already at least some decorators. So I expect that JS analyzer will not fail for every use of decorators.
We are also experiencing these kind of issues, not only with decorators but other enabled Babel plugins (such as optional chaining). Is there a way to enable these plugins on the SonarCloud side or to just analyze the transpiled code and provide the source maps?
no this is currently not possible to customize the way we use babel parser. Currently we are a bit busy with migration to ESLint. Once the whole analysis is fully using espree and babel we will consider the use case to customize parser with plugins.
Welcome to our community, and thank you for your message.
There is actually an update about the support of decorators by the parsers we use. This ticket has been created for that purpose. We hope to address it soon, but as mentioned above, we are still busy with migration.
