SonarTS

Static code analyzer for TypeScript detecting bugs and suspicious patterns in your code.

How does it work?

The TypeScript compiler provides AST and type information
On top of it we build the symbol model and the control flow model
Some rules are based on AST equivalence (like no-all-duplicated-branches or no-identical-expressions).
And finally we use live variable analysis to detect dead stores

Rules

Getters and setters should access the expected fields (no-accessor-field-mismatch)
All branches in a conditional structure should not have exactly the same implementation (no-all-duplicated-branches)
delete should not be used on arrays (no-array-delete)
Collection sizes and array length comparisons should make sense (no-collection-size-mischeck) (requires type-check)
Dead stores should be removed (no-dead-store) (requires type-check)
Two branches in a conditional structure should not have exactly the same implementation (no-duplicated-branches)
Destructuring patterns should not be empty (no-empty-destructuring)
Nested blocks of code should not be left empty (no-empty-nested-blocks)
Related "if/else if" statements and "cases" in a "switch" 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)
Functions should not have identical implementations (no-identical-functions)
Return values should not be ignored when function calls don't have any side effects (no-ignored-return) (requires type-check)
Functions should use "return" consistently (no-inconsistent-return)
Array.reverse should not be used misleadingly (no-misleading-array-reverse) (requires type-check)
Non-existent operators '=+', '=-' and '=!' should not be used (no-misspelled-operator)
Multiline string literals should not be used (no-multiline-string-literals)
Conditionals should start on new lines (no-same-line-conditional)
Variables should not be self-assigned (no-self-assignment) (requires type-check)
Jump statements should not be used unconditionally (no-unconditional-jump)
Multiline blocks should be enclosed in curly braces (no-unenclosed-multiline-block)
Errors should not be created without being thrown (no-unthrown-error)
Array contents should be used (no-unused-array)
The output of functions that don't return anything should not be used (no-use-of-empty-return-value) (requires type-check)
Values should not be uselessly incremented (no-useless-increment)
Variables should be declared before they are used (no-variable-usage-before-declaration) (requires type-check)

Use in TSLint

If you don't have TSLint yet configured for your project follow these instructions.
Install tslint-sonarts

npm install tslint-sonarts      # install in your project
npm install tslint-sonarts -g   # or install globally

Add tslint-sonarts to your tslint.json extends property:

{
  "extends": ["tslint:recommended", "tslint-sonarts"]
}

Some of the rules in SonarTS require type information. So in order to provide as much value as possible run TSLint with type-checker, for example:

tslint --type-check --project tsconfig.json -c tslint.json 'src/**/*.ts'

Use in SonarQube

SonarTS is available as plugin for SonarQube. SonarQube is an open source platform for continuous inspection of code quality. Thanks to the platform, SonarTS provides additional features:

Code coverage import
Duplication detection
Different metrics
More rules

See the documentation here and example project here.

Also available online on ☁️ sonarcloud.io

Contribution

Create New Rule

Create file for rule implementation in src/rules. File name should start with lower case and have suffix Rule
Create test folder in test/rules with the name of the rule file
In this folder create files <rule file name>.test.ts and <rule file name>.lint.ts
Run Ruling test
Add rule key to tslint-sonarts.json
In folder docs/rules create rule documentation file <rule key>.md
In README.md add reference to the documentation file.

Testing

The awesome jest test runner is used. There is just a little configuration required to enable TypeScript support.

To run unit tests:

cd sonarts-code
yarn test

To run unit tests in watch mode:

cd sonarts-code
yarn test -- --watch

And finally to run unit tests with coverage:

cd sonarts-code
yarn test -- --coverage

When you run tests with coverage, the coverage/ directory will be created at the root. You can open the web version of the coverage report coverage/lcov-report/index.html to see which lines are covered by tests.

To run unit tests for SQ plugin part of the project

cd sonarts-sq-plugin
mvn clean install

To build SQ plugin part of the project

./build.sh

Ruling

The ruling test is a special integration test which launches the analysis of a large code base, and then compares those results to the set of expected issues (stored as snapshot files). To have this code base locally:

 git submodule init
 git submodule update

To run the ruling test:

cd sonarts-code
yarn ruling
yarn ruling -- --rule <RuleFileName> # to run ruling for a single rule
yarn ruling -- --update # to update the snapshots
yarn ruling -- --rule <RuleFileName> --update # it is possible to combine both options

Tools we use

Visual Studio Code
Prettier (and its extension for VSCode)

hosszubalazs / SonarTS