sonarlint-intellij: SonarQube for JetBrains IDEs, in the editor

Squiggles in the editor, before the commit

SonarQube for IntelliJ is an IDE extension that helps you detect and fix quality issues so you deliver integrated code quality and security, and the README compares it to a spell checker: SonarQube for IntelliJ squiggles flaws so they can be fixed before committing code.

That comparison sets the expectation correctly. This is not a server-side scan and not a report you read the next morning. The feedback appears in the editor, on the code you are writing, with the same shape of interaction as the underline under a misspelled word.

The installation route is the standard one for a JetBrains plugin. The README points at the JetBrains Plugin Repository, where the plugin is listed as SonarQube for IDE with the identifier 7973-sonarqube-for-ide, and says it is directly available in the IDE preferences. The project is written in Kotlin, and the topic tags place it in static analysis, code quality, security and IntelliJ.

The homepage for the product is the SonarQube for IDE features page for JetBrains, and the full documentation sits at docs.sonarsource.com/sonarqube-for-intellij.

One naming point is worth noting for anyone arriving from older documentation. The repository is still called sonarlint-intellij, the topics still include sonarlint, and the debugging section of the README refers to the SonarLint Team and to SLOOP, while the product name used in the text is SonarQube for IntelliJ. The plugin and the analysis service are separate pieces, and the naming reflects that history.

The audience is straightforward: developers working in IntelliJ IDEA and its siblings who want quality and security findings surfaced while the code is still in front of them.

The rules catalogue and a community forum that expects patience

Where the checks come from is documented separately from the plugin. The README links a Rules page in the documentation, on which a full list of supported programming languages and links to the static code analysis rules associated with each language are available.

That separation is the point for an evaluation. A plugin that ships with an opinionated set of checks is only useful if you can see what the checks are and how many of them apply to your language. The rules page is the answer to the question of what you are actually going to get in the editor, and it is worth reading before install, not after.

Support runs through the SonarSource community forum, and the README is unusually specific about how to use it. For support questions you should first read the FAQ to learn how to get your logs, and then head to the Sonar forum. Before creating a new topic you should check whether the question has already been answered, because there is a chance someone has already had the same issue.

There is also a request for basic courtesy. The forum is a community and the standard pleasantries are expected, and if you do not get an answer to your thread you should sit on your hands for at least three days before bumping it. The note that operators are not standing by but that the Teams and Community Managers know your questions are important is a fair description of how volunteer-run support actually works.

For a project with this much usage, that guidance is the difference between a support forum that stays searchable and one that fills with duplicates.

Feature contributions are closed, typo fixes are not

The contributing section sets expectations that are worth reading twice before anyone plans a pull request.

If you want to see a new feature, the README points at a PM for a Day page, which provides a forum to discuss needs and a chance to engage the Product Manager and development teams directly. That is the route for asking for something.

For code, the statement is blunt: the project is not actively looking for feature contributions, because it is extremely difficult for someone outside SonarSource to comply with the roadmap and expectations, and therefore typically only minor cosmetic changes and typo fixes are accepted.

If you do submit code, the README asks you to create a pull request and to explain your motives for contributing the change, describe the problem you are trying to fix, and state the improvement you are trying to make. The SonarLint Team reviews the pull request and discusses internally how it aligns with the published roadmap. You are also asked to follow the project's code style, which points at the sonar-developer-toolset configuration for IntelliJ, and to make sure all tests are passing.

This is a common arrangement for a commercial product with an open source client, and it is worth weighing before you invest time. The plugin is open source and readable, and the analysis experience is something you can configure and report on, but the direction of the product is set by the vendor, and the venue for changing it is the Product Manager discussion rather than the pull request queue.

One Gradle command builds the plugin, and tags are the safe build target

The build is a Gradle build with a wrapper in the repository, and the README documents three commands.

./gradlew buildPlugin

That produces the plugin artefact. The README is clear that this does not run the tests and the checks, and to include those you run:

./gradlew check buildPlugin

And for the complete list of tasks:

./gradlew tasks

The build directory layout supports that, with a root build.gradle.kts and settings.gradle.kts, a gradle/ directory, gradle.properties, and both gradlew and gradlew.bat for the two platforms. There is also a gradle.lockfile and a settings-gradle.lockfile, which means the dependency versions are pinned, and a mise.toml for toolchain versions, plus a nodejs/ directory for the frontend build.

The important caveat is the one about external contributors. The README states that the project should be guaranteed to build from any specific tag, and that during the development phase some unreleased dependencies not accessible to the public could be used, preventing you from building the project.

In practice that means building the tip of master can fail for reasons that have nothing to do with your environment, and the fix is to build from a released tag instead. For anyone who wants to run the plugin locally with a patch applied, that is the first thing to know.

