Code Inspections in JavaScript and TypeScript

Reports method calls to document.write() or document.writeln(). Most uses of these calls are better performed using explicit DOM calls such as getElementByID() and createElement(). Additionally, the write() and writeln() calls will not work with XML DOMs, including DOMs for XHTML if viewed as XML. This can result in difficulty to point out bugs.

Reports common JavaScript patterns for detecting the browser or operating system in which the script is being run. In addition to pointing out non-portable constructs, these platform detection patterns are often incomplete and easily fooled. For most cases, detection of individual environment features is preferable to attempting to detect the entire platform. Patterns detected include document.all, document.layers, navigator.userAgent, navigator.oscpu, navigator.appName, navigator.appCodeName, and navigator.platform

Reports JavaScript accesses to DOM nodes as text using the innerHTML property. Most uses of innerHTML are better performed using explicit DOM calls such as getElementByID() and createElement(). Additionally, innerHTML will not work with XML DOMs, including DOMs for XHTML if viewed as XML. This can lead to difficult to diagnose bugs.

Reports common JavaScript DOM patterns which may present problems with XHTML documents. In particular, the patterns detected will behave completely differently depending on whether the document is loaded as XML or HTML. This can result in subtle bugs where script behaviour is dependent on the MIME-type of the document, rather than its content. Patterns detected include document.body, document.images, document.applets, document.links, document.forms, and document.anchors.

Validates names and paths in ECMAScript import declarations.

Reports dependencies in package.json that are not installed or don't match the specified version range.

When using JSX, it's usually required to have import from React in the file scope. Otherwise, the code may not compile properly. The inspection is disabled in projects with React 17 because the version no longer requires the React import.

Checks whether the module in the require() call or import statement exists, whether it is listed in package.json dependencies, and whether it is locally installed.

Suggests installing the module and/or including it into package.json.

For require() calls, works only in files in the scope of Node.js Core JavaScript library.

Reports unused JavaScript or TypeScript import bindings or specifiers. The validation works in ES6 and TypeScript files.

Runs the ESLint linter.

The highlighting is based on the rule severity specified in the ESLint configuration file. Uncheck "Use rule severity from the configuration file" to use the same severity configured in this inspection for all ESLint rules.

Runs JSHint validator for specified JavaScript file.

Reports errors according to JavaScript Standard Style.

The severity level of the inspection is applied only for the 'Inspect code...' action.

Runs TSLint- a linter for TypeScript.

The highlighting is based on the rule severity specified in the TSLint configuration file. Uncheck "Use rule severity from the configuration file" to use the same severity configured in this inspection for all TSLint rules.

Reports assignment operations which can be replaced by operator assignment. Using operator assignment may be clearer, and theoretically more performant.

Reports assignments to variables declared as a for loop parameter. While occasionally intended, this construct can be extremely confusing, and is often the result of a programmer error.

Reports assignments to function parameters. It also reports attempts to increment or decrement the variable. While occasionally intended, this construct can be extremely confusing, and is often the result of a programmer error.

Reports an assignment being used as the condition of an if, while, for or do statement. While occasionally intended, this usage is confusing, and often indicates a typo (= instead of == ).

Reports assignment expressions nested inside other expressions. While admirably terse, such expressions may be confusing, and violate the general design principle that a given construct should do precisely one thing.

Reports assignment expressions where the result of the assignment is used in a containing expression. Such assignments are often indications of coding errors such as using = instead of ==. Moreover, they can result in confusion due to order of operations, as evaluation of the assignment may effect the outer expression in unexpected ways.

Expressions in parentheses are ignored.

Reports assignments of the form x = x. These are pointless, and usually indicate programmer error.

Reports floating point numbers which do not have a decimal point, numbers before the decimal point, and numbers after the decimal point. Such literals may be confusing, and violate several coding standards.

