.vue files are not being analysed but sonarcloud scan succeeds

SonarQube Cloud
,
1

.vue files are not being analysed by SonarCloud scanner but scan succeeds. Please help us understand why this happened and how to fix this.

  • ALM used: Bitbucket Cloud
  • CI system used: Bitbucket Cloud
  • Scanner command used when applicable (private details masked): - pipe: sonarsource/sonarcloud-scan:1.2.2
  • Languages of the repository: javascript, typescript, vue
  • Only if the SonarCloud project is public, the URL: Private repo
  • Error observed: Attached logs -
    scan-logs.txt (24.3 KB)
2

Can someone please look into this and help. It’s urgent.
I tried increasing Dsonar.javascript.node.maxspace but it wouldn’t work.

4

Hi @kiki

Could you share the content of that ‘.vue’ file? You can do that privately.

6

Hi @Lena

I do not have the option to send a private message to you. Could you please guide me on how to share this file privately.

7

I first assumed something is wrong with that first file you’ve sent me, but when I analyze it alone everything is ok. So probably the whole project initialization (which happens during first file analysis) is not successful.

I suggest you to try following:

  • You can use sonar.javascript.node.maxspace property to allow the analysis to use more memory. Set this property to 4096 or 8192 for big projects. This property should be set in sonar-project.properties file or on command line for scanner (with -Dsonar.javascript.node.maxspace=4096 ).
  • You can try to remove node_modules dir before analysis
  • Finally you can try to limit number of files by setting sonar.sources (accepts specific directories) or sonar.exclusions (accepts patterns).

Could you also let me know if it started failing recently (when?) or it was failing from the beginning?

8

As I mentioned already, I tried increasing Dsonar.javascript.node.maxspace but it wouldn’t work. Yes, it has been failing from the beginning - the very first .vue file itself is not being analysed.

We can’t really remove any modules from the repo, will try to exclude libraries using exclusions property. But node_modules get generated only as part of our npm CI on a different pipeline and sonar pipe is on a different pipeline. So, adding it in exclusions kind of didn’t work nor did adding other artifacts from the steps in the same pipeline as sonar pipe.

node_modules
node_modules1611×509 33.1 KB

Also, if it helps: I created a test repo with just this .vue file. Scan succeeded and this vue file was also analysed.

9

To check if other pipeline steps are causing issues with sonar scanner, I copied the whole repo to our internal test repo with a simple pipeline with just sonarscan pipe. Same errors. I also observed that the problem is not with any particular vue file. Any vue file being picked up for scan first is not being analysed.

Observed these extra errors by enabling debug logs:

...
INFO: 0/580 files analyzed, current file: **/<filename>.vue
INFO: 0/580 files analyzed, current file: **/<filename>.vue
INFO: 0/580 files analyzed, current file: **/<filename>.vue
ERROR: eslint-bridge Node.js process is unresponsive. This is most likely caused by process running out of memory. Consider setting sonar.javascript.node.maxspace to higher value (e.g. 4096).
ERROR: Failure during analysis, Node.js command to start eslint-bridge was: node --max-old-space-size=4096 /opt/atlassian/pipelines/agent/build/.scannerwork/.sonartmp/eslint-bridge-bundle/package/bin/server 32837 127.0.0.1 /opt/atlassian/pipelines/agent/build/.scannerwork true false /opt/atlassian/pipelines/agent/build/.scannerwork/.sonartmp/eslint-bridge-bundle/package/custom-rules4347962301006135656/package
java.lang.IllegalStateException: eslint-bridge is unresponsive
...
10

Since there is too much info in this thread, I’d like to summarise the problem here with specific latest info:

  • Javascript analysis fails with javascript heap oom error, after a series of INFO: 0/580 files analyzed, current file: **/<filename>.vue and ultimately this error: eslint-bridge Node.js process is unresponsive., but overall scan succeeds and produces quality metrics.
  • These 580 files are a mix of vue files and js files in majority.
  • This doesn’t look like a problem specific to vue files - some vue files have been analysed for maintainability, bugs, debt, etc., (could see some suggestions for these files on sonarcloud dashboard).
  • Other pipeline steps artifacts and things are not interfering with sonar analysis.
  • Workarounds tried and failed: -Dsonar.javascript.node.maxspace=4096/7128 (doesn’t look like a problem of insufficient heap); increased both java heap and js heap to 4096; exclusions for libraries; increase build step size to 2x.

Open questions: Sensor JavaScript analysis [javascript] analysis is failing in the very first step even after increasing maxspace to 7128. Why? And what exactly does this part of sonar analysis analyse?

11

Another failed workaround as discussed on private messages with Lena: -Dsonar.javascript.allowTsParserJsFiles=false (analyzer will not try to analyze JS with TypeScript compiler). Shared logs for the same on private message.

12

Tried this to narrow down the problem:
Exclude all .vue files - sonar.exclusions=**/*.vue and sonar.javascript.allowTsParserJsFiles=false

Got such errors:

ERROR: Failed to parse file [**/<jsfilename>.js] at line 2: unknown: Support for the experimental syntax 'classPrivateProperties' isn't currently enabled (2:3):

  1 | class Emitter {
> 2 |   #listeners = new Map()
    |   ^
  3 |
  4 |   addListener(label, callback, vm) {
  5 |     if (typeof callback === 'function') {
13

Thanks @kiki

Those parsing errors have nothing to do with the initial problem, it’s just some new syntax you are using in several files which we are not able to parse (ticket created). Overall it seems that analysis is successful.

So most likely the problem is indeed is that when analyzing the first file, the whole project is built, and 5 minutes is not enough for your biggish project (ticket for it).

sonar.javascript.allowTsParserJsFiles=false is supposed to disable the whole project build but it does not, as .vue files are part of the project (see this bug ticket). I hope this one will be fixed soonish so that you could analyze your entire project at least with sonar.javascript.allowTsParserJsFiles=false. But as it’s an internal technical property and enabling it makes analysis less precise eventually you should remove it.

Feel free to subscribe to those tickets and create new threads here if other problems arise.

Regards,
Elena

15

Hi @Lena, by when can we expect these fixes to be ready? Can this be fast-tracked?

16

Can these fixes be fast-tracked?

17

+1

any update on this ?

18
  • 1 here
    Seems like a lot of people suffer from the same issue
19

@arsen this is an old thread, and the issues mentioned in this ticket were fixed, or they are no longer relevant. Could you please create a new topic and describe your problem, share the logs, etc…?

20

I had the exact same issue with Eslint, For getting better control I moved my pipeline from Bitbucket to Jenkins and the issue persists. The scanner will start scanning JS files fine after reaching the 4700 mark out of 6038 JS files the error pops out Failure during analysis, Node.js command to start eslint-bridge was: node --max-old-space-size=8192 /tmp/jenkins/workspace/ube_9.9_sonar-test-latest-master/.scannerwork/.sonartmp/eslint-bridge-bundle/package/bin/server 41183 127.0.0.1 /tmp/jenkins/workspace/ube_9.9_sonar-test-latest-master/.scannerwork true false

Tried investing time in all the solutions mentioned above, is there a permanent solution to this problem? If you believe that this issue is fixed, please it’s not, am using the latest version sonar-qube 9.9

Not sure what’s next, this doesn’t seem to be a good customer experience.