Code Inspections in TypeScript
In TypeScript, ReSharper 2018.3 provides two kinds of code inspections: 141 inspections that detect errors such as broken syntax, unresolved symbols, compiler errors, etc. (you cannot configure or disable any of these inspections), and 51 proprietary code inspections, any of which you can disable or change its severity level.
These code inspections help you detect code issues in design time in all open files, and additionally they allow you to find code issues in specific scope.
Configurable TypeScript inspections are listed below, grouped by their categories.
Code Style (5 inspections)Inspections in this category detect violations of code syntax styles. In contrast to most of other code inspections, these inspections can either detect the same code construct as a code issue or not depending on the corresponding code style rule configured on the page of ReSharper options. You can also fix issues that these inspection detect, using code cleanup.
Element has implicit 'any' type
Non-compliant path style inside 'require'
Non-compliant 'public' modifier or its absense
Type of variable may be specified explicitly
Type specification is redundant, because variable type is contextually determined from the type of assigned value
Common Practices and Code Improvements (4 inspections)This category groups inspections that hunt for medium severity issues that mainly affect code readability.
Constructor of an abstract class can be made protected
Introducing variable will allow to apply type guard
Private class field can be made readonly
String literal usage allows to create specialized overload
Language Usage Opportunities (9 inspections)This category includes code inspections, mostly with the suggestion severity level, which notify you when more advanced language constructs can be used. These inspections detect syntax of outdated language versions and suggest using features from more modern language versions. For most of the supported languages, language version can be detected automatically or set manually.
AMD module may be converted to external module
Class emulation may be converted to class
CommonJs module may be converted to external module
Function expression may be converted to lambda expression
Immediately-invoked function expression may be converted to internal module
Invocation of parent class may be converted to super call
Member assigned by a function may be converted to function member
Possible overloads may be inferred by function body
Use 'as' operator instead of type assertion
Potential Code Quality Issues (15 inspections)This category includes inspections that detect critical issues (code smells), mostly with Error or Warning level. This category also includes inspections that ensure localization assistance.
Cannot resolve, probably symbol is located in inaccessible module
Check 'amd-dependency' the same way as require() argument
Empty return value for type-annotated function
Exported entity uses a private entity
'Implicit any' inspection when NoImplicitAny is set
More specific signature follows less specific
Overload is less specific than the main signature
Parameter-property value assigned inside constructor won't be assigned to class property
Suspicious 'instanceof' check
Suspicious 'this' usage in context of local function inside class member
Suspicious 'typeof' check
Type parameter hides type parameter declared in outer scope
Use of possibly unassigned property in a static initializer
Use of undeclared variable
Redundancies in Code (9 inspections)Code inspections in this category look for redundancies and dead code, which affect code readability and style, and could be safely removed. Some code redundancies cannot be fixed automatically, and quick-fixes for them are performed in the interactive mode, requiring the user input. But the majority of the redundancies can be fixed without user interaction, using either fix in scope or code cleanup.
Comparison of boolean with boolean value is equivalent to value or negated value
Double negation of boolean is redundant
Duplicate reference comment is redundant
Redundant parent type specification in extends/implements
Reference comment creates cyclic dependency
Ternary operator may be replaced by it's condition
Type cast is redundant: expression is always of provided type
Type cast is redundant: expression is of a structurally compatible type
Redundancies in Symbol Declarations (6 inspections)This category includes code inspections, mostly with the warning severity level, which detect empty and unused symbol declarations.
Parameter doesn't participate in the main signature
Redundant empty constructor without parameters
Same item is imported twice with different names
Type guard definitely produces 'never' type for the variable
Type guard doesn't affect variable's type in any way
Unused local import
Spelling issues (3 inspections)These inspections detect typos in various contexts.