Sonar provides powerful static analysis: 4800+ rules over 30 programming languages !

And, both SonarQube and SonarCloud play well with other open-source code analysis tools by allowing developers to Import Third-Party issues , both in formats produced by those tools or via the Generic Issue Import Format .

This means that issues raised by these tools will fit into Sonar’s Clean as you Code methodology: and benefit from features like issue backdating (the issue is considered to have been created at the last commit of a line, not the first time it’s reported to Sonar).

Additionally, this is even Sonar’s recommended way to design custom rules for some languages: such as building custom rules for JavaScript/TypeScript with ESLint and importing the issues.

Are you importing third-party issue reports into Sonar? From which tools? Is Sonar missing support for any that would really help your workflow? Let us know!

eslint, tflint, tfsec, pylint.roslyn are the main 3rd party rules we are importing.

The biggest problem with 3rd party support at the moment is that you have no ability to mark specific issues as “False Positive” or “won’t fix” or indeed ideally also to disable some of the rules completely, just as we could with native rules. Going further, to be able to attach descriptions/links to descriptions on the web would be great too.

If you import 3rd party results then violations will always show unless you fix them…and if you never intend on fixing them then they will always show, which isn’t great.

I understand that managing the rules globally (in profiles) might be a harder task but it seems like being able to mark a single instance of a violation as fixed/won’t fix/false positive should be relatively easy to achieve.

Of course it would be ideal if Sonar nativelysupported all the popular rule sets that are in use today for the various languages but that is likely not achievable…however improving the treatment of third party rules should be!

My apologies - I thought the work to integrate eslint had been done but not yet. but if it helps, the .eslint.js file being used for linting, which will be imported into Sonar at some point, contains this section:

    rules: {
        '@typescript-eslint/explicit-function-return-type': 'off',
        '@typescript-eslint/explicit-module-boundary-types': 'error',
        '@typescript-eslint/interface-name-prefix': 'off',
        '@typescript-eslint/no-explicit-any': showError ? 'error' : 'off',
        '@typescript-eslint/no-use-before-define': 'off',
        '@typescript-eslint/no-unused-vars': ['error', { varsIgnorePattern: '^_', argsIgnorePattern: '^_' }],
        'semi': ['error'],
        'no-multiple-empty-lines': ["error", { "max": 2, "maxBOF": 1 }],
        'eqeqeq': ["error", "always"],
        'getter-return': 'error',
        'no-compare-neg-zero': 'error',
        'quotes': ['error', 'single', { 'avoidEscape': true, 'allowTemplateLiterals': true }],
        '@typescript-eslint/ban-types': ['error', {
            types: {
                Function: false,
                Object: false,
                object: false,
                '{}': false
        '@typescript-eslint/member-ordering': 'error',
        '@typescript-eslint/explicit-member-accessibility': 'error',
        'comma-dangle': 'off',
        '@typescript-eslint/comma-dangle': ['error', 'only-multiline']
    extends: [
        'eslint:recommended',
        'plugin:@typescript-eslint/eslint-recommended',
        'plugin:@typescript-eslint/recommended'
              
For go we use golangci-lint and pass the reports to Sonar where they are all consumed as the same type and severity. Being able to map some of the reported rules as security, bugs and different levels would be nice, but at the very least this help our Go developers get hints about improving the code during the PRs.
For python we use mypy and pylint. We are considering ruff which is very fast. One thing we do is that we have our our wrapper to call these tools and in the case of pylint we added support to silence pre-existing issues. This allows us to upgrade to newer versions of pylint without breaking the CI pipelines, yet prevent new issues to come in and not having to update dozens of files with ignore notation.
              
Hi @sodul,
Thanks for your input. I think the challenges you’ve faced with importing those external issue reports are interesting & I’ve flagged this internally.
              
At our (C#/.NET orriented) company, we use both XUnit, and NUnit (depending on the preference of the team), and FluentAssertions for our test projects. All of them have there own Roslyn analyzers:
NuGet Gallery | FluentAssertions.Analyzers 0.20.0
NuGet Gallery | NUnit.Analyzers 3.6.1
NuGet Gallery | xunit.analyzers 1.1.0
We use AsyncFixer that deals with the most common errors made while dealing with async/await.
NuGet Gallery | AsyncFixer 1.6.0
We use (a limited subset of) StyleCop for some coding style enforcement:
NuGet Gallery | StyleCop.Analyzers 1.1.118
We use Qowaiv.Analyzers (my own analyzer) to enforce some coding guidelines (like sealing classes, decorating pure classes (for libraries only), and not over using Nullable<T>. In short, all rules I think are useful, but have (because they are not universal) have no place in Sonar (or another) existing analyzer.
NuGet Gallery | Qowaiv.Analyzers.CSharp 0.0.8