General Advice on Setup & Resolving Issues

Hi,

My current setup is as follows:

  • ALM used: GitHub
  • CI system used: GitHub Actions
  • Scanner command used: mvn verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar
  • Languages of the repository: Vue.JS/TS/JS (frontend), Java (backend)

I have a parent pom which delegates to the frontend pom that specifies the sources and my tsconfig for the frontend (I get a lot of false positives due to it not reading Vue.JS properly or my TS version (3.9.7).
Lots of issues like this:

<big>"<strong>" and "<em>" tags should be used</big>

I’m fine with marking these as false positives and resolving them, but then I find that if I merge that feature branch into my integration branch, they pop up again, and then when I release and push to master the same thing happens.

When I am scanning feature/bugfix branches I am using the following:
mvn verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.branch.name=$branch -Dsonar.branch.target=development

development is my integration branch. When I am scanning this branch I use:
mvn verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.branch.name=development -Dsonar.branch.target=master

And finally when I scan master I use:
mvn verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar

Both development & master are long lived branches, the rest are short-lived.
From all my reading this is the way to set it up but for some reason already fixed issues tend to pop up again in future branches. Is there a setting somewhere I have overlooked? Any help would be much appreciated.

Also, if there is a better way to do my scanning or set it up I am all ears. Currently both frontend/backend exist in the same repository hence why I’ve set it up this way but I’m not adverse to maybe changing it if there is benefit in doing so.

Thanks,
Terry

Hi @tsposato ,

Vue.JS and TS are part of the languages and frameworks supported by our products.
I suggest to open another forum thread, describing your Vue.JS and TS configuration and versions.
Someone specialist of the support of JS/TS may be able to improve that support and solve the root problem.
Please use the javascript, typescript, github-actions and maven tags to help routing the thread to the right team, and include the logs produced by the Scanner during analysis.

About the main issue of that thread, does the development branch match the “long-lived branch pattern” in the SonarCloud UI? (Administration > Branches & Pull Requests, the pattern is shown at the top right corner of the page).
A screen shot of the Administration > Branches & Pull Requests page may help, with the main branch, the development branch, 1 feature branch affected by the issue and the pattern. All private details can be masked.

So far, I didn’t succeed in reproducing the issue, it seems I am not aware of some important configuration implied here. Could you please try to build a public reproducer and share the link of the SonarCloud project link here?

1 Like

Hi @Claire_Villard ,

I will create another threat for my JS/TS issues after I resolve my core issue.
As requested here is a screenshot of my branches & PR’s:


As you can see, the master branch here has a status of failed, however when we merge our PR’s into development branch we ensure all outstanding sonar items/issues are resolves. This includes a bunch of the Vue issues which we resolve as false positives. Once I merge the development branch into master, the same issues are then raised again and if I want to have it as Green and Passed the developers need to manually go and resolve them again.

Maybe this is due to the TS/JS configuration problem and I should work on resolving that first?
The issues are all Vue/JS/TS related, here is a snippet of them:


There is definitely a chance I have set it up incorrectly, but from the docs that I have found everything looks good from my end. Happy for you to point me in the right direction.

I’ve attached the sonar logs as well just in case they shed some light on the issue.
sonar-logs.txt (15.3 KB)
Thanks.

Hi,

At first glance, the branch configuration seems fine. I tried to reproduce using the same parameters on one of my test projects, and the issues did not reappeared, so I have the feeling it may be connected to the problem with Vue.

To confirm that, if you close an issue on a Java file on a feature branch, does it reappear once merged on the long branch?

Hi,

It does look like that the issue is only the frontend components. I can confirm that issues closed or resolved in our PR/development branches on Java files don’t reappear on the master branch. The issues that reappear currently are in .vue or .scss files. I did see this ticket that got resolved recently - https://jira.sonarsource.com/browse/MMF-1441 - I wonder if this may have something to do with it?

I did re-run a scan of our master branch which didn’t change anything but maybe I’m reading that ticket wrong and my issue is potentially something different.

Hi,

Thanks for the confirmation the issue is limited to frontend files.

This ticket you found implements the support of the Vue.JS single file components (SFC). Are you using that feature on your project?
This feature is available on SonarCloud since Feb 15th, did you notice some change before/after that date?

I notice several parsing errors in the scanner logs:

[INFO] Sensor TypeScript analysis [javascript]
[INFO] Deploying custom rules bundle jar:file:/home/runner/.sonar/cache/f2d4f3985cfdc8a536978941e81bc342/sonar-securityjsfrontend-plugin.jar!/js-vulnerabilities-rules-1.0.0.tgz to /home/runner/work/project/project/target/sonar/.sonartmp/eslint-bridge-bundle/package/custom-rules466951565167290432
[INFO] Using /home/runner/work/project/project/frontend/tsconfig.json from sonar.typescript.tsconfigPath property
[INFO] 107 source files to be analyzed
[INFO] Analyzing 107 files using tsconfig: /home/runner/work/project/project/frontend/tsconfig.json
Error:  Failed to parse file [frontend/src/components/ReceiverDetails/DeliveryDetails.vue] at line 31: Unexpected token (7:33)
Error:  Failed to parse file [frontend/src/components/ReceiverDetails/ReceiverTimeSlots.vue] at line 46: Unexpected token (11:41)
Error:  Failed to parse file [frontend/src/components/Item/ReferenceForm.vue] at line 19: Unexpected token (7:18)
[INFO] 18/107 files analyzed, current file: frontend/src/components/ConfirmActionModal/ConfirmActionModal.vue
Error:  Failed to parse file [frontend/src/components/DatePicker/DatePicker.vue] at line 25: Unexpected token (6:36)
Error:  Failed to parse file [frontend/src/components/Alert/Alert.vue] at line 32: Unexpected token (8:36)
[INFO] 53/107 files analyzed, current file: frontend/src/components/ClientSelect/ClientSelect.vue
Error:  Failed to parse file [frontend/src/components/SuburbFormInput/SuburbFormInput.vue] at line 54: Unexpected token, expected "," (26:19)
Error:  Failed to parse file [frontend/src/components/CustomEmail/CustomEmailForm.vue] at line 164: Missing semicolon (35:28)
[INFO] 84/107 files analyzed, current file: frontend/src/components/ManifestDataTable/ManifestDataTable.vue
[INFO] 107/107 source files have been analyzed
[INFO] Sensor TypeScript analysis [javascript] (done) | time=39831ms

Have those files something special?

Hi,

Yes we do use Vue.JS SFC. Those files do have some of those. Is there something we need to turn on or change to enable it or will it be automatic? I still see those errors in the logs since Feb 15th.

Hello @tsposato,

Since February 15, SonarCloud uses SonarJS 7.2, which introduced the support of TypeScript code inside Vue.js Single File Components. One consequence of this novelty is that JavaScript code inside Vue.js file is now parsed with TypeScript compiler to benefit from type information and analysed with TypeScript rules, including type-aware ones.

Now that Vue.js files are considered as TypeScript code, issues on such files that used to be resolved (back when it was considered JavaScript code) could reappear. This is an unfortunate but temporary side-effect of introducing the support of TypeScript analysis in Vue.js Single File Components. Given your branching setup, such issues may pop-up occasionally but you can expect to see this side-effect eventually vanish. However, if the aforementioned pattern keeps popping up over time (let’s after a few weeks), then the problem might be outside of SonarJS’s scope. Please come back to us if this is still the case.

Coming to the parsing errors that were reported in the logs, it would be interesting to check on your side whether those errors were already there before SonarJS 7.2, in other word before February 15. Regardless of the outcome, we still need to understand the reason behind these parsing errors. Your code may be using some non-standard syntax. In that regard, we would need from you a minimal code reproducer taken from one of these failing files so that we can investigate further.

Hope this helps,
Yassin

2 Likes

Hi @Yassin_Kammoun,

I know that we definitely do use Vue.JS Single File Components so I will monitor these carefully from now on to see if bugs/smells that we resolve continue to pop up in our long lives branches once we merge.

Most of the ‘Failed to parse file’ errors looks like they are due to lines begining with ‘@Prop’ within a ‘script’ block.

DeliveryDetails.vue:
@Prop({ default: '' }) private notes: string

ReceiverTimeSlots.vue:
@Prop({ default: new Date() }) private dispatchDate: Date

ReferenceForm.vue:
@Prop() private reference: Reference

If needed I can go into more detail and attach the full files that are failing to parse, just let me know.
It seems like most are false positives or errors in the scanning as the app compiles/runs and it working.

Thanks.

Hello again,

Thank you for the additional information. Unfortunately, I was not able to reproduce the parsing errors with the @Prop decorator you suspected to be the cause. My guess is that the problem lies elsewhere. Therefore, I would really appreciate if you can attach the full files that are failing to parse.

Best,
Yassin

Hi @Yassin_Kammoun,

I’ve attached the files here for you.

Regards,
Terry

Sonar-failed-parses.zip (7.1 KB)