UI tests need a real IDE, in the foreground, with a token

The UI test instructions are the most specific part of the README, and they describe a heavier setup than a unit test suite.

To start an IDE instance with the plugin loaded:

./gradlew :its:runIdeForUiTests &

The README then says to wait for the UI robot server to start, and only then run the integration tests:

./gradlew :its:check

Afterwards you close the IDE. The background ampersand in the first command is doing real work here, because the second command talks to the running instance.

Two properties let you target a specific environment. The ijVersion property selects the IntelliJ version to test against, with the example given as IC-2025.2, and the runIdeDirectory property points at a local IDE installation you want to run instead:

./gradlew :its:runIdeForUiTests -PijVersion=IC-2025.2 &

./gradlew :its:runIdeForUiTests -PrunIdeDirectory=<path_to_ide> &

The README also notes that the IDE must be in the foreground while the tests are executed, and that because some integration tests use SonarCloud, the SONARCLOUD_IT_TOKEN environment variable must be defined, with the value held in the project's password management tool.

That token requirement is worth flagging for an outside contributor. It means the integration suite expects a SonarCloud identity, so a contributor without one can run the plugin locally and the build tasks, but not the whole of the UI test suite.

Attaching a debugger to the plugin inside the test IDE

There are two debugging situations, and the README covers both.

For the test side, you can launch the test in debug mode from the IDE. For the plugin side, you open the project in IntelliJ and run the its:runIdeForUiTests task in debug mode, for example from the Gradle panel on the right.

The third case is the interesting one, debugging SLOOP, the component the README calls the thing you might want to plug the debugger into. The steps are: open the run configuration you use to launch the IDE, either runLocalIde or its:runIdeForUiTests, add an environment variable named SONARLINT_JVM_OPTS with a specific value, run the task, open the SLCORE project and use Run and Attach to process, and finally choose the SLOOP running process.

The value of the SONARLINT_JVM_OPTS environment variable is a Java debug agent line:

-agentlib:jdwp=transport=dt_socket,address=8080,server=y,suspend=n

The suspend=n part is what allows the process to start without waiting for a debugger to attach, and address=8080 is the port the debugger then connects to. This is a standard JDWP remote debugging setup, and the README adds that if you want the debugger attached as soon as SLOOP is started there is more to the procedure.

For a plugin whose real work happens in a separate process, being able to attach a debugger to that process rather than to the IDE shell is the difference between finding a bug and guessing at it.

A multi-IDE codebase, pinned dependencies, and a tight release line

The repository layout shows a plugin that covers more than one JetBrains IDE. There are separate source roots for clion/, clion-resharper/ and rider/, alongside common/, src/, git/, nodejs/, repo/, its/ and test-common/, plus a docs/ directory and a .sonarlint/ configuration directory at the root.

The clion-resharper directory in particular suggests the plugin ships a companion piece for the ReSharper based IDEs, and rider/ and clion/ confirm the multi-IDE scope. The git/ directory suggests the source control integration is a separate module, and its/ holds the UI test project, with test-common/ holding shared test fixtures.

The legal files are worth a note. LICENSE.txt sits at the root with the LGPL-3.0 licence recorded for the project, and there are also NOTICE.txt, THIRD-PARTY-NOTICES and a HEADER file, which is the standard notice and header tooling for a project with a mix of licence obligations. SECURITY.md covers vulnerability reporting, and AGENTS.md and CLAUDE.md are present for automated contributors, alongside a .verifier-ignored-problems.txt that presumably suppresses known findings from the verifier.

On releases, the numbering shows a plugin that ships against every IntelliJ release. 12.8.0.85170 was published on 2026-08-31, 12.9.0.85269 on 2026-09-14, and 13.0.0.85671 on 2026-10-14, with the last push to the repository on 2026-10-20. The four-digit build number after each version is what identifies a plugin build for the marketplace, and the cadence of roughly one release per month is what you should plan around when you pin a version in a team.

Editorial conclusion

sonarlint-intellij suits developers who want static analysis feedback inside the editor, before a commit rather than after it, and it suits teams moving to the SonarQube rule set who want the same rules locally and on the server. It does not suit a team that expects to contribute features, because the README states that outside feature contributions are not actively sought and that only minor cosmetic changes and typo fixes are typically accepted, and it does not suit anyone who wants to build it from the tip of the branch. Check three things before you adopt it: that the IDE version you use is covered by the rules catalogue listed in the documentation, that your JetBrains IDE version matches what the plugin build targets, and that you read the requirements and installation pages, since the README deliberately keeps no version matrix of its own. The newest release is 13.0.0.85671 from 2026-10-14 and the last push to the repository was on 2026-10-20.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. SonarSource/sonarlint-intellij on GitHub