what are you trying to achieve: Calculate code coverage for typescript monorepo
what have you tried so far to achieve this:
Issue description
When running sonar-scanner against nx mono repository (459k lines of typescript code), couple of files having 0% coverage, even though coverage report reports the lcov.info file, which have 100% or slightly less code coverage with error like:
can't save DA data for line 403 of coverage report file (java.lang.IllegalArgumentException: Line with number 28 doesn't belong to file service-users.model.ts
There is around 20 files with this error, so not many, but these files are across couple of libs. This can't save DA data is displayed many many times for these around 20 files. These libs are still containing files, which doesn’t have this kind of issues, so it shouldn’t be related to library configuration.
When I run analysis on the specific lib by running sonar-scanner -Dsonar.projectBaseDir=libs/my/lib/path and specify the one specific coverage *.lcov report file, it works smoothly on all files in this library.
I also tried to use nx-sonarqube but behaviour was exactly the same like by using sonar-scanner diirectly.
Just to make sure: with exactly the same coverage file analysis/import from the root directory fails with data errors about which lines are in which files, and if you set the analysis directory (via sonar.projectBaseDir) import succeeds.
Are the relevant file names duplicated within your project? I.e. does service-users.model.ts exist in multiple directories in the monorepo?
Right, so basically to get rid of other possible issues, I generated code coverage for the single library (project). This code coverage report was the same for running analysis with either projectBaseDir definition or without.
Yes, service-users.model.ts exists in two directories in monorepo. This is something, what kinda came into my mind in the beginning. Because if there would be some issue with project configuration, it wouldnt happen that for most of the libraries the coverage report succeed even in the same library.
Ah, @ganncamp I made a small progress. When I excluded the duplicated file from analysis (sonar.exclusions), the original file which I required coverage for, was covered properly. There are other 16 files with the same issues (some of them are with pretty generic name like index.ts or helper.ts) so I’m not really able to realise, what is causing this issue.
Do you have any recommendation how to get rid of this issue?