We have recently installed an on-prem SonarQube sever (Developer Edition, version 10.1.0.73491, under a Windows Server VM), running scans manually on workstations (without integration with any CI/CD pipeline). The scans of JS code run correctly, yielding both Issues and Security Hotspots, reflected in the server Web interface.
We also installed SonarLint (v. 3.21.0) under VSCode (v. 1.81.1) on a Windows 10 machine and defined an interface to the SonarQube server.
The connection seems to have succeeded: according to logs appearing in the “Output” tab of VSCode, the rules are fetched, and so are project branches, issues, taint issues and hotspots. All the messages appearing in the “Output” tab are of “Info” level.
However, neither hotspots, nor issues are shown in the VSCode workspace. Instead, the Security Hotspots section shows a message “Please ensure a connection to SonarQube 9.7+ or SonarCloud is set up…”, and “Problems” tab shows nothing.
Running SonarLint directly on the source code (by selecting “In Whole Folder” option) works, filling both Security Hotspots and Problems, but without any sync with the server definitions.
Our network, servers and workstations are working in a closed and hardened environment, so it is possible that some Data Security tool is interfering with the process. Please advise how it is possible to troubleshoot the problem.
Hello @greg_ya and welcome to the community!
Thanks for your detailed report. Can you please ensure that verbose logging is enabled for SonarLint? And after it’s done please open the project that is bound to SonarQube and then open the file with the code in the VSCode editor.
Once you have done it please copy the log output and upload it here as txt file.
Have a good day!
SonarLintLogs.txt (295.8 KB)
Hi, Kirill,
Thank you very much for your help!
I did as you said, the log file is attached. Also attached is a screenshot from the SonarQube UI, where you can see a vulnerability detected in Worker.js, and a screenshot from the SonarLint page, where no Security Hotspots are shown even after I opened Worker.js in the workspace, as you suggested.
I guess our problem is that the sonarqube/api GET’s (appearing in log lines 2357, 2361 and 2365) are returning empty results. I tried to run them manually from a browser, and received some very short binary response (a protobuf with no results?). Tried manually to set the “changeSince” in the URL parameter to a small value, but got exactly the same result.
Regards,
Greg.
Hi Greg,
What I see from the log is that your SonarLint instance pulling for the correct branch which is main, but getting an empty response. This is a bit strange for sure, given you can see the issue in the SonarQube web interface. And I don’t see any errors in logs or other signs why is it this way.
I’ll try to find what are possible reasons and how can you troubleshoot it. I will keep you posted here on this topic.
But regardless of server synchronization results, you are still supposed to have local analysis. Yes, server data about issues will not be taken into account. Like if you marked the issue as Won't fix during review for example. Normally such resolved issues should disappear in SonarLint, in your case they won’t. But issues still should be there. And here becomes relevant the fact that the log you have posted does look truncated to me.
The last lines of your logs are related to the JavaScript/TypeScript analyzer warming up and preparing everything for analysis. So after you are supposed to have a little bit more logs about warming up JS/TS analyser and then local analysis. On my machine, when I run the analysis the first time after IDE restart, I can see it stops printing logs for the noticeable time exactly after the line that is the last one in your log. It’s waiting for the initialization of everything it needs to have to start the analysis. But then it continues and performs the analysis (on my box).
So question. Could it be that you have copied logs during such a warmup pause on your machine? Can you please try again and give it a bit more time? Really ensure it doesn’t print anything after. After warming up, further analysis iterations should be significantly faster, but initialization may take time.
Best,
Hi, Kirill,
Yes, you are right, I just did not wait enough. SonarLint did try to scan the file locally, but eventually failed as well.
There is a lot of bulk printouts in the log file, I tried to cut only the lines which seem to show a reason for the failure. My guess would be that line 50 is showing that reason: RUNTIME_API_INCOMPATIBLE, whatever it means…
Thanks!
Greg.
SonarLintLogs1.txt (7.2 KB)
Hi, Kirill,
Hate being pushy, but any chance you were able to have a further look into it?
Thanks,
Greg.
Hi Greg.
The new log you submitted makes me think that something unexpected happened during the analysis.
I have asked my colleagues who work on JavaScript/TypeScript analysis to look at this. They will do it when they have time.
In the meantime, you could check if you have issues with other languages like Python for example. You don’t need to have Python installed on your machine. It will be enough to create a .py file in your project and put there some code that is supposed to have issue(s). Something like
def myFun():
# TODO foo bar
i = 0
print('Hi')
j = 0
should do the job.
If you can see the issues for the Python code it means that the problem is specific to JS/TS.
Best,
Hi, Kirill,
I made some more experiments, including a Python file, as you suggested. I created a “hardcoded IP address” vulnerability in Python, and it was detected both in SonarQube Web UI and in a local SonarLint VSCode run. I also made some more experiments with JS files. This time the local SonarLint JS runs succeeded as well, maybe Python file being in the folder made the difference.
After all this I think I managed to focus the problem to the following:
For some reason, SonarLint only shows hotspots or problems from its own runs. Either “In Open Files”, or “In Whole Folder” - whatever option is selected for display. But it never shows the issues stored in SonarQube server, even though (according to logs) it succeeds fetching them with /api/hotspots/pull calls.
Here for example (the 1st log file that I sent), we see it receiving 59 hotspots:
[Debug - 07:38:19.372] GET 200 http://XX.XX.XX.XX/sonarqube/api/hotspots/pull?projectKey=NeWMI-2&branchName=main&languages=apex,c,cpp,css,cobol,web,java,js,php,plsql,py,secrets,ts,xml,yaml,go,cloudformation,docker,kubernetes,terraform | response time=118ms
[Debug - 07:38:19.378] Pulled issues in 124ms
[Debug - 07:38:19.407] Merged 59 hotspots in store. Closed 0. | took 26ms
59 hotspots were fetched, but they never showed up in VSCode. This goes both for JS and Python code.
So, there might be a problem in the local SonarLint JS scanner (sometimes fails to run). But our real problem is causing SonarLint show issues exposed by SonarQube server, and not those collected locally.
Thanks,
Greg.
Hello @greg_ya,
Many thanks for the feedback and the logs you provided. That helped a lot!
A subset of JavaScript rules uses TypeScript’s compiler to benefit from type information and improve their analysis precision. When type information is missing, these rules can find (less) issues to some extent or just don’t do anything at all. The exact behavior depends on the rule implementation, and it’s a case-by-case decision depending on what’s doable.
For performance reasons, type information is available in SonarLint only for projects of a certain size. More specifically, the property sonar.javascript.sonarlint.typechecking.maxfiles (default 20’000 files) controls the enabling of type-checking JavaScript files. This means that JavaScript rules using type information become no-op should the threshold be exceeded.
Now, coming to your specific case, the security hotspot highlighted on the provided SonarQube screenshot happens to use type information. Furthermore, the logs that you kindly shared include the following lines:
[Debug - 07:40:16.508] Project type checking for JavaScript files deactivated as project has too many files (maximum is 20000 files)
[Debug - 07:40:16.508] Update "sonar.javascript.sonarlint.typechecking.maxfiles" to set a different limit.
This essentially means that JavaScript rules using type information won’t behave as expected.
Please try to set in SonarLint the property sonar.javascript.sonarlint.typechecking.maxfiles to a value higher than 20’000 until the issues are found. Note, however, that increasing that value could degrade the analysis running time and performance depending on your project size and the available memory.
Finally, we are aware that the printed logs are not helpful from the user’s perspective. We created this ticket to improve those as well as that ticket to help identity which rules are impacted when type information is missing. We will also solicit our Documentation team to document this limited feature in SonarLint’s context.
Hope this helps,
Yassin
Hi, Yassin,
Thank you very much for your help! I will try to change the property to a higher value. It will be helpful to have SolarLint check the entire JS project, without size limitation.
However, please notice that this problem is just a by-product of troubleshooting of another one: SonarLint fails to show issues found by the external scanner and reported to an on-prem SonarQube server (see my previous response to Kirill). Do you have any idea what is the problem there?
Regards,
Greg.
Hey Greg,
The only thing that I can say for sure is that if SonarQube analyzes some JavaScript file on its own and SonarLint analyzes the very same file on its own, but both don’t find the exact same set of issues, the type-checking limitation I mentioned earlier could be an explanation. It denotes the analyzer behaving differently in two different contexts, which is expected: the enabling of type-checking of JavaScript files in SonarLint is coupled with the project size, while SonarQube doesn’t have any limitations.
I am afraid I don’t know what’s happening in your case. The problem of these 59 hotspots fetched but not displayed on VSCode seems beyond the scope of the JavaScript analyzer. As far as I can tell, if this is a data exchange between SonarQube and SonarLint to notify new issues from the former to the latter, the analyzer is not supposed to be involved in the workflow.
Hi Greg,
Sorry for the late response. Regarding external scanners: SonarLint doesn’t support external analyzers, so it’s expected that issues reported by them are not displayed. If you missing some features for languages we support or you would like Sonar to support some new language - please post your suggestion in the Project Manager for a Day section of the community forum.
Best,
Hi, Kirill,
Sorry, but either I fail to explain myself, or I am missing something big time!
I am not trying to use SonarLint with any external analyzer, but rather with SonarQube!
The SonarLint Web site calls it “Connected Mode” (Connected Mode to SonarQube Linting analysis | How to set up), clearly stating that “Connected Mode extends SonarLint capabilities by allowing you to address security hotspots detected by SonarQube and taint analysis results from SonarQube/SonarCloud directly in your IDE, so you can fix them early.”
The screenshot that I attached to my previous post shows SonarLint pane saying “Please ensure a connection to SonarCube is set up. Detected security spots will show here”.
Why does this not work?
Regards,
Greg.
Hello @greg_ya ! 
Thank you so much for your patience and for using SonarLint AND for providing feedback! 
After having a look at this thread, here is how I understood your issue:
- You have a SonarQube server analyzing your JS files, and in the SonarQube UI you see all the Vulnerabilities and Security Hotspots as expected.
- You have set up a Connected Mode with SonarLint and expect to see exactly the same Issues and Security Hotspots as in SonarQube. (Due to the log lines saying that the Hotspots were downloaded).
I will try to explain why this is happening:
- By default, SonarLint will analyze only files that are open. In addition, the Security Hotspots view offers the possibility to scan the whole folder and this does yield some results as you pointed out before.
- SonarLint will always* display the findings detected locally, we fetch SonarQube issues and hotspots in order to apply correct status to local issues. *The only exception to this rule are Taint Vulnerabilities that SonarLint does not detect locally and fetches them exactly as they are on the server.
- Since SonarLint Security Hotspots view, and the SonarLint issues in the VSCode Problems view will include results of the local analysis, if local analysis fails for some reason, you will not see the findings.
- As highlighted in this post, for your case the local detection did fail, because of the
sonar.javascript.sonarlint.typechecking.maxfileslimitation. As a result, you do not see some of the findings seen on the SonarQube UI.
I hope this clarifies at least a little bit 
As for the improvements on our side, you are right that the text on the web site is a bit misleading. I will flag this for the relevant people possibly improve that.
Feel free to reach out if you have any questions.
All the best,
Sophio from