eslint-plugin-sonarjs

What is eslint-plugin-sonarjs?

eslint-plugin-sonarjs is an ESLint plugin that provides a set of rules inspired by SonarQube to detect bugs and suspicious patterns in JavaScript code. It aims to improve code quality by identifying potential issues early in the development process.

What are eslint-plugin-sonarjs's main functionalities?

Detecting Cognitive Complexity

This rule helps to keep functions simple and maintainable by enforcing a limit on their cognitive complexity. The code sample configures ESLint to throw an error if a function's cognitive complexity exceeds 15.

module.exports = {
  rules: {
    'sonarjs/cognitive-complexity': ['error', 15]
  }
};

Detecting Duplicated Code

This rule detects duplicated string literals in the code. The code sample configures ESLint to throw an error if a string literal is duplicated more than 3 times.

module.exports = {
  rules: {
    'sonarjs/no-duplicate-string': ['error', 3]
  }
};

Detecting Unused Function Parameters

This rule identifies function parameters that are declared but not used within the function body. The code sample configures ESLint to throw an error for any unused function parameters.

module.exports = {
  rules: {
    'sonarjs/no-unused-collection': 'error'
  }
};

Detecting Collapsible If Statements

This rule detects if statements that can be collapsed into a single statement. The code sample configures ESLint to throw an error for any collapsible if statements.

module.exports = {
  rules: {
    'sonarjs/no-collapsible-if': 'error'
  }
};

Other packages similar to eslint-plugin-sonarjs

eslint-plugin-jsx-a11y

eslint-plugin-jsx-a11y is an ESLint plugin that provides accessibility checks for JSX elements. It helps developers to write accessible code by enforcing best practices and identifying potential accessibility issues. Unlike eslint-plugin-sonarjs, which focuses on code quality and bug detection, eslint-plugin-jsx-a11y is specifically aimed at improving accessibility in web applications.

eslint-plugin-security

eslint-plugin-security is an ESLint plugin that identifies potential security vulnerabilities in JavaScript code. It includes rules to detect common security issues such as the use of eval, insecure randomness, and potential command injection. While eslint-plugin-sonarjs focuses on general code quality and bug detection, eslint-plugin-security is specialized in identifying security-related issues.

eslint-plugin-unicorn

eslint-plugin-unicorn is an ESLint plugin that enforces various best practices and code quality improvements. It includes a wide range of rules for improving code readability, maintainability, and performance. Compared to eslint-plugin-sonarjs, eslint-plugin-unicorn offers a broader set of rules that cover more aspects of code quality, including stylistic preferences and performance optimizations.

README

eslint-plugin-sonarjs

SonarJS rules for ESLint to help developers produce Clean Code by detecting bugs and suspicious patterns.

Rules

Bug Detection :bug:

Rules in this category aim to find places in code that have a high chance of being bugs, i.e. don't work as intended.

• All branches in a conditional structure should not have exactly the same implementation (no-all-duplicated-branches)
• Collection elements should not be replaced unconditionally (no-element-overwrite)
• Empty collections should not be accessed or iterated (no-empty-collection)
• Function calls should not pass extra arguments (no-extra-arguments)
• Related "if/else if" statements should not have the same condition (no-identical-conditions)
• Identical expressions should not be used on both sides of a binary operator (no-identical-expressions)
• Return values from functions without side effects should not be ignored (no-ignored-return) (uses-types)
• Loops with at most one iteration should be refactored (no-one-iteration-loop)
• The output of functions that don't return anything should not be used (no-use-of-empty-return-value)
• Non-existent operators '=+', '=-' and '=!' should not be used (non-existent-operator) (:wrench: fixable)

Code Smell Detection :pig:

Code Smells, or maintainability issues, are raised for places of code which might be costly to change in the future. These rules also help to keep the high code quality and readability. And finally, some rules report issues on different suspicious code patterns.

• Cognitive Complexity of functions should not be too high (cognitive-complexity)
• "if ... else if" constructs should end with "else" clauses (elseif-without-else) (disabled)
• "switch" statements should not have too many "case" clauses (max-switch-cases)
• Collapsible "if" statements should be merged (no-collapsible-if)
• Collection sizes and array length comparisons should make sense (no-collection-size-mischeck) (:wrench: fixable, uses-types)
• String literals should not be duplicated (no-duplicate-string)
• Two branches in a conditional structure should not have exactly the same implementation (no-duplicated-branches)
• Boolean expressions should not be gratuitous (no-gratuitous-expressions)
• Functions should not have identical implementations (no-identical-functions)
• Boolean checks should not be inverted (no-inverted-boolean-check) (:wrench: fixable, disabled)
• "switch" statements should not be nested (no-nested-switch)
• Template literals should not be nested (no-nested-template-literals)
• Boolean literals should not be redundant (no-redundant-boolean)
• Jump statements should not be redundant (no-redundant-jump) (:wrench: fixable)
• Conditionals should start on new lines (no-same-line-conditional) (:wrench: fixable)
• "switch" statements should have at least 3 "case" clauses (no-small-switch)
• Collection and array contents should be used (no-unused-collection)
• "catch" clauses should do more than rethrow (no-useless-catch)
• Local variables should not be declared and then immediately returned or thrown (prefer-immediate-return) (:wrench: fixable)
• Object literal syntax should be used (prefer-object-literal)
• Return of boolean expressions should not be wrapped into an "if-then-else" statement (prefer-single-boolean-return) (:wrench: fixable)
• A "while" loop should be used instead of a "for" loop (prefer-while) (:wrench: fixable)

Prerequisites

• Node.js (>=12.x).
• ESLint 5.x, 6.x, 7.x or 8.x (peer dependency for the plugin).

Usage

• If you don't have ESLint yet configured for your project, follow these instructions.
• Install eslint-plugin-sonarjs using npm (or yarn) for your project or globally:

npm install eslint-plugin-sonarjs --save-dev # install for your project
npm install eslint-plugin-sonarjs -g         # or install globally

• Add eslint-plugin-sonarjs to the plugins option of your .eslintrc:

{
  "plugins": ["sonarjs"]
}

• Add plugin:sonarjs/recommended to the extends option to enable all recommended rules:

{
  "extends": ["plugin:sonarjs/recommended"]
}

• or enable only some rules manually:

{
  "rules": {
    "sonarjs/cognitive-complexity": "error",
    "sonarjs/no-identical-expressions": "error"
    // etc.
  }
}

• To enable all rules of this plugin, use @typescript-eslint/parser as a parser for ESLint (like we do) and set the parserOptions.project option. Thanks to it, type information is available, which is beneficial or even essential for some rules.

Available Configurations

This plugin provides only a recommended configuration. Almost all rules are activated in this profile with a few exceptions (check the disabled tag in the rules list). The recommended configuration activates rules with error severity.

ESLint and Sonar

This plugin exposes to ESLint users a subset of JS/TS rules from Sonar-* products (aka SonarJS). We extracted the rules that are not available in ESLint core or other ESLint plugins to be beneficial for the ESLint community.

If you are a SonarQube or SonarCloud user, to lint your code locally, we suggest using SonarLint IDE extension (available for VSCode, JetBrains IDEs and Eclipse). You can connect SonarLint to your SonarQube/SonarCloud project to synchronize rules configuration, issue statuses, etc.

Contributing

Do you want to participate in the development of the project? Have a look at our contributing guide!