Hello @reitzig, welcome to the community! And thank you for reporting this.
We are painfully aware of this issue (I cleaned 3GB of cached plugins recently from my machine), and we already have a ticket to take care of it.
The problem is 3-fold:
there is no standard, cross-platform API for IntelliJ plugins to store data on local storage, hence our use of the config directory (actually suggested by JetBrains)
we cache plugins on server synchronization and after updates of SonarLint, but we don’t have a good heuristic to decide when to purge the cache
IntelliJ and its sibling IDEs create a new config folder for each version, duplicating the plugin cache in the process
We’ll make sure to prioritize this issue in an upcoming hardening sprint.
using that directory is totally the plugin’s choice, nothing in the API mandates that. I disagree with the statement that there is no better method in the API, but in any case the platform doesn’t restrict plugins from using any directory on the system.
There are a number of methods in com.intellij.openapi.application.PathManager ; which one suites the plugin better depends on that directory’s data life cycle.
Now, there’s little use in me playing messenger here, I think; maybe it’s worthwhile if one of the maintainers here engage?
Indeed and I believe we should first have a chat within the team about why this location was chosen in the first place and whether these reasons still hold.
I think you’re right, the files that you mention should belong to the cache and not config folder. It’s not very explicit on the API side, but I guess we could use PathManager.getSystemPath() that should map to the right cache folder on each OS. I created a ticket to do the change, not sure exactly when we will tackle it. In the meantime what I suggest is to have an exclusion on SonarLint subfolders when backing up your config folder.
Also, yesterday we released a new version of SonarLint for IntelliJ that should use less space in that config folder.