SonarQube for IDE: the SonarLint extension renamed and re-scoped

A rename that changes what the extension is for

The extension's title in the readme is SonarQube for IDE: Visual Studio Code, and the parenthetical says formerly SonarLint. The rename is more than cosmetic because the description also changed.

SonarQube for IDE by Sonar is described as a free static analysis tool that enhances code quality and security. The promise is that you analyze your code early, as you write it or generate it, and that local analysis automatically identifies quality and security issues in real time, even with AI-generated code. You then fix the issues using QuickFix or the AI CodeFix feature before pushing to your SCM, so the code meets your quality standards and is safe for running in production.

The educational framing is explicit too. The readme says the tool turns into your personal coding tutor by giving you the why behind each issue with detailed contextual information, so you level up your skills rather than just silencing warnings.

The repository metadata reflects the shift. The package is still named sonarlint-vscode, but the displayName is SonarQube for IDE, the description calls it an advanced linter to detect and fix coding issues locally in JS/TS, Python, Java, C#, C/C++, Go and PHP, and the keywords list has been widened to include AI, language-model-tools and IaC alongside the language names. The categories include Linters, Education, Programming Languages, Notebooks and AI.

The licence is the GNU Lesser General Public License, Version 3.0, with the copyright held by SonarSource, and the package metadata carries a SEE LICENSE IN LICENSE.txt placeholder rather than an SPDX identifier.

Local analysis needs no server, and the connected mode is what changes

There are two ways to use the extension, and the difference between them decides which rules you get.

On its own, the extension works locally. The readme describes the flow as simply opening any source file, starting to code, and seeing issues reported. Issues are highlighted in the code and also listed in the Problems panel, and you can access the detailed rule description directly from the editor through the provided contextual menu.

The connected mode links the IDE to SonarQube Server or SonarQube Cloud, and the readme is careful about what that buys. The connection enables sharing of consistent language rulesets and project settings, and it unlocks analysis of deeply hidden security issues, fostering collaboration and code uniformity. Concretely, connected mode unlocks analysis of languages such as COBOL, Apex, PL/SQL, T-SQL, Ansible, Shell, Azure Pipelines and Rust.

So the trade is clear. Standalone, you get a fast local linter over a solid set of languages: C, C++, Java, Go, Rust, JavaScript, TypeScript, Python, C#, HTML, CSS, PHP, Kubernetes, Docker and PL/SQL, with a pointer to the documentation for the complete list of supported languages, rules and secret detection capabilities.

Connected, you get the same analyser but with your organisation's rule set and configuration, and a much wider language coverage, at the cost of a server to run or a SonarQube Cloud account, which the readme notes is free to create.

One piece of configuration in the package manifest is worth reading, because it shows the migration path for existing users. The sonarlint.connectedMode.servers setting carries a deprecation message saying that the setting is deprecated and that you should use sonarlint.connectedMode.connections.sonarqube or sonarlint.connectedMode.connections.sonarcloud instead. The old single-servers array has become two named connections.

A large TypeScript codebase with a webview and a dogfood folder

The repository layout shows a substantial extension rather than a thin wrapper, and a few of the entries explain how the project is worked on.

There is a src/ directory for the extension source, a webview-ui/ directory for the panels the extension renders, styles/ for the CSS, a walkthrough/ directory which is the VS Code walkthrough mechanism, icons/ and images/ for assets, and a docs/ directory. The build is driven by webpack with a webpack.config.js at the root and the TypeScript compiled by tsconfig.json.

The two directories that say something about the project's own practices are dogfood/ and .sonarlint/. The first is the project running its own analyser on its own code, and the second is the configuration for that. There is a sonar-project.properties at the root, a sonarsource-public.key file, and a .npmrc, so the build environment is pinned as well as configured.

There is also a test/ directory, an its/ directory, a build-sonarlint/ directory, and a runext.sh and runits.sh pair, which are the scripts for running the extension in different modes during development. The mise.toml pins the toolchain, and a .vscode/ directory and a sonarlint-vscode.code-workspace file hold the editor configuration. CHANGELOG.md, SECURITY.md, NOTICE.txt, LICENSE.txt and develop.md complete the root.

The primary language of the repository is recorded as CSS, which is a quirk of the statistics rather than a statement about the project, since the code is TypeScript with a webpack build and a webview. The version in the package manifest is 6.2.0, and the three most recent release tags are 6.1.1+91162 from 2026-10-14, 6.1.0+91156 from 2026-10-12 and 6.0.1+91054 from 2026-09-30, so releases are frequent and the trailing number tracks an internal build.

Installation and the two pages you need first

The getting started section is deliberately short, because the detail lives in the product documentation rather than in the repository.

It says to check the Requirements and Installation pages, download SonarQube for IDE in the Extension Marketplace, and enjoy safe coding. The requirement pages are linked to the SonarSource documentation site, and they are where you find the version of Visual Studio Code the extension expects.

That expectation is visible in the package manifest, where the engines field declares a VS Code version constraint of 1.100.0 or later, and the extension activates on startup finished rather than on a specific command. Activation on startup is a meaningful choice for a linter: it means the analysis is ready as soon as you open the editor, and it also means the extension is running for every project you open, which is the fact that makes the telemetry setting worth checking against your policy.

The manifest also declares that the extension does not support virtual workspaces, and it registers the configuration properties for the connected mode under a SonarLint titled configuration section, which is a leftover from the previous product name in the same way as the telemetry setting name.

The licence and the installation path are both simple things to find: the LGPL version 3.0 text is linked at the bottom of the readme, and the extension comes from the Extension Marketplace rather than from a build in this repository.

Outside contributions are limited to cosmetics, and telemetry is on by default

Two things in the readme are worth reading carefully before you plan to use or contribute to the extension.

The first is the contribution policy, which is unusually blunt. The readme says it is extremely difficult for someone outside SonarSource to comply with the roadmap and expectations, and that the project typically only accepts minor cosmetic changes and typo fixes. There is a community forum thread where the team plays Product Manager for a day, and a note about why the old Suggest New Features category was deprecated. Code contributions are still welcome, as pull requests, but you are asked to explain the problem you are fixing and the improvement you are making, to follow the code style, and to make sure all tests are passing.

The second is telemetry. The extension collects anonymous usage data and sends it to SonarSource to help improve the functionality. No source code or IP address is collected, and SonarSource does not share the data with anyone else. Collection is controlled through a setting, sonarlint.disableTelemetry, and a telemetry-sample.md file in the repository shows a sample of what is collected.

That is a reasonable position for a vendor tool, and the sample file is the kind of thing that lets an organisation check the claim rather than take it on trust. But it is a real consideration, because the setting name still carries the old product name, and because an extension that reports on your code as you type is a natural target for a security review.

For support questions, the readme points to the FAQ and the Sonar forum, with the usual forum etiquette, and the issue tracker is read only, hosted on JIRA under the SLVSCODE project.

Editorial conclusion

SonarQube for IDE suits a developer who wants security and quality findings in the editor before code reaches review, and a team that already runs SonarQube Server or Cloud and wants the same rules locally. It does not suit a team that wants the extension to replace server-side analysis, since the connected mode exists to complement that, and the project is explicit that it accepts only minor cosmetic changes and typo fixes from outside contributors. Before adopting it, read the requirements and installation pages, decide whether you want the standalone local analysis or the connected mode, and set the telemetry switch if your policy requires it off.

Frequently asked questions

Official sources

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