# What other open-source analysers do you use?

**URL:** <https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541>\
**Category:** Discussions\
**Created:** [October 17, 2022, 6:00am UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541 "2022-10-17T06:00:19Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\
**Post date:** [October 17, 2022, 6:00am UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/1 "2022-10-17T06:00:19Z")

</div>

Sonar provides powerful static analysis: [4800+ rules over 30 programming languages](https://rules.sonarsource.com/)!

And, both SonarQube and SonarCloud play well with other open-source code analysis tools by allowing developers to [Import Third-Party issues](https://docs.sonarqube.org/latest/analysis/external-issues/), both in formats produced by those tools or via the [Generic Issue Import Format](https://docs.sonarqube.org/latest/analysis/generic-issue/).

This means that issues raised by these tools will fit into Sonar’s [Clean as you Code](https://docs.sonarqube.org/latest/user-guide/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!

---

<div class="post-metadata">

**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\
**Post date:** [October 17, 2022, 8:11am UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/2 "2022-10-17T08:11:24Z")

</div>



---

<div class="post-metadata">

**Author:** ![ganncamp](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ganncamp/32/1261_2.png) [@ganncamp](https://community.sonarsource.com/u/ganncamp)\
**Post date:** [October 19, 2022, 2:21pm UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/3 "2022-10-19T14:21:01Z")

</div>

3 posts were split to a new topic: [Trouble with FortifyVulnerabilityExporter in Sonarqube version 8.9](https://community.sonarsource.com/t/trouble-with-fortifyvulnerabilityexporter-in-sonarqube-version-8-9/74762)

---

<div class="post-metadata">

**Author:** ![tbutler](https://avatars.discourse-cdn.com/v4/letter/t/c77e96/32.png) [@tbutler](https://community.sonarsource.com/u/tbutler)\
**Post date:** [March 23, 2023, 9:07am UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/4 "2023-03-23T09:07:35Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![gab](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/gab/32/72206_2.png) [@gab](https://community.sonarsource.com/u/gab)\
**Post date:** [March 23, 2023, 6:26pm UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/6 "2023-03-23T18:26:58Z")

</div>

Hi @tbutler, do you mind sharing what rules you are using in ESLint along with Sonar?

---

<div class="post-metadata">

**Author:** ![tbutler](https://avatars.discourse-cdn.com/v4/letter/t/c77e96/32.png) [@tbutler](https://community.sonarsource.com/u/tbutler)\
**Post date:** [March 24, 2023, 7:48am UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/7 "2023-03-24T07:48:22Z")

</div>

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:

```auto
    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'
    ],

```

---

<div class="post-metadata">

**Author:** ![gtoison](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/gtoison/32/51877_2.png) [@gtoison](https://community.sonarsource.com/u/gtoison)\
**Post date:** [March 27, 2023, 4:53pm UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/8 "2023-03-27T16:53:14Z")

</div>

I’m using Google’s error-prone. In order to manage the rules and the false positives I’ve resorted to make a sonar plugin. Showing the rule description from inside the SonarQube interface really helps (I believe it is not possible when importing third-party issues).

> **[GitHub - erroraway/sonar-erroraway-plugin: Analyze Java Code with ErrorProne...](https://github.com/erroraway/sonar-erroraway-plugin)**
>
> Analyze Java Code with ErrorProne in SonarQube. Contribute to erroraway/sonar-erroraway-plugin development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![sodul](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/sodul/32/6385_2.png) [@sodul](https://community.sonarsource.com/u/sodul)\
**Post date:** [April 20, 2023, 10:42pm UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/10 "2023-04-20T22:42:00Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ganncamp](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ganncamp/32/1261_2.png) [@ganncamp](https://community.sonarsource.com/u/ganncamp)\
**Post date:** [April 21, 2023, 12:43pm UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/12 "2023-04-21T12:43:42Z")

</div>

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.

&nbsp;  
Ann

---

<div class="post-metadata">

**Author:** ![Corniel](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/corniel/32/10101_2.png) [@Corniel](https://community.sonarsource.com/u/Corniel)\
**Post date:** [June 27, 2023, 10:51am UTC](https://community.sonarsource.com/t/what-other-open-source-analysers-do-you-use/74541/13 "2023-06-27T10:51:53Z")

</div>

At our (C#/.NET orriented) company, we use both XUnit, and NUnit (depending on the preference of the team), and [FluentAssertions](https://fluentassertions.com/) for our test projects. All of them have there own Roslyn analyzers:

- [NuGet Gallery | FluentAssertions.Analyzers 0.20.0](https://www.nuget.org/packages/FluentAssertions.Analyzers)
- [NuGet Gallery | NUnit.Analyzers 3.6.1](https://www.nuget.org/packages/NUnit.Analyzers)
- [NuGet Gallery | xunit.analyzers 1.1.0](https://www.nuget.org/packages/xunit.analyzers)

We use [AsyncFixer](https://github.com/semihokur/AsyncFixer) that deals with the most common errors made while dealing with async/await.

- [NuGet Gallery | AsyncFixer 1.6.0](https://www.nuget.org/packages/AsyncFixer)

We use (a limited subset of) StyleCop for some coding style enforcement:

- [NuGet Gallery | StyleCop.Analyzers 1.1.118](https://www.nuget.org/packages/StyleCop.Analyzers)

We use [Qowaiv.Analyzers](https://github.com/Qowaiv/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](https://www.nuget.org/packages/Qowaiv.Analyzers.CSharp)
