As described in
MMF-365, we’ve decided to stop supporting modules in our ecosystem: SonarQube, SonarCloud and SonarLint.
Currently, in VSCode, connecting a project to SonarQube/SonarCloud consists in binding a workspace to a single remote project. And, if the files structure in the workspace doesn't exactly match the project in SonarQube, the mechanism to synchronize and hide won't fix/false positive issues doesn't work well. This is for example the case for multi-modules projects.
When modules will disappear from SonarQube, the project structure in SonarQube should naturally match the filesystem. SonarLint for VSCode should be able to properly track issues for any project that is opened as a workspace.
Still, users who work with big projects are likely to open only a few selected project folders in their workspace. In many cases, the issues tracking mechanism won't work properly.
We should remove this limitation: the connected mode should properly work for any folder that is part of a bound workspace.
We'll use a mechanism similar with was done for IntelliJ and Eclipse, and find the prefixes to be used to match local folders with folders in SonarQube.
From a user point of view, the change should be seamless:
- After the upgrade, when the user opens a project, SonarLint will invalidate the storage and will require an update of the binding. It may not be even needed.
- From there, SonarLint should properly match local files with the remote ones, and issue tracking will start working where previously it was not the case.
We see 3 distinct feature levels:
- Level 1: user has a workspace with several sub-folders that are linked to the same SonarQube project - at this point the settings can be set at workspace level
- Level 2: user has a workspace with folders that are linked to several projects in the same SonarQube instance - at this point, the settings have to be set at folder level
- Level 3: user has a workspace with folders that are linked to projects in several SonarQube instances - this level also requires that settings are set at folder level
This MMF is solely about supporting Level 1.
- SonarLint will look at the filesystem to know local folders, and then use the core API to find, for each folder, the prefix that can be used to match remote files paths.
- Each time a new folder is added to the workspace, the mechanism will be triggered to find the corresponding prefix.
- SonarLint might not need to store this prefix (in folder settings? in the storage?). It could be computed again each time folders are opened.
- Specific files/folders could directly excluded from this computation: node modules, binaries, etc - check whether there is an API to check for ignored/generated files