# 31 new rules for TypeScript

**URL:** <https://community.sonarsource.com/t/31-new-rules-for-typescript/19674>\
**Category:** Sonar Updates\
**Tags:** typescript, javascript\
**Created:** [February 4, 2020, 8:39pm UTC](https://community.sonarsource.com/t/31-new-rules-for-typescript/19674 "2020-02-04T20:39:39Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/chris/32/71589_2.png) [@Chris](https://community.sonarsource.com/u/Chris)\
**Post date:** [February 4, 2020, 8:39pm UTC](https://community.sonarsource.com/t/31-new-rules-for-typescript/19674/1 "2020-02-04T20:39:39Z")

</div>

Hello JavaScript and TypeScript developers,

We’ve ported **31 rules to TypeScript** from JavaScript to give frontend developers a more seamless experience as they move between the two languages.

_Bug Detection_

- [S1529](https://rules.sonarsource.com/typescript/RSPEC-1529): Bitwise operators should not be used in boolean contexts
- [S2137](https://rules.sonarsource.com/typescript/RSPEC-2137): Special identifiers should not be bound or assigned
- [S2427](https://rules.sonarsource.com/typescript/RSPEC-2427): The base should be provided to “parseInt”
- [S1530](https://rules.sonarsource.com/typescript/RSPEC-1530): Function declarations should not be made within blocks
- [S1848](https://rules.sonarsource.com/typescript/RSPEC-1848): Objects should not be created to be dropped immediately without being used

_Code Smell Detection_

- [S1119](https://rules.sonarsource.com/typescript/RSPEC-1119): Labels should not be used
- [S128](https://rules.sonarsource.com/typescript/RSPEC-128): Switch cases should end with an unconditional “break” statement
- [S134](https://rules.sonarsource.com/typescript/RSPEC-134): Control flow statements “if”, “for”, “while”, “switch” and “try” should not be nested too deeply
- [S3973](https://rules.sonarsource.com/typescript/RSPEC-3973): A conditionally executed single line should be denoted by indentation
- [S2392](https://rules.sonarsource.com/typescript/RSPEC-2392): Variables should be used in the blocks where they are declared
- [S3524](https://rules.sonarsource.com/typescript/RSPEC-3524): Braces and parentheses should be used consistently with arrow functions
- [S3317](https://rules.sonarsource.com/typescript/RSPEC-3317): Default export names and file names should match
- [S3499](https://rules.sonarsource.com/typescript/RSPEC-3499): Shorthand object properties should be grouped at the beginning or end of an object declaration
- [S3514](https://rules.sonarsource.com/typescript/RSPEC-3514): Destructuring syntax should be used for assignments
- [S3513](https://rules.sonarsource.com/typescript/RSPEC-3513): “arguments” should not be accessed directly
- [S2310](https://rules.sonarsource.com/typescript/RSPEC-2310): Loop counters should not be assigned to from within the loop body
- [S2692](https://rules.sonarsource.com/typescript/RSPEC-2692): “indexOf” checks should not be for positive numbers
- [S1994](https://rules.sonarsource.com/typescript/RSPEC-1994): “for” loop increment clauses should modify the loops’ counters
- [S1515](https://rules.sonarsource.com/typescript/RSPEC-1515): Functions should not be defined inside loops
- [S2208](https://rules.sonarsource.com/typescript/RSPEC-2208): Wildcard imports should not be used
- [S888](https://rules.sonarsource.com/typescript/RSPEC-888): Equality operators should not be used in “for” loop termination conditions
- [S1539](https://rules.sonarsource.com/typescript/RSPEC-1539): “strict” mode should be used with caution
- [S1128](https://rules.sonarsource.com/typescript/RSPEC-1128): Unnecessary imports should be removed
- [S1472](https://rules.sonarsource.com/typescript/RSPEC-1472): Function call arguments should not start on new lines
- [S1219](https://rules.sonarsource.com/typescript/RSPEC-1219): “switch” statements should not contain non-case labels
- [S100](https://rules.sonarsource.com/typescript/RSPEC-100): Function and method names should comply with a naming convention
- [S124](https://rules.sonarsource.com/typescript/RSPEC-124): Track comments matching a regular expression
- [S1134](https://rules.sonarsource.com/typescript/RSPEC-1134): Track uses of “FIXME” tags
- [S1067](https://rules.sonarsource.com/typescript/RSPEC-1067): Expressions should not be too complex
- [S1135](https://rules.sonarsource.com/typescript/RSPEC-1135): Track uses of “TODO” tags
- [S126](https://rules.sonarsource.com/typescript/RSPEC-126): “if … else if” constructs should end with “else” clauses

In total, there are now 173 TypeScript rules available to bring Code Quality and Security to your projects.

You can already enjoy these new features on [SonarCloud](https://sonarcloud.io/). As for SonarQube, these new features will be included in the next version (8.2).

Cheers,  
Christophe

---

<div class="post-metadata">

**Author:** ![Thw0rted](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/thw0rted/32/11962_2.png) [@Thw0rted](https://community.sonarsource.com/u/Thw0rted)\
**Post date:** [May 26, 2020, 12:51pm UTC](https://community.sonarsource.com/t/31-new-rules-for-typescript/19674/2 "2020-05-26T12:51:39Z")

</div>

I’m still pretty new to SonarQube, and this release includes a few rules that raised a lot of false positives (?) for my code. Is this site the right place to discuss individual rules? I clicked through to the individual rules listed here but `rules.sonarsource.com` has no social features that I could find. Should I make new posts in the “false positive” forum here? I’m not really sure “false positive” is the right description.

---

<div class="post-metadata">

**Author:** ![Alexandre\_Gigleux](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/alexandre_gigleux/32/26_2.png) [@Alexandre\_Gigleux](https://community.sonarsource.com/u/Alexandre_Gigleux)\
**Post date:** [May 26, 2020, 3:26pm UTC](https://community.sonarsource.com/t/31-new-rules-for-typescript/19674/3 "2020-05-26T15:26:12Z")

</div>

Welcome to the SonarQube community @Thw0rted! If you see issues that should not be raised, then indeed the good place to report them is on the [false-positive](https://community.sonarsource.com/c/bug/fp/7) category in this forum.
