Code Inspections in TypeScript
In TypeScript, ReSharper 2016.3 provides two kinds of code inspections: 137 inspections that detect errors such as broken syntax, unresolved symbols, compiler errors, etc. (you cannot configure or disable any of these inspections), and 48 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 in the following categories:
Code Style (5 inspections) Inspections in this category detect violations of code style rules. In contrast to the rest of 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 in the pages of ReSharper options. You can also fix issues that these inspection detect, using code cleanup. For more information, see Code Style and Cleanup.
| Element has implicit 'any' type || Warning |
| Non-compliant path style inside 'require' || Hint |
| Non-compliant 'public' modifier or its absense || Hint |
| Type of variable may be specified explicitly || Hint |
| Type specification is redundant, because variable type is contextually determined from the type of assigned value || Hint |
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 || Hint |
| Introducing variable will allow to apply type guard || Hint |
| Private class field can be made readonly || Hint |
| String literal usage allows to create specialized overload || Hint |
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 || Suggestion |
| Class emulation may be converted to class || Suggestion |
| CommonJs module may be converted to external module || Suggestion |
| Function expression may be converted to lambda expression || Suggestion |
| Immediately-invoked function expression may be converted to internal module || Suggestion |
| Invocation of parent class may be converted to super call || Suggestion |
| Member assigned by a function may be converted to function member || Suggestion |
| Possible overloads may be inferred by function body || Hint |
| Use 'as' operator instead of type assertion || Hint |
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 || Error |
| Check 'amd-dependency' the same way as require() argument || Disabled |
| Duplicate identifier || Error |
| Empty return value for type-annotated function || Warning |
| Exported entity uses a private entity || Error |
| 'Implicit any' inspection when NoImplicitAny is set || Error |
| More specific signature follows less specific || Warning |
| Overload is less specific than the main signature || Warning |
| Parameter-property value assigned inside constructor won't be assigned to class property || Warning |
| Suspicious 'instanceof' check || Warning |
| Suspicious 'this' usage in context of local function inside class member || Warning |
| Suspicious 'typeof' check || Warning |
| Type parameter hides type parameter declared in outer scope || Warning |
| Use of possibly unassigned property in a static initializer || Warning |
| Use of undeclared variable || Error |
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 || Warning |
| Double negation of boolean is redundant || Warning |
| Duplicate reference comment is redundant || Warning |
| Redundant parent type specification in extends/implements || Warning |
| Redundant qualifier || Warning |
| Reference comment creates cyclic dependency || Disabled |
| Ternary operator may be replaced by it's condition || Warning |
| Type cast is redundant: expression is always of provided type || Warning |
| Type cast is redundant: expression is of a structurally compatible type || Warning |
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 || Warning |
| Redundant empty constructor without parameters || Warning |
| Same item is imported twice with different names || Warning |
| Type guard definitely produces 'never' type for the variable || Warning |
| Type guard doesn't affect variable's type in any way || Warning |
| Unused local import || Warning |
Last modified: 12 October 2017