31 new rules for TypeScript

Clean Code Sonar Updates
,
1

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: Bitwise operators should not be used in boolean contexts
  • S2137: Special identifiers should not be bound or assigned
  • S2427: The base should be provided to “parseInt”
  • S1530: Function declarations should not be made within blocks
  • S1848: Objects should not be created to be dropped immediately without being used

Code Smell Detection

  • S1119: Labels should not be used
  • S128: Switch cases should end with an unconditional “break” statement
  • S134: Control flow statements “if”, “for”, “while”, “switch” and “try” should not be nested too deeply
  • S3973: A conditionally executed single line should be denoted by indentation
  • S2392: Variables should be used in the blocks where they are declared
  • S3524: Braces and parentheses should be used consistently with arrow functions
  • S3317: Default export names and file names should match
  • S3499: Shorthand object properties should be grouped at the beginning or end of an object declaration
  • S3514: Destructuring syntax should be used for assignments
  • S3513: “arguments” should not be accessed directly
  • S2310: Loop counters should not be assigned to from within the loop body
  • S2692: “indexOf” checks should not be for positive numbers
  • S1994: “for” loop increment clauses should modify the loops’ counters
  • S1515: Functions should not be defined inside loops
  • S2208: Wildcard imports should not be used
  • S888: Equality operators should not be used in “for” loop termination conditions
  • S1539: “strict” mode should be used with caution
  • S1128: Unnecessary imports should be removed
  • S1472: Function call arguments should not start on new lines
  • S1219: “switch” statements should not contain non-case labels
  • S100: Function and method names should comply with a naming convention
  • S124: Track comments matching a regular expression
  • S1134: Track uses of “FIXME” tags
  • S1067: Expressions should not be too complex
  • S1135: Track uses of “TODO” tags
  • S126: “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. As for SonarQube, these new features will be included in the next version (8.2).

Cheers,
Christophe

2 Likes
2

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.

3

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 category in this forum.

1 Like