SonarLint support for Monorepo for VS Code Connected Mode

[JulianCANCOM (Julian)]

We often implement monorepos with NX. It would be nice if you can easily config such a monorepo in the connected mode in VS Code.

Current possible solution

If I want to use the connected mode I would have to add each project as an extra project to my VS Code workspace. This is anoying and is not a nice way to set up Sonar.

Current VS Code extension config (.vscode/settings.json):

{
  "sonarlint.connectedMode.project": {
    "connectionId": "my-company",
    "projectKey": "my-company:my-ado-project:my-repo:mono:my-inner-project1"
  }
}

Expected behaviour

In the config of the SonarLint extension it should be possible to config multiple Sonar projects and add a file path which this belongs to. In this way you only have to add a monorepo as a single project in your VS Code workspace which gives the user more overview over his monorepo.

Possible new VS Code extension configs (.vscode/settings.json):

Single Sonar config:

{
  "sonarlint.connectedMode.project": {
    "connectionId": "my-company",
    "projectKey": "my-company:my-ado-project:my-repo:mono:my-inner-project1"
  }
}

Monorepo:
Single Sonar config:

{
  "sonarlint.connectedMode.projects": [
    {
      "connectionId": "my-company",
      "projectKey": "my-company:my-ado-project:my-repo:mono:my-inner-project1",
      "path": "path/to/my-inner-project1"
    },
    {
      "connectionId": "my-company",
      "projectKey": "my-company:my-ado-project:my-repo:mono:my-inner-project2",
      "path": "path/to/my-inner-project2"
    }
  ]
}

[Colin]

Hey there.

I think what you’re trying to accomplish can be solved by having a multi-root workspace. Take a look here and let me know!

Binding multiple projects and nested projects

Hello, welcome to the community! And thank you for asking. I would recommend creating a multi-root workspace. You can start with your current project-A folder open, then use File > Add Folder to Workspace... to add project-B as a separate workspace folder. You can then use File > Save Workspace As... to save this workspace layout and have it automatically reopened the next time you start the IDE. This way, each workspace folder is seen by the IDE as a separate configuration scope, and each c…

[gregoryorton-ws (Gregory Orton)]

Hi Colin - IMO this is not a reasonable solution. Mono repos use shared code and import from path in parent folders like “../../libs/…” etc, and mono repo work often crosses project boundaries for configuration and package installation purposes.

We also use NX and NX commands are also run from the project root, such that nx run my-app:test will not corectly run from a mono-repo project folder, only the mono-repo root.

This is at best a workaround. You sell sonarqube cloud as having “full monorepo” support - so please update your extension to actually support monorepos.

This suggestion from Julian is exactly what is required. Please notify us when you complete the support so we can actually use the product.

@JulianCANCOM

Monorepo:
Single Sonar config:

{
  "sonarlint.connectedMode.projects": [
    {
      "connectionId": "my-company",
      "projectKey": "my-company:my-ado-project:my-repo:mono:my-inner-project1",
      "path": "path/to/my-inner-project1"
    },
    {
      "connectionId": "my-company",
      "projectKey": "my-company:my-ado-project:my-repo:mono:my-inner-project2",
      "path": "path/to/my-inner-project2"
    }
  ]
}

[JulianCANCOM (Julian)]

Hi Colin,
for me your suggested solution is not really practicable. As Gregory also mentioned, monorepos, especially NX projects, need to perform actions on root site and so setting up a multi-root workspace is not the solution for this problem.

I am sure my suggested change is the solution for a lot of programmers out there.

[sdalonzo (Steve Dalonzo)]

I’d like to echo support for the original request. Multi-root workspaces are not desirable for us for reasons that are not negotiable, especially in this agentic age — agentic coding tools like Claude Code require a single-root workspace to operate effectively across a monorepo.

I’m not an NX user — I’m a RushJS user — but the proposal here would work for both Rush and NX users, representing a pretty significant proportion of large monorepos in use.

We have ~350 projects in our Rush monorepo with different owners and infosec gating deployments on per-project quality gates. We’ve built a custom CI implementation that works reliably, but it has painful gaps that better IDE integration would help offset:

• To dynamically scan only the projects with changes, we run a separate workflow_dispatch per affected project — duplicating checkout and dependency installation overhead each time, even when build artifacts and coverage reports come from cache.
• The PR comments posted by the SonarQube GitHub Action don’t indicate which project was scanned until you click through. For categories of work that monorepos make vastly more efficient — dependency upgrades, migrations — it’s infuriating to see dozens of identical-looking comments with no project key attribution.

[kussberg (Edgar)]

Thank you @sdalonzo for the insights. Let me check with the team on how could we improve the binding mechanism.

[Florian_Mutter]

We also need this. We have a mono repo with ~100 services where each service has its own sonar project.