SonarLint for Intellij: Excessive use of storage space in .config

I recently saw my daily backup grow. Investigating, I found this:

❯ du -sh .config/JetBrains/
1,7G	.config/JetBrains/

❯ du -sh .config/JetBrains/*/sonarlint/plugins
133M	.config/JetBrains/IntelliJIdea2020.3/sonarlint/plugins
453M	.config/JetBrains/IntelliJIdea2021.1/sonarlint/plugins
481M	.config/JetBrains/IntelliJIdea2021.2/sonarlint/plugins
207M	.config/JetBrains/PyCharm2021.1/sonarlint/plugins
234M	.config/JetBrains/PyCharm2021.2/sonarlint/plugins

As you can see, a config folder of 1.7GB – which is, bluntly speaking, outrageous – is mostly attributed to SonarLint plugins.

Please store plugins in a cache folder.

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.

Thanks! I opened issue IDEA-275727.

If SonarLint could use ~/.cache for its cache, the problem (for me) would just go away; no app-driven purging needed.

1 Like

Huh. Roman Shevchenko writes:

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 :slight_smile: 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.