SonarJS is integrated inside of SonarLint IDE extension. It is available for WebStorm/IntelliJ, Visual Studio, VS Code, Atom and Eclipse.
SonarJS is integrated inside of sonarcloud.io, an online service for continuous code quality. To set up analysis of your project, follow instructions on this page.
SonarQube is an open-source platform for continuous inspection of code quality. Assuming you have SonarQube installed and running, choose the scanner and configure your project accordingly.
- SonarQube Scanner is a basic scanner using the configuration file
sonar-project.propertiesin the project root directory to perform analysis.
Example of sonar-project.properties
sonar.projectKey=my:project
sonar.projectName=My project
sonar.projectVersion=1.0
sonar.sources=srcThere are many more properties that can be provided, see general properties and javascript-specific properties. Once this file is created and scanner is installed, run the following command from the project base directory to launch the analysis
sonar-scanner
- SonarQube Scanner for JavaScript relies on
package.jsonfile to set up all the analysis properties, such as project name, version etc. You can find an example of project using this scanner here (it's a TypeScript project, but there is no difference in use).
We recommend to set the version of the project manually through script file to not depend on the one from
package.json(like this). That way you will be able to profit from a correct leak period and focus on quality issues introduced since last release.
❗ To perform analysis SonarJS requires Node.js >=6
| Property | Example | Description |
|---|---|---|
sonar.nodejs.executable |
/Users/John/bin/node |
Set this property to absolute path to Node.js executable, if standard node is not available. |
| Property | Example | Description |
|---|---|---|
sonar.javascript.file.suffixes |
.jsx | Comma-separated list of suffixes for files to analyze. Default value is ".js,.jsx,.vue". |
| Property | Example | Description |
|---|---|---|
sonar.javascript.jQueryObjectAliases |
$, jQuery, jQ | Comma-separated list of names used to address jQuery object. Default value is "$, jQuery". NOTE These names are used only to detect jQuery usages, they are not used to build the list of globals. |
sonar.javascript.environments |
browser, jquery, amd | Comma-separated list of environments names. The analyzer automatically adds global variables based on that list. |
sonar.javascript.globals |
Backbone, IS_DEBUG | Comma-separated list of global variables. Default value is "angular,goog,google,OpenLayers,d3,dojo,dojox,dijit,Backbone,moment,casper". |
Available environment names for sonar.javascript.environments: amd, applescript, atomtest, browser, commonjs, couch, embertest, flow, greasemonkey, jasmine, jest, jquery, meteor, mocha, mongo, nashorn, node, phantomjs, prototypejs, protractor, qunit, rhino, serviceworker, shared-node-browser, shelljs, webextensions, worker, wsh, yui. By default all environments are included.
SonarJS does not generate its own test coverage report, but re-uses the one generated by LCOV. Prior to the analysis, execute your unit tests and generate the LCOV report(s). Import the report(s) while running the analysis by providing the paths of the LCOV report through the following properties. The paths may be absolute or relative to the project base directory.
| Property | Description |
|---|---|
sonar.javascript.lcov.reportPaths |
comma-separated list of paths to LCOV coverage report files |
SonarJS enables the import of ESLint reports into SonarQube. In order to do this, run eslint with the JSON formatter and write the resulting report into a file. Here is an example of such a command:
$ eslint -f json -o report.json .
Once the report is created, add the following property to the SonarQube Scanner configuration:
| Property | Description |
|---|---|
sonar.eslint.reportPaths |
comma-separated list of paths (absolute or relative) to the JSON files with ESLint issues. |
You can now run the SonarQube Scanner and all the issues will be imported. Note that the next time you run the scanner, all issues which disappeared from the ESLint report will also be removed from the SonarQube reports.
Note that this feature requires SQ 7.2 or later.
Starting from version 3.3, by default SonarJS ignores any files located inside folders called node_modules and bower_components. This can be changed by setting the following property.
| Property | Description |
|---|---|
sonar.javascript.exclusions |
comma-separated list of path patterns to exclude from analysis. Default value is **/node_modules/**,**/bower_components/**. |
SonarJS provides 2 rule profiles out of the box: Sonar way (default) and Sonar way Recommended.
Sonar way profile is activated by default. It defines a trimmed list of high-value/low-noise rules useful in almost any JS development context. You can check out the list of rules belonging to Sonar way on SonarCloud.
Sonar way Recommended contains all rules from Sonar way (bugs and pitfall detection), plus more rules that mandate high code readability and long-term project evolution. You can check out the list of rules belonging to Sonar way Recommended on SonarCloud.
By using SonarQube/SonarCloud UI you can create your own rule profiles and activate even more rules which are valuable in your development context. We recommend you to look at the following rules, which are highly valuable but whose activation depends on your environment, coding principles or requires some configuration.
- "Non-existent properties should not be read" S3759 (should be activated if you don't use monkey patching)
- "Non-existent variables should not be referenced" S3827 (requires configuration)
- "Objects should not be created to be dropped immediately without being used" ConstructorFunctionsForSideEffects (activate, if you agree that constructors should not have side effects)
- "Variables should be declared with "let" or "const"" S3504. Activate, if you use ES2015. Find more rules with tag "es2015".
- "Variables should be defined in the blocks where they are used" S2392 (forces you to declare variables in the most narrow scope)
- "Variables should not be shadowed" VariableShadowing (forces you to not shadow variables declared in outer scope)
Have a question and can't find it here, create an issue!
A: Import of unit tests is not provided by SonarJS, and it's provided by SonarQube/SonarCloud itself (since v6.2). Here is documentation about it.
A: You may disable coverage metrics for some source files by setting sonar.coverage.exclusions.
A: Here is some documentation on how to write custom rules.