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

Follow us on twitter

To analyze pure JavaScript code, see SonarJS

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

• Getters and setters should access the expected fields (no-accessor-field-mismatch) (requires type-check)
• 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) (requires type-check)
• 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)
• Collections elements should not be overwritten unconditionally (no-element-overwrite) (requires type-check)
• Destructuring patterns should not be empty (no-empty-destructuring)
• Nested blocks of code should not be left empty (no-empty-nested-blocks)
• Conditions should not always evaluate to "true" or to "false" (no-gratuitous-expressions)
• 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)
• Function parameters, caught exceptions and foreach variables' initial values should not be ignored (no-ignored-initial-value) (requires type-check)
• 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)
• Redundant pairs of parentheses should be removed (no-redundant-parentheses)
• 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) (requires type-check)
• Redundant casts and not-null assertions should be avoided (no-useless-cast) (requires type-check)
• Values should not be uselessly incremented (no-useless-increment)
• The output of functions that don't return anything should not be used (no-use-of-empty-return-value) (requires type-check)
• Variables should be declared before they are used (no-variable-usage-before-declaration) (requires type-check)
• Type aliases should be used (use-type-alias) (requires type-check)

• 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'

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

• 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.

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

To run unit tests:

cd sonarts-core
yarn test

To run unit tests in watch mode:

cd sonarts-core
yarn test --watch

And finally to run unit tests with coverage:

cd sonarts-core
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

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-core
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

• Visual Studio Code
• Prettier (and its extension for VSCode)