My TypeScript project uses absolute imports. We have just added SonarQube to our org, and it is reporting code smells for all of our internal module imports as:
import MyComponent from 'components/MyComponent';
import { Some, Other, Components } from 'components/SomeOtherComponents';
import { helperFcn } from 'lib/utils';
etc
SonarQube insists:
Either remove this import or add it as a dependency.
Dependencies should be explicitly listed in the package.json file. Importing a module that is not declared as a dependency makes it an implicit one and is bound to create problems.
potential workaround
Mark as false positive
questions
Is there a way to whitelist internal modules for imports, as you can with eslint, or do I have to manually mark all of these as false positives as they come up?
Thank you for your message, and welcome to our community!
I just updated RSPEC-4328 that was missing the information you were looking for. You can actually configure the rule with a whitelist property.
As mentioned in the rule description, the property takes a comma separated list of modules to ignore. In your particular case, it would be "components, lib".
Thank you @Yassin, very helpful! I’m not quite sure where the whitelist is, or where to include the whitelist property. Is it something that requires admin access in the SonarQube UI?
I hope @Yassin doesn’t mind me assisting here since I was just playing with this feature as well.
You can add a comma separated list of modules to ignore when the SonarScanner analyzes the package.json file. To do that, you need to have admin access or be given permission selectively by your admin to your user.
Click on “Rules” menu at the top.
Search “s4328” in the filter box.
Click on the “Dependencies should be explicit” rule.
In the “Quality Profiles” section with the “Activate” button, click on the “Change” button next to the quality profile that you desire.
Add your list of modules to the “whitelist” field and click “Save”.
Yes, but it will require a bit more effort and awareness. You can create a custom Quality Profile with S4328 rule active with your whitelist then activate the Quality Profile for that project only.
Can this whitelist be specified in sonar-project.properties?
We have many projects that each have different module resolution approaches, creating a Quality profile for every single one can be tedious especially considering that devs don’t have that kind of permissions in sonarqube dashboard. Plus they can be changed as project evolves, then a simple whitelist change will require submitting a ticket and waiting for who knows how long because it has a very low priority.
This looks like a perfect case for something that should be configurable vis sonar-project.properties file, no?
No it cannot, as far as I know. Prior to SonarQube 7.9, we used to have a sonar.profile parameter that you could pass at analysis time (and hence with sonar-project.properties file), but with 7.9 we removed this parameter.
sonar.profile could only select a single Quality Profile (for a single language). This does not match the multi-language nature of many software projects today, so your current or future projects will not be properly analyzed by the correct Quality profile for each language.
The Quality Profile of a project should not change very often, therefore it isn’t necessary to be passed as an analysis parameter (and should be set on the Server).
Pre-provisioning SonarQube projects in the UI (prior to analysis) and applying necessary configuration is also considered by us to be a best practice.
The burden of updating the quality profile for a project must be on the project owner (or whoever has Administer quality profile permisson) to modify the quality profile for the language of a given project. You can use the Web API (link in the footer of the UI or in the (?) icon next to the search field in the top right-hand corner of the UI) and use these 2 endpoints:
POST api/qualityprofiles/remove_project (Remove a project’s association with a quality profile)
POST api/qualityprofiles/add_project (Associate a project with a quality profile)
This will allow you to change it quickly, without using the UI, and then continue the analysis with the new quality profile and change it back if you want to. The quality profile shouldn’t change too often so you shouldn’t need this as a permanent fixture in your analysis workflow.
