I was expecting that this plugin’s integration with Sonarcloud would mean that it would be able to just fetch the list of issues published to Sonarcloud. This would have made my life, from a developer’s point of view a lot simpler. This is not the case.
I was also expecting that it would be possible to analyze my entire project in Idea using this plugin. This is also not the case. While it is possible and perhaps works on minute code bases (spanning over maybe a language or two at best), this is not possible if your repository contains a mixture of Java, SQL, Python and JavaScript. I have a very powerful machine with 64 GB RAM + 4 TB SSD and a high end Intel processor and while my memory settings in Idea should be high enough, the analysis just crashes with an exception after about 5-10 minutes.
It isn’t possible to filter issues by rule type.
The only way this plugin works is if you’re working with just one file at a time. What year is this? 1991?
This is extremely disappointing and tedious to work with.
You should have a proper plugin for Idea which can:
Pull already published issues in Sonarcloud/Sonarqube
Analyze an entire project locally
Work with a single file
Publish issues to Sonarcloud/Sonarqube
Filter issues across the code base by rule type
In its current form this plugin is not particularly helpful, unless you settle with having to go over classes one by one, because you have to keep switching between the IDE and the webapp to check/resolve issues. Very inefficient and impractial.
Are there any plans to implement any of these features?
Thanks for bothering to share your frustrations with us. A lot of people wouldn’t have.
It does work that way for some types of issues, which we don’t run locally in the IDE because they would kill performance.
Otherwise, we run analysis live on the file(s) you’re coding in to give you the most accurate and up-to-date view of what you’re currently coding. If we blindly reported everything from SonarCloud, we would risk frustration and confusion by showing issues that you’ve already fixed.
No, it’s not the case. We see this as a best-tool-for-the-job question. Again, we don’t want to drag down IDE performance. We keep it quick and light by - intentionally - focusing only on where you’re currently working.
And we see the best tool for the job of overall codebase analysis as the CI pipeline, where it’s okay if analysis takes 2 or 5 or 10 minutes depending on project size and complexity.
That’s a hard no for us. If you haven’t checked in your changes yet, where do we “hang” the new issues you want to push from the IDE? And how do your teammates make any sense of them?
That said, we have added the ability for you to proactively mark an issue False Positive from the IDE even before it’s committed and analyzed in SonarQube (it’s not available yet in SonarCloud). Then when/if the issue ever shows up in a full analysis from your CI, it’s already taken care of.
Thanks for not being put off by my level of frustration, but it has been building for years now. I have been responsible for setting up and maintaining Sonarqube/Sonarcloud across a large number of your high profile commercial clients (mainly banking corporations). This feedback is also based on years of experience since your earliest versions and spanning across several programming languages and is not just my own rant, but it has also been echoed by co-workers.
Could you please clarify what “some issues” really means? Because, sorry, but to me this sounds like a joke. It either supports pulling down the issues, or it doesn’t. I have read the page you provided (a while ago), but none of these issues are being displayed. All I see are issues discovered on-the-fly in the current file and the sonarlint plugin is successfully connected to Sonarcloud via token.
The plugin should be able to connect to Sonarqube/Sonarcloud and get all the issues from there. If this actually worked this way, you wouldn’t have to keep scanning the entire code base, but just the changed files and your linting would happen quickly. No rocket science here, wouldn’t you agree…?
The “best tool for the job” is the one that actually does the job.
I’m sorry, but, in my opinion, this is just not even remotely attempting to be good enough in its current form. (It’s good for marketing and for non-technical managers to see in articles, “Oh, yeah, they have support for Idea/VSCode/etc”, but wait `til you actually have to start using it…). And this plugin has been around for what… 5-10 years now?
A plugin like this should be able to scan the entire project. It shouldn’t be actively doing it all the time, but only when manually triggered. By the developer. Who is the one entrusted to be making independent smart decisions. We all know that a full scan will take time. However, you should allow the user to have an actual choice. Otherwise you’re forcing an opinionated behaviour which doesn’t necessarily match their needs, but rather – what you think they will need and how they should use it.
Right, I can appreciate that this may require some effort to be implemented, but it’s actually by no means impossible.
When a developer works on a feature branch, there is a base branch (main, master, dev, whatever). Typically, companies carry out scans against at least a couple of these branches. When you do scans in pull requests, in the issues reported in Sonarqube/Sonarcloud, you can add a section that says “Pending fixes applied in origin/feat/123 to be merged via pull request foo/bar#1234”.
This is not so impossible to do and partial scans via the pull request or the sonarlint plugin can be the way to do this.
Right now, if you’re tasked with going through a large code base and sorting out issues reported in Sonarqube, you have to keep looking up the respective next issue in the Sonarqube web interface, copying the class name, going to the IDE fixing it, looking at the sonarlint plugin to see if it has detected other issues in the current file and potentially fixing those and then going back to the webapp to mark those as assigned and looking at the next batch. This is so inefficient and time-consuming that it make it almost pointless to have the plugin in the first place.
On a side note, it’s also very disappointing that reporting bugs for this plugin is such an ordeal. You have the project up on Github and people can see the codebase and contribute. However, you have disabled Github issues. Fine. Some companies do that. But then again, when you have a Jira for this, people should be able to create accounts and submit bug reports. This is going from open source to closed source and it sounds like you don’t care about the community’s feedback anymore.
I hope you take into consideration at least a fraction of my suggestions as they are meant as constructive criticism and are coming from both a Developer’s and DevSecOps’ point of view.
Sure. Specifically, this means issues from taint analysis rules. You can identify those rules in SonarQube using the Repository filter on the rules page & selecting the ‘Security SonarAnalzyer’ repository. Those rules require cross-file analysis, and so they’re deliberately not run on SonarLint to not drag down the performance. TBH, I’m not 100% sure on this point, but probably the rules from the ‘Dataflow Bug Detection SonarAnalyzer’ (DBD) also aren’t run in SonarLint, for the same reason.
Why aren’t you seeing these issues? They show up in a different tab in SonarLint, the Taint Vulnerabilities tab. Do DBD issues show up there too? Not sure. TBH, they’re still pretty new. I assume that’s where they (would) show up and probably we just need to rename the tab.
Why are they segregated? I wasn’t in those discussions, but probably because they weren’t detected “live” in SonarLint, and may have already been edited out of the file by the time you’re looking at them.
Again, the focus really is on helping you in the moment. We really don’t consider SonarLint the tool for overall code inspection.
The other type of “issue” that doesn’t show up in the default tab is Security Hotspots. For that one, the reason we don’t show them by default because by definition, Security Hotspots may or may not be actionable. They’re Schrodinger’s Vulnerabilities; each one may or may not be a problem - it depends on the context - and you won’t know until you review it. So we don’t detect them directly in SonarLint. We pull them down in connected mode and show them on the Security Hotspots tab.
I should add here that taint analysis and DBD issues aren’t available in SonarQube Community Edition. Security Hotspots are available for all editions.
Your main context upon which most of your frustration seems to be based is an overall audit and cleanup of the entire code base, right?
We haven’t - as you’ve pointed out - built SonarLint to do that. There are two reasons. First, that’s what SonarQube and SonarCloud are for.
Second, and more importantly to us, we simply don’t think that’s the best way to go about things. And yes, we’re being opinionated here. We believe - deeply and fundamentally - that all you need to do is follow the Clean as You Code methodology: make sure the code you check in today is issue free (this is what we built SonarLint for), well covered by tests and low in duplications. I.E. focus on New Code. Over time, overall code quality will take care of itself.
Does that mean we believe you should ignore new-found NPEs, for example, in old code? No. But that’s where SonarQube and SonarCloud come in. Use the UI we’ve built for the filtering you want to do to find those issues. Then use the button in the SonarQube issue UI (presumably coming soon to SonarCloud) to “Open in IDE” and implement the fix.
And yes, I admit that you’ll have to slog back to the SonarQube UI to find the next issue you want to fix. But the workflow doesn’t have to be onerous.
We currently have a mix of project on Jira and GHIssues, and we’re moving to standardize on Jira because it works better with the other tooling we’re using internally.
We tried this. It was… not fun.
We do, however, believe you should ideally be able to have an account in Jira to be able to vote for and watch the tickets we created as the results of discussions here. And when our Jira was self-hosted, that’s how it worked. Unfortunately, that’s something we all have to take up with Atlassian, which phased out self-hosted Jiras and then set the cloud pricing for this to prohibitive levels.
Anyway, back to the main topic…
I get that you’re frustrated. And I believe that frustration stems from a fundamental mismatch in expectations for what SonarLint should do.
We believe SonarLint should be a lightweight tool to help devs accomplish their normal coding tasks. Better.