Reports suspicions combinations of + or - characters in JavaScript code (e.g. a+++b. While legal, such sequences are confusing, and may have their semantics changed through changes in whitespace.

Reports calls to the eval(), setTimeout(), and setInterval() functions, or allocation of a Function object. These functions are used to execute arbitrary strings of JavaScript text, often dynamically generated. This can be very confusing, and may be a security risk.

Reports "magic numbers", i.e. literal numeric constants used without declaration. "Magic numbers" can result in code whose intention is extremely unclear, and may result in errors if a "magic number" is changed in one code location but not another. The numbers 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 100, 1000, 0.0 and 1.0 are not reported by this inspection.

Reports if statements which have an else branch and a negated condition. Flipping the order of the if and else branches will usually increase the clarity of such statements.

Reports conditional expressions whose conditions are negated. Flipping the order of the conditional expression branches will usually increase the clarity of such statements.

Reports ternary conditional expressions contained within other ternary conditions. Such nested conditionals may be extremely confusing, and best replaced by more explicit conditional logic.

Reports functions nested inside other functions. While JavaScript allows functions to be nested, such constructs may be confusing. Additionally, nested functions are prone to cause difficult-to-diagnose memory leaks in certain browsers, including Microsoft Internet Explorer.

Use the checkbox below to prevent this inspection from reporting anonymous nested functions.

Reports arithmetic expressions with too many terms. Such expressions may be confusing and bug-prone.

Use the field provided below to specify the maximum number of terms allowed in an arithmetic expression.

Reports boolean expressions with too many terms. Such expressions may be confusing and bug-prone.

Use the field provided below to specify the maximum number of terms allowed in an arithmetic expression.

Reports pointless arithmetic expressions. Such expressions include adding or subtracting zero, multiplying by zero or one, division by one, and shift by zero. Such expressions may be the result of automated refactorings not completely followed through to completion, and in any case are unlikely to be what the developer intended to do.

Reports increment (++) or decrement (--) expressions where the result of the assignment is used in a containing expression. Such assignments can result in confusion due to order of operations, as evaluation of the assignment may effect the outer expression in unexpected ways.

Reports if, while, for, and with statements whose bodies are empty. While occasionally useful, such statements are often the result of typos, and may cause confusion.

Use the checkbox below to select whether statements whose bodies are empty block statements will be reported by this inspection.

Reports unnecessary block statements. Block statements that are not used as the body of if, for, while, do, with, or try statements, or as the body of a function declaration are reported. Since JavaScript blocks do not introduce new scopes as is common in Java and other languages, free-standing block statements may be the result of code confusion, and may result in subtle bugs.

Reports uses of the caller property in a JavaScript function. Use of this property to access the stack frame of the calling method can be extremely confusing, and result in subtle bugs.

Suggests configuring coding assistance for Node.js, e.g. 'require' and/or core modules ('path', 'http', 'fs', etc.).

See https://nodejs.org/api/ for the complete list.

This inspection highlights failed method calls or assertions in tests.

Reports this expressions occurring outside of object literals or constructor bodies. Such this expressions are legal JavaScript, and reference the top-level "global" JavaScript object, but are largely useless.

Checks that constant or readonly variable is being reassigned.

Reports expression statements which are not assignments or calls. Such statements have no obvious semantics, and are normally the result of programmer error.

Reports functions which return a value in some circumstances and return without a value in others. While legal, such code almost certainly represents a programming error.

Reports deprecated octal integer literals prefixed with '0' and not '0o'.
It is an error to use such literals in modern ECMAScript code, and it is an error to use them in strict mode.
You can force this inspection for ES5 and ES3 language levels by ticking the 'Warn about obsolete octal literals in ES5- code' checkbox in the inspection settings.

a

Checks that arguments references are inside a function body.

Reports JavaScript reserved words being used as a name. The JavaScript specification reserves a number of words which are currently not used as keywords. Using those words as identifiers may result in broken code if later versions of JavaScript start using them as keywords.

Reports string literals which contain the sequence </. Such strings are legal JavaScript, but may result in incorrect parsing of any HTML the JavaScript is embedded in.

Missing await for an async function call results in having a Promise where a value was expected.

When the 'Report for promises in return statements' checkbox is checked, this inspection will also suggest adding 'await' in return statements.
While this is generally not necessary, it gives two main benefits.
The first one is that you won't forget to add 'await' when surrounding your code with try-catch.
The second one is that having explicit 'await' helps V8 runtime to provide async stack traces.

Highlights usages of await in functions that were possibly intended to be async but are missing the async modifier. While it is possible to use await as an identifier, it is likely that it was intended to be used as an operator and the containing function should be made async.

Reports redundant await usages, such as await await, or awaiting a non-promise result.
When the 'Report for promises' checkbox is checked, this inspection will also suggest removing 'await' before promises when applicable (in return statements, and with Promise.resolve/reject).
While this is not generally necessary, removing 'await' in such contexts gives you two problems.
The first one is that surrounding your code with try-catch and forgetting to add 'await' will change code semantics, and you may fail to notice that.
The second one is that not having explicit 'await' may prevent the V8 runtime from providing async stack traces.

Reports function calls that return a Promise that is not later used. These are usually unintended and indicate an error.

Highlights usages of top-level await -expressions. While the new 'top-level async' proposal is on its way, currently it is still illegal to use await outside async functions.

Reports unnecessary local variables, which add nothing to the comprehensibility of a function. Variables caught include local variables which are immediately returned, local variables that are immediately assigned to another variable and then not used, and local variables which always have the same value as another local variable or parameter.

Use the checkbox below to have this inspection ignore variables which are immediately returned or thrown. Some coding styles suggest using such variables for clarity and ease of debugging.

Reports where local variables are "reused", overwriting their values with new values unrelated to their original use. Such local variable reuse may be confusing, as the intended semantics of the local variable may vary with each use. It may also be prone to bugs, if code changes result in values that were thought to be overwritten actually being live. It is good practices to keep variable lifetimes as short as possible, and not reuse local variables for the sake of brevity.

Suggests to make the constructor of an abstract class protected (because it is useless to have it public).

Checks union and intersection types for duplicates

Reports usages of equality operators which may cause unexpected type coercions. It is considered a good practice to use the type-safe equality operators === and !== instead of their regular counterparts == and !=.

Depending on the option selected, this will either highlight:

• All usages of == and != operators.

• All usages except comparison with null. Some code styles allow using x == null as a replacement for x === null || x === undefined.

• Only suspicious expressions, such as: == or != comparisons to 0, '', null, true, false, or undefined.

Highlights type annotations that do not match the current code style for explicit types.

Type declarations are not necessary when the type inferred from the context exactly matches the type annotation, for example:

var pi: number = 3.14

In some cases it is preferable to always have explicit types - this saves from accidental type changes and makes code more explicit.

If a private field is assigned only in the constructor, it can be made readonly.

Checks that a corresponding type argument is passed when a generic type is used in a function, interface or class declaration

Checks that current file imports the augmentation module.

Checks that required options are enabled in tsconfig.json, e.g. when using React JSX in .tsx files, the TypeScript configuration file contains 'jsx: "react"'.

Checks type arguments for redundancy when a reference provides the type with default values

Report the use of references to a UMD global if the current file is a module.

Checks that the TypeScript library files required for the symbol are listed under the 'lib' compiler option in tsconfig.json.

Warns against a common mistake in TypeScript code, when a class field is declared as a constructor parameter, and then this parameter is assigned.
In this case, the corresponding field won't be assigned, only the local parameter value is modified.

Checks TypeScript called function parameters, return values, assigned expressions to be of correct type in any type context.

Checks that TypeScript called functions are valid.

Checks that TypeScript referenced variables and fields are valid.

Highlights variable usages where variable type is narrowed by a type guard. Note that severity level doesn't affect this inspection.

Validates consistency of 'paths', 'checkJs' and 'extends' in tsconfig.json files.

Reports for loops where the condition or update does not use the for loop variable.

Checks that operands in comparisons have compatible types in JavaScript files. Operands of types without possible common values are reported.

Checks code for comparisons with NaN. Comparisons like expr == NaN or expr === NaN are always evaluated to false.

Checks that array literal doesn't contain consecutive commas. Skipped element takes undefined value, but it could be done unintentionally, e.g. when commas are at the end of one line and at the beginning of the following.

Checks that function recognized as constructor does not return primitive values. When called with new, this value will be lost and object will be returned instead. To avoid warnings, you can explicitly specify function's return type with @return tag.

Reports division by zero or remainder by zero.

Reports for, while, or do statements which can only exit by throwing an exception. While such statements may be correct, they are often a symptom of coding errors.

Reports functions which must either recurse infinitely or throw an exception. Functions reported by this inspection can not return normally.

Reports potentially invalid indexed property access such as Array[1]. The validation works in JavaScript, html, or jsp files.

Reports potentially invalid constructor function usages such as: using non constructor in new, using constructor's prototype and constructor call without new. Constructor function assumed to have upper case name (optional) or have explicit JSDoc @constructor tag. The validation works in JavaScript, html or jsp files.

Checks for this to be the same in closure and in outer context. The validation works in JavaScript, html, or jsp files.

Warns against a common mistake of trying to reference a member of an ECMAScript class via this. qualifier in a nested function that is not a lambda.
this in a nested function that is not a lambda is the function's own 'this' and doesn't relate to the outer class.

Reports object allocation where the result of the object allocated is ignored. Such allocation expressions are legal JavaScript, but are usually either inadvertent, or evidence of a very odd object initialization strategy.

Reports assignments in form 'a =+ b'. In most cases, assignments of form 'a =+ b' are typos, and the correct option is 'a += b'.

Reports assignments and function calls where the name of the variable to which a value is assigned or the function parameter does not seem to match the name of the value assigned to it. For example:

Warns if bind is used together with arrow function.
Since arrow functions use lexical this, bind call will have no effect on them.
Please read more here.

Reports when literal string in a comparing with typeof is not one of the standard types: undefined, object, boolean, number, string, function or symbol.

Reports for loops which contain neither initialization or update components, and can thus be replaced by simpler while statements.

Use the checkbox below if you wish this inspection to ignore for loops with trivial or non-existent conditions.

Reports if statements with identical then and else branches. Such statements are almost certainly programmer error.

Reports if statements with too many branches. Such statements may be confusing, and are often the sign of inadequate levels of design abstraction.

Use the field below to specify the maximum number of branches expected.

Reports ternary conditional expressions with identical then and else branches. Such statements are almost certainly programmer error.

Reports conditional expressions of the form true? result1: result2 or false? result1: result2. These expressions sometimes occur as the result of automatic refactorings, and may obviously be simplified.

Reports duplicate conditions in different branches of an if statement. While it may rarely be the desired semantics, duplicate conditions usually represent programmer oversight.

Reports for, while and do statements whose bodies are guaranteed to execute at most once. Normally, this is an indication of a bug.

Reports errors caused by invoking a method, accessing a property or calling a function on an object that is undefined or null.

Reports pointless or pointlessly complicated boolean expressions or statements.

Reports if statements which can be simplified to single assignment or return statements. For example:

Reports conditional expressions of the form condition ?true:false or condition ?false:true. These expressions may be safely simplified to condition or ! condition, respectively.

Reports tail recursion, that is when a function calls itself as its last action before returning. Tail recursion can always be replaced by looping, which will be considerably faster. Some JavaScript engines perform this optimization, while others do not. Thus, tail recursive solutions may have considerably different performance characteristics on different environments.

Reports unnecessary continue statements at the end of loops. These statements may be safely removed.

Reports unnecessary return statements. Unnecessary return statements are those which return no value and occur just before the function would have "fallen through" the bottom. These statements may be safely removed.

Reports unused labels.

Reports labelled break statements whose labels may be removed without changing the flow of control.

Reports labelled continue statements whose labels may be removed without changing the flow of control.

Reports code which can never be executed. Such code almost certainly represents a programming error

typeof x type guard can be unsound in one of the following two cases:

1. typeof x never corresponds to the specified value (e.g., typeof x === 'number' when x has type 'string | boolean')

2. typeof x always corresponds to the specified value (e.g., typeof x === 'string' when x has type 'string')

1. Type of x is not related to A

2. Type of x is A or a subtype of A

Reports break or continue statements inside of finally blocks. While occasionally intended, such statements are very confusing, may mask exceptions thrown, and tremendously complicate debugging.

Reports return statements inside of finally blocks. While occasionally intended, such return statements may mask exceptions thrown, and tremendously complicate debugging.

Reports throw statements inside of finally blocks. While occasionally intended, such throw statements may mask exceptions thrown, and tremendously complicate debugging.

Reports empty catch blocks. Empty catch blocks are a sign that errors are simply being ignored, rather than properly handled.

Reports empty finally blocks. Empty finally blocks are usually the result of a coding error.

Reports empty try blocks. Empty try blocks are usually the result of a coding error.

Reports throw statements whose exceptions are always caught by containing try statements. Using throw statements as a "goto" to change the local flow of control is likely to be confusing.

Reports catch parameters that are unused in their corresponding blocks. This inspection will not report catch parameters named "ignore" or "ignored".

Use the checkbox below to disable this inspection for catch blocks with comments.

Reports classes and functions annotated with JSDoc @constructor or @class tags whose names are either too short, too long, or do not follow the specified regular expression pattern.

Use the fields provided below to specify minimum length, maximum length and regular expression expected for classes names. (Regular expressions are in standard java.util.regex format.)

Reports functions whose names are either too short, too long, or do not follow the specified regular expression pattern.

Use the fields provided below to specify minimum length, maximum length and regular expression expected for function names. (Regular expressions are in standard java.util.regex format.)

Reports function parameters whose names are either too short, too long, or do not follow the specified regular expression pattern.

Use the fields provided below to specify minimum length, maximum length and regular expression expected for local variables names. (Regular expressions are in standard java.util.regex format.)

Reports names containing non-ASCII symbols.

If 'Allow only ASCII names' option is used, reports all names containing non-ASCII symbols.
Otherwise reports all names, containing both ASCII and non-ASCII symbols.

Reports local variables whose names are either too short, too long, or do not follow the specified regular expression pattern.

Use the fields provided below to specify minimum length, maximum length and regular expression expected for local variables names. (Regular expressions are in standard java.util.regex format.)

Checks that JavaScript code is covered by the Flow type checker. To use this inspection, the Flow executable must be configured in Settings | Languages & Frameworks | JavaScript

Reports errors from Flow in Inspect code.

Checks that the // @flow flag is located on the top of the file – otherwise this file will not be checked by Flow.

Checks that there’s a .flowconfig file in the project that covers a JavaScript file with the // @flow flag.

Reports functions with three or more negation operations (! or != ). Such functions may be unnecessarily confusing.

Reports functions containing multiple loop statements.

Reports functions with multiple return points. Some coding standards warn against functions with multiple returns, as they may make functions more difficult to understand and maintain.

Reports functions with too many parameters. Functions with too many parameters are often an indication of design weakness.

Use the field provided below to specify the maximum acceptable number of parameters a function might have.

Reports functions that have too high cyclomatic complexity. Cyclomatic complexity is basically a measurement of the number of branching points in a function. Functions with too high a cyclomatic complexity may be confusing and difficult to test.

Use the field provided below to specify the maximum acceptable cyclomatic complexity a function might have.

Reports overly long functions. Function length is calculated by counting up the number of non-empty statements in the function. Functions that are too long are error-prone, and difficult to test.

Use the field provided below to specify the maximum acceptable number of statements a function might have.

Reports functions whose bodies are contain statements too deeply nested within other statements. Functions with too much statement nesting may be confusing, and are a good sign that refactoring may be necessary.

Use the field provided below to specify the maximum acceptable nesting depth a function might have.

Reports arrow functions where the body contains exactly one statement and can be converted to concise syntax without braces.

let incrementer = (x) => {return x + 1}; to

let incrementer = (x) => x + 1;

Reports chained equality comparisons (i.e. a==b==c ). Such comparisons are confusing.

Reports function calls whose target is another function call.

Reports on comparison operations with constant values on their left-hand side. Some coding conventions specify that constants should be on the right-hand side of comparisons.

Reports on comparison operations with constant values on their right-hand side. Some coding conventions specify that constants should be on the left-hand side of comparisons.

Reports function calls used as arguments to another function call.

Reports if, while, for, and with statements whose bodies are not block statements. While such statements are legal JavaScript, it is usually safer for downstream maintenance to use the code blocks for statement bodies.

Reports assignments to undefined properties of explicitly type-annotated variables.

Reports parentheses when they are redundant.

In expressions: var x = ((1) + 2) + 3

Arrow function argument lists: var incrementer = (x) => x + 1

TypeScript and Flow type declarations: type Card = (Suit & Rank) | (Suit & Number)

Reports statements that may be erroneously not terminated by a semicolon or a newline.

If 'terminate statements with semicolons' is selected in Editor | Code Style | JavaScript or TypeScript - Punctuation, reports all statements which do not end with a semicolon. While line-breaks may be used instead of semicolons to terminate JavaScript statements, some coding styles prefer the semicolon for consistency with the other languages.

Checks that local variables declared with var are at the top of a function scope.

By default, variable declarations are always moved ("hoisted") invisibly to the top of their containing scope when the code is executed. Therefore, having them defined at the top of the scope helps represent this behavior in the code.

Checks for #x -like access to private fields. Such syntax was allowed in the early versions of the specification draft, but is no longer a valid syntax. In the most recent versions of the draft, only the syntax with explicit 'this.' qualifier is valid.

Checks that JavaScript members marked with @private and @protected tags are visible in current context.

Checks code for warnings implied by Google Closure Compiler annotations. This includes correct usage of @abstract, @interface and @implements tags.

Checks for using deprecated functions and variables. The validation works in JavaScript, html, or jsp files.

Reports multiple destructuring properties with identical keys that can be merged

Checks that declarations are declared once in current scope. The validation works in JavaScript, TypeScript, html or jsp files.

Reports unresolved file references in JavaScript files, including CommonJS and AMD modules references.

Checks that variables are declared explicitly with a var statement. The validation works in JavaScript, html or jsp files.

Reports ES6 imports whose from part can be shortened by importing the parent directory.

Checks that jQuery selectors are used in an efficient way. It warns about duplicated selectors which could be cached and optionally about attribute and pseudo-selectors usage.

Checks that parameters defined within JSDoc comments match the function's actual parameters, i.e. have the same names and quantity.

This inspection reports basic syntax issues and inconsistencies with language specification. Examples are invalid usages of keywords, incompatible numeric format usage or multiple parameters to getters/setters.
Generally, such errors must always be reported and shouldn't be disabled. But in some cases, like issues due to dynamic nature of JavaScript, usage of not yet supported language features, or bugs in IDE's checker, it may be handy to disable reporting these very basic errors.

Checks for ActionScript, JavaScript and TypeScript methods which may safely be made static. A method may be static if it does not reference any of its class' non static methods and non static fields and is not overridden in a sub class.

Use the first checkbox below to inspect only private methods.

Reports collection fields or variables whose contents are either queried and not updated, or updated and not queried. Such mismatched queries and updates are pointless, and may indicate either dead code or a typographical error.

Query methods are automatically detected, based on whether they return something or a callback is passed. Use the table below to specify which methods are update methods.

Checks that JavaScript files are in strict mode.

Checks for improper usage of wrappers for primitive types. Also, warning will be produced when property of primitive type is modified, as assigned value will be lost.

Highlights and provides fixes to convert object properties to ES6 shorthand style.

var obj = {foo:foo} to

var obj = {foo}

Highlights usages of React JSX tags in JavaScript code.

Reports nested instances of strings and template literals. Such instances can be inlined into the containing template string.

For example, `Hello, ${`Brave ${"New"}`} ${"World"}!` can be simplified to `Hello, Brave New World!`

Checks for accessing mutable variables in nested functions. The validation works in JavaScript, html, or jsp files.

Checks JavaScript called function arguments, return values, assigned expressions to be of correct type. The validation works in JavaScript, html or jsp files.

Validates syntax and references in JavaScript/ActionScript documentation comments (JSDoc/ASDoc).

Checks that URL of an external JavaScript library is associated with a locally stored file used for code completion and navigation.
Use 'Download library' quick fix (Alt+Enter) to solve the problem.

Checks that called function parameters, return values and assigned expressions are of the correct type. The validation works in JavaScript, html or jsp files.

Checks for unfiltered for-in loops. The use of this construct results in processing inherited or unexpected properties. You need to filter own properties with hasOwnProperty() method. The validation works in JavaScript, html or jsp files.

Reports unneeded semicolons. The validation works in JavaScript, html or jsp files.

Reports when a trailing comma is used in array literals.

The warning is reported only when the JavaScript language version is set to JavaScript 1.8.5, ECMAScript 3 or 5.1.

Trailing commas in arrays are allowed according to these specifications, however, some browsers might throw an error when a trailing comma is used.

You can configure formatting options for trailing commas in Code Style | JavaScript or TypeScript | Punctuation.

Reports when a trailing comma is used in object literals.

The warning is reported only when the JavaScript language version is set to JavaScript 1.8.5, ECMAScript 3 or 5.1.

Trailing commas in object literals are allowed according to these specifications, however, some browsers might throw an error when a trailing comma is used.

You can configure formatting options for trailing commas in Code Style | JavaScript or TypeScript | Punctuation.

Checks that Ext JS xtype references have corresponding class.

Checks that called functions are valid. The validation works in JavaScript, html or jsp files.

Checks that referenced variables and fields are valid. The validation works in JavaScript, html or jsp files.

Reports the use of unresolved React components. As a fix, suggests adding a missing import statement if the referenced component is defined in the project or its dependencies or creating a new component with this name.

The template for a new component can be modified in Editor | File and Code Templates.

Reports when a class member initializer references another non-hoisted class member that could be not initialized yet.

Class members initialization happens consequently for fields, thus, a field cannot reference another field declared later.

This inspection suggests to move variables closer to their usages joining with the initializer expression If a variable is declared without an initializer, and it is used in the code much further or in a single nested scope, such variable may be joined with the first assignment as an initializer.

Validates options in the webpack configuration file (which name should start with `webpack`, e.g. `webpack.config.js`) against webpack Options Schema.

Disable this inspection to turn off validation and code completions inside the configuration object.

Reports switch statements where the default case comes before some other case.
Having the default mixed with other cases causes confusion. The best practice is to have it as the very last case.

Reports switch statements on a variable of enum or union type when the statement covers not all the value options from the type.

Reports switch statements without default clause in case when not all possible values are enumerated.

Reports unnecessary switch statements. Warns on switch statement with an empty body, only one case branch, or only single default branch.

Reports duplicated case labels on switch statements. Such switch statements are normally an indication of programmer error.

Reports cases where control can proceed from one branch of a switch statement to the next. Such "fall-through" is often a result of programmer error, for example, a missing break or return.

Reports switch statements which are nested in other switch statements. Such nested switch statements can be very confusing, particularly if proper indenting is not followed.

Reports labelled statements inside of switch statements. While occasionally intended, this construction is often the result of a typo.

Reports case branches of a switch statement that are unreachable in current context

Reports variables that are declared in one case clause of a switch statement, and are used in a different case clause of the same statement. For block-scope variables, this results in a ReferenceError being thrown. For var -variables, it signifies a potential error. This inspection can be disabled for var -variables if you use this pattern intentionally.

Converts for..in loops on arrays to for..of loops.
for..of loops, introduced in ECMAScript 6, iterate over iterable objects. For arrays, this construction should be preferred to for..in, since it is executed only for array values and not for array object's properties.

Reports let declarations that can be made const.

Reports when module.export is used and helps to replace it with the export or export default statement.

Please note that a quick-fix for converting module.export into export is not available for module.export inside functions or statements, because export statements can only be at the top level of a module.

Reports when require() is used and helps to replace the require() call with the import statement.

Enable Convert require() inside inner scopes with Fix all action to convert all require() calls inside the nested functions and statements when using the Fix all action.

Please note that converting the require() statements inside inner scopes to the import statements may cause changes in the semantics of the code. Import statements are static module dependencies and are hoisted, which means that they are moved to the top of the current module. require() calls load modules dynamically. They can be executed conditionally and their scope is defined by the expression in which they are used.
Clear Convert require() inside inner scopes with Fix all action option to prevent any changes in these complex cases when using Fix all action.

Reports var declarations that are used instead of let or const.
Both let and const are block-scoped and behave more strictly.

It helps to replace all var declarations with let or const declarations, depending on value semantics. Declarations might be moved to the top of the function or before the first usage of the variable to avoid Reference errors.
Check Conservatively convert var with Fix all action option to prevent any changes in these complex cases when using Fix all action.

Helps to replace function expressions with arrow functions.

Converts indexed for loops on arrays to for..of loops.
for..of loops, introduced in ECMAScript 6, iterate over iterable objects.

This inspection highlights string concatenations that can be replaced with a template string.

Reports suspicious usages of bitwise AND (" & ") and OR (" | ") operators. Usually it is a common typo and user expect a result according to the boolean operations AND (" && ") and OR (" || ").

Reports bitwise mask expressions which are guaranteed to evaluate to true or false. Expressions checked are of the form (var & constant1) == constant2 or (var | constant1) == constant2, where constant1 and constant2 are incompatible bitmask constants.

Reports pointless bitwise expressions. Such expressions include and ing with zero, or ing by zero, and shift by zero. Such expressions may be the result of automated refactorings not completely followed through to completion, and in any case are unlikely to be what the developer intended to do.

Reports shift operations where the value shifted by is constant and outside of the reasonable range. Integer shift operations outside of the range 0..31 are reported. Shifting by negative or overly large values is almost certainly a coding error.

Checks JavaScript for unused assignments. The validation works in JavaScript, ActionScript, HTML and JSP files.

Reports unused globally accessible public functions, variables, classes, and properties. The validation works in JavaScript, ActionScript, HTML and JSP files.

Reports unused locally accessible parameters, local variables, functions, classes and private member declarations. The validation works in JavaScript, ActionScript, HTML and JSP files.

Reports break statements. break statements that end case blocks are not reported.

Reports labelled break statements.

Reports continue statements.

Reports labelled continue statements.

Reports debugger statements, used for interaction with Javascript debuggers. Such statements should probably not be found in production code.

Reports void expressions. Since void behaves completely differently in JavaScript and Java, these expressions maybe confusing.

Reports with statements. with statements result in potentially confusing implicit bindings, and may behave strangely in setting new variables.

Reports anonymous functions. An explicit name of a function expression may be helpful for debugging. Function expressions without names are not reported if they have a name property specified in the ECMAScript 6 standard. For example, var bar = function() {}; is not reported.

Reports comma expressions. Comma expressions are often a sign of overly clever code, and may lead to subtle bugs. Comma expressions in the initializer or update section of a for loop are ignored by this inspection.

Reports ternary conditional expressions. Some coding standards prohibit such expressions, in favor of explicit if statements.

Reports labeled statements.