Rule Description KPI URL
no-console In general, console methods aren’t appropriate for production code. Resource Utilization
no-magic-numbers Magic numbers should be avoided as they often lack documentation, forcing them to be stored in variables gives them implicit documentation.When no list of allowed values is specified, -1, 0 and 1 are allowed by default. Maintainability
no-var-keyword Disallows usage of the var keyword. Use let or const instead. Maintainability
typeof-compare Makes sure result of typeof is compared to correct string values Maintainability
no-switch-case-fall-through Fall though in switch statements is often unintentional and a bug. Accuracy
no-arg Using arguments.callee makes various performance optimizations impossible. See MDN for more details on why to avoid arguments.callee. Efficiency
arrow-return-shorthand Suggests to convert () => { return x; } to () => x. Understandability
no-var-requires Disallows the use of require statements except in import statements.In other words, the use of forms such as var module = require(“module”) are banned. Instead use ES6 style imports or import foo = require(‘foo’) imports. Maintainability
no-submodule-imports Submodules of some packages are treated as private APIs and the import paths may change without deprecation periods. It’s best to stick with top-level package exports. Maintainability
no-inferrable-types Explicit types where they can be easily inferred by the compiler make code more verbose. Robustness
no-redundant-jsdoc Forbids JSDoc which duplicates TypeScript functionality. Maintainability
use-default-type-parameter Warns if an explicitly specified type argument is the default for that type parameter. Maintainability
no-shadowed-variable Shadowing a variable masks access to it and obscures to what value an identifier actually refers. Robustness
no-string-throw Flags throwing plain strings or concatenations of strings because only Errors produce proper stack traces. Maintainability
no-string-literal If –noImplicitAny is turned off, property access via a string literal will be ‘any’ if the property does not exist. Robustness
forin for (let key in someObject) { if (someObject.hasOwnProperty(key)) { // code here } } Prevents accidental iteration over properties inherited from an object’s prototype. See MDN’s for…in documentation for more information about for…in loops. Maintainability  
no-parameter-properties Parameter properties can be confusing to those new to TS as they are less explicit than other ways of declaring and initializing class members. Understandability  
variable-name Checks variable names for various errors. Understandability  
match-default-export-name Requires that a default import have the same name as the declaration it imports. Does nothing for anonymous default exports. Understandability
no-any Using any as a type declaration nullifies the compile-time benefits of the type system. Robustness
prefer-switch Prefer a switch statement to an if statement with simple === comparisons. Maintainability
switch-final-break Checks whether the final clause of a switch statement ends in break; Robustness
no-sparse-arrays Missing elements are probably an accidentally duplicated comma. Robustness
ban-comma-operator Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code. Understandability
no-unnecessary-type-assertion Warns if a type assertion does not change the type of an expression. Understandability
no-conditional-assignment Assignments in conditionals are often typos: for example if (var1 = var2) instead of if (var1 == var2). They also can be an indicator of overly clever code which decreases maintainability. Accuracy
prefer-for-of A for(… of …) loop is easier to implement and read when the index is not needed. Understandability
binary-expression-operand-order In a binary expression, a literal should always be on the right-hand side if possible. For example, prefer “x + 1” over “1 + x”. Understandability
promise-function-async Ensures that each function is only capable of 1) returning a rejected promise, or 2) throwing an Error object. In contrast, non-async Promise-returning functions are technically capable of either. This practice removes a requirement for consuming code to handle both cases. Maintainability
no-implicit-dependencies Disallows importing transient dependencies and modules installed above your package’s root directory. Maintainability
no-unnecessary-qualifier Warns when a namespace qualifier (A.x) is unnecessary. Accuracy
no-for-in-array Disallows iterating over an array with a for-in loop. A for-in loop (for (var k in o)) iterates over the properties of an Object. While it is legal to use for-in loops with array types, it is not common. for-in will iterate over the indices of the array as strings, omitting any “holes” in the array. More common is to use for-of, which iterates over the values of an array. If you want to iterate over the indices, alternatives include: array.forEach((value, index) => { … }); for (const [index, value] of array.entries()) { … } for (let i = 0; i < array.length; i++) { … } Accuracy
prefer-const If a variable is only assigned to once when it is declared, it should be declared using ‘const’. Understandability
object-literal-key-quotes Object literal property names can be defined in two ways: using literals or using strings. For example, these two objects are equivalent: var object1 = { property: true }; var object2 = { ‘property’ : true }; In many cases, it doesn’t matter if you choose to use an identifier instead of a string or vice-versa. Even so, you might decide to enforce a consistent style in your code. This rules lets you enforce consistent quoting of property names. Either they should always be quoted (default behavior) or quoted only as needed (‘as-needed’). Understandability
typedef Requires type definitions to exist. Understandability  
class-name Makes it easy to differentiate classes from regular variables at a glance. Understandability  
prefer-readonly Marking never-modified variables as readonly helps enforce the code’s intent of keeping them as never-modified. It can also help prevent accidental changes of members not meant to be changed. Accuracy  
no-null-keyword Instead of having the dual concepts of null andundefined in a codebase, this rule ensures that only undefined is used. Understandability  
no-namespace ES6-style external modules are the standard way to modularize code. Using module {} and namespace {} are outdated ways to organize TypeScript code. Maintainability  
prefer-template Prefer a template expression over string literal concatenation. Understandability  
member-access Explicit visibility declarations can make code more readable and accessible for those new to TS. Understandability  
no-construct There is little reason to use String, Number, or Boolean as constructors. In almost all cases, the regular function-call version is more appropriate. More details are available on StackOverflow. Understandability  
return-undefined Prefer return; in void functions and return undefined; in value-returning functions. Accuracy  
no-reference-import Don’t if you import foo anyway. Maintainability  
import-blacklist Some libraries allow importing their submodules instead of the entire module. This is good practise as it avoids loading unused modules. Efficiency  
no-bitwise Bitwise operators are often typos – for example bool1 & bool2 instead of bool1 && bool2. They also can be an indicator of overly clever code which decreases maintainability. Accuracy  
prefer-object-spread Object spread allows for better type checking and inference. Maintainability  
restrict-plus-operands When adding two variables, operands must both be of type number or of type string. Accuracy  
no-invalid-this See the rule’s author;s rationale here. Maintainability
no-misused-new Warns on apparent attempts to define constructors for interfaces or new for classes. Accuracy
newline-per-chained-call This style helps to keep code “vertical”, avoiding the need for side-scrolling in IDEs or text editors. Understandability
no-unused-variable In addition to avoiding compilation errors, this rule may still be useful if you wish to have tslint automatically remove unused imports, variables, functions, and private class members, when using TSLint’s –fix option. Maintainability
no-dynamic-delete Deleting dynamically computed keys is dangerous and not well optimized. Accuracy
quotemark Requires single or double quotes for string literals. Accuracy
no-unused-expression Detects potential errors where an assignment or function call was intended. Maintainability
label-position Labels in JavaScript only can be used in conjunction with break or continue,
constructs meant to be used for loop flow control. While you can theoretically use
labels on any block statement in JS, it is considered poor code structure to do so.
no-empty-interface An empty interface is equivalent to its supertype (or {}). Maintainability
only-arrow-functions Traditional functions don’t bind lexical scope, which can lead to unexpected behavior when accessing “this”. Accuracy
no-require-imports Prefer the newer ES6-style imports over require(). Maintainability Checks whether the final clause of a switch statement ends in break;
no-unnecessary-callback-wrapper Replaces x => f(x) with just f. To catch more cases, enable only-arrow-functions and arrow-return-shorthand too. Accuracy
no-void-expression Requires expressions of type void to appear in statement position. Maintainability
array-type Requires using either “T[]” or “Array” for arrays. Maintainability
Prefer-method-signature Prefer foo(): void over foo: () => void in interfaces and types. Maintainability
chai-prefer-contains-to-index-of Avoid Chai assertions that invoke indexOf and compare for a -1 result. It is better to use the chai .contain() assertion API instead because the failure message will be more clearer if the test fails. Efficiency
chai-vague-errors Avoid Chai assertions that result in vague errors. For example, asserting expect(something) will result in the failure message “Expected true received false”. This is a vague error message that does not reveal the underlying problem. It is especially vague in TypeScript because stack trace line numbers often do not match the source code. A better pattern to follow is the xUnit Patterns Assertion Message pattern. The previous code sample could be better written as expect(something).to.equal(true, ‘expected something to have occurred’); Maintainability
export-name The name of the exported module must match the filename of the source file. This is case-sensitive but ignores file extension. Since version 1.0, this rule takes a list of regular expressions as a parameter. Any export name matching that regular expression will be ignored. For example, to allow an exported name like myChartOptions, then configure the rule like this: “export-name”: [true, “myChartOptionsg”] Maintainability
function-name Applies a naming convention to function names and method names. You can configure the naming convention by passing parameters. Please note, the private-method-regex does take precedence over the static-method-regex, so a private static method must match the private-method-regex. The default values are: [ true, {  “method-regex”: “^[a-z][wd]+$”, “private-method-regex”: “^[a-z][wd]+$”, “protected-method-regex”: “^[a-z][wd]+$”, “static-method-regex”: “^[A-Z_d]+$”, “function-regex”: “^[a-z][wd]+$” } This rule has some overlap with the tslint variable-name rule; however, the rule here is more configurable.] Maintainability
import-name The name of the imported module must match the name of the thing being imported. For example, it is valid to name imported modules the same as the module name: import Service = require(‘x/y/z/Service’) and import Service from ‘x/y/z/Service’. But it is invalid to change the name being imported, such as: import MyCoolService = require(‘x/y/z/Service’) and import MyCoolService from ‘x/y/z/Service’. Since version 2.0.9 it is possible to configure this rule with a list of exceptions. For example, to allow underscore to be imported as _, add this configuration: ‘import-name’: [ true, { ‘underscore’: ‘_’ }] Maintainability
insecure-random Do not use insecure sources for random bytes. Use a secure random number generator instead. Bans all uses of Math.random and crypto.pseudoRandomBytes. Better alternatives are crypto.randomBytes and window.crypto.getRandomValues. References: * CWE 330 * MDN Math.random * Node.js crypto.randomBytes() * window.crypto.getRandomValues() Accuracy
jquery-deferred-must-complete When a JQuery Deferred instance is created, then either reject() or resolve() must be called on it within all code branches in the scope. Maintainability
max-func-body-length Avoid long functions. The line count of a function body must not exceed the value configured within this rule’s options.  You can setup a general max function body length applied for every function/method/arrow function e.g. [true, 30] or set different maximum length for every type e.g. [true, { “func-body-length”: 10 , “func-expression-body-length”: 10 , “arrow-body-length”: 5, “method-body length”: 15, “ctor-body-length”: 5 }]. To specify a function name whose parameters you can ignore for this rule, pass a regular expression as a string(this can be useful for Mocha users to ignore the describe() function). Since version 2.0.9, you can also ignore single- and multi-line comments from the total function length, eg. [true, { “ignore-comments”: true }] Maintainability
mocha-no-side-effect-code All test logic in a Mocha test case should be within Mocha lifecycle method and not defined statically to execute when the module loads. Put all assignments and initialization statements in a before(), beforeEach(), beforeAll(), after(), afterEach(), afterAll(), or it() function. Code executed outside of these lifecycle methods can throw exceptions before the test runner is initialized and can result in errors or even test runner crashes. This rule can be configured with a regex to ignore certain initializations. For example, to ignore any calls to RestDataFactory configure the rule with: [true, { ignore: ‘^RestDataFactory..*’ }] Accuracy
no-backbone-get-set-outside-model Avoid using model.get(‘x’) and model.set(‘x’, value) Backbone accessors outside of the owning model. This breaks type safety and you should define getters and setters for your attributes instead. Maintainability
no-banned-terms Do not use banned terms: caller, callee, eval, arguments. These terms refer to functions or properties that should not be used, so it is best practice to simply avoid them. Understandability
no-document-domain Do not write to document.domain. Scripts setting document.domain to any value should be validated to ensure that the value is on a list of allowed sites. Also, if your site deals with PII in any way then document.domain must not be set to a top-level domain (for example, but only to an appropriate subdomain (for example, If you are absolutely sure that you want to set document.domain then add a tslint suppression comment for the line. For more information see the Phase 4 Verification page of the Microsoft SDL Security
no-duplicate-case This rule can be replaced with TSLint’s no-duplicate-switch-case. Do not use duplicate case labels in switch statements. Similar to the ESLint no-duplicate-caserule Maintainability
no-empty-interfaces Do not use empty interfaces. They are compile-time only artifacts and they serve no useful purpose Maintainability
no-exec-script Do not use the execScript functions. window.execScript is not crossing browsers, only IE supports it. Robustness
no-inner-html Do not write values to innerHTML, outerHTML, or set HTML using the JQuery html() function. Writing values to innerHTML can expose your website to XSS injection attacks. All strings must be escaped before being rendered to the page. Security
no-invalid-regexp Do not use invalid regular expression strings in the RegExp constructor. Similar to the ESLint no-invalid-regexp rule Maintainability
no-missing-visibility-modifiers This rule is in the TSLint product as member-access. Class members (both fields and methods) should have visibility modifiers specified. THe Principle of Least Visibility guides us to prefer private methods and fields when possible. If a developer forgets to add a modifier then TypeScript assumes the element should be public, which is the wrong default choice. Maintainability  
no-multiple-var-decl Deprecated – This rule is now part of the base TSLint product as the rule named ‘one-variable-per-declaration’. Do not use comma separated variable declarations Maintainability  
no-regex-spaces Do not use multiple spaces in a regular expression literal. Similar to the ESLint no-regex-spaces rule Maintainability  
no-relative-imports Do not use relative paths when importing external modules or ES6 import declarations. The advantages of removing all relative paths from imports is that 1) the import name will be consistent across all files and subdirectories so searching for usages is much easier. 2) Moving source files to different folders will not require you to edit your import statements. 3) It will be possible to copy and paste import lines between files regardless of the file location. And 4) version control diffs will be simplified by having overall fewer edits to the import lines. Maintainability  
no-reserved-keywords Do not use reserved keywords as names of local variables, fields, functions, or other identifiers. Since version 2.0.9 this rule accepts a parameter called allow-quoted-properties. If true, interface properties in quotes will be ignored. This can be a useful way to avoid verbose suppress-warning comments for generated d.ts files.  This rule has some overlap with the tslint variable-name rule, however, the rule here finds more keywords and more usages. Maintainability  
no-stateless-class Deprecated – This rule can be replaced with TSLint’s no-unnecessary-class. A stateless class represents a failure in the object oriented design of the system. A class without state is better modeled as a module or given some state. A stateless class is defined as a class with only static members and no parent class. Maintainability  
no-suspicious-comment Do not use suspicious comments, such as BUG, HACK, FIXME, LATER, LATER2, TODO. We recommend that you run this rule before each release as a quality checkpoint. Reference: CWE-546 Suspicious Comment Robustness  
no-typeof-undefined Do not use the idiom typeof x === ‘undefined’. You can safely use the simpler x === undefined or perhaps x == null if you want to check for either null or undefined. Accuracy  
no-unnecessary-bind Do not bind ‘this’ as the context for a function literal or lambda expression. If you bind ‘this’ as the context to a function literal, then you should just use a lambda without the bind. If you bind ‘this’ as the context to a lambda, then you can remove the bind call because ‘this’ is already the context for lambdas. Works for Underscore methods as well. Accuracy  
no-unnecessary-field-initialization Do not unnecessarily initialize the fields of a class to values they already have. For example, there is no need to explicitly set a field to undefined in the field’s initialization or in the class’ constructor. Also, if a field is initialized to a constant value (null, a string, a boolean, or some number) then there is no need to reassign the field to this value within the class constructor. Resource Utilization  
no-unnecessary-override Do not write a method that only calls super() on the parent method with the same arguments. You can safely remove methods like this and Javascript will correctly dispatch the method to the parent object. Resource Utilization  
no-unsupported-browser-code Avoid writing browser-specific code for unsupported browser versions. Browser versions are specified in the rule configuration options, eg: [true, [ “IE 11”, “Firefox > 40”, “Chrome >= 45” ] ]. Browser-specific blocks of code can then be designated with a single-line comment, like so: // Browser specific: IE 10, or with a jsdoc like this: @browserspecific chrome 40. Understandability  
no-useless-files Avoid keeping files around that only contain commented out code, are completely empty, or only contain whitespace characters Resource Utilization  
no-var-self Deprecated – This rule can be replaced with TSLint’s no-this-assignment. Do not use var self = this; instead, manage scope with arrow functions/lambdas. Self variables are a common practice in JavaScript but can be avoided in TypeScript. By default the rule bans any assignments of the this reference. If you want to enforce a naming convention or allow some usages then configure the rule with a regex. By default the rule is configured with (?!) which matches nothing. You can pass ^self$ to allow variables named self or pass ^(?!self$) to allow anything other than self, for example Maintainability  
prefer-array-literal Use array literal syntax when declaring or instantiating array types. For example, prefer the Javascript form of string[] to the TypeScript form Array. Prefer ‘[]’ to ‘new Array()’. Prefer ‘[4, 5]’ to ‘new Array(4, 5)’. Prefer ‘[undefined, undefined]’ to ‘new Array(4)’. Since 2.0.10, this rule can be configured to allow Array type parameters. To ignore type parameters, configure the rule with the values: [ true, { ‘allow-type-parameters’: true } ] This rule has some overlap with the TSLint array-type rule, however, the version here catches more instances. Maintainability  
promise-must-complete When a Promise instance is created, then either the reject() or resolve() parameter must be called on it within all code branches in the scope. For more examples see the feature request. This rule has some overlap with the tslint no-floating-promises rule, but they are substantially different. Maintainability  
react-a11y-aria-unsupported-elements For accessibility of your website, enforce that elements that do not support ARIA roles, states, and properties do not have those attributes. Maintainability  
react-a11y-event-has-role For accessibility of your website, Elements with event handlers must have explicit role or implicit role. Maintainability  
react-a11y-image-button-has-alt For accessibility of your website, enforce that inputs element with type=”image” must have non-empty alt attribute. Maintainability  
react-a11y-img-has-alt Enforce that an img element contains the alt attribute or role=’presentation’ for a decorative image. All images must have alt text to convey their purpose and meaning to screen reader users. Besides, the alt attribute specifies an alternate text for an image, if the image cannot be displayed. This rule accepts as a parameter a string array for tag names other than img to also check. For example, if you use a custom tag named ‘Image’ then configure the rule with: [true, [‘Image’]] Maintainability  
react-a11y-lang For accessibility of your website, HTML elements must have a lang attribute and the attribute must be a valid language code. Maintainability  
react-a11y-meta For accessibility of your website, HTML meta elements must not have http-equiv=”refresh”. Maintainability  
react-a11y-props For accessibility of your website, enforce all aria-* attributes are valid. Elements cannot use an invalid aria-* attribute. This rule will fail if it finds an aria-* attribute that is not listed in WAI-ARIA states and properties. Maintainability  
react-a11y-proptypes For accessibility of your website, enforce the type of aria state and property values are correct. Maintainability  
react-a11y-role-has-required-aria-props For accessibility of your website, elements with aria roles must have all required attributes according to the role.  Maintainability  
react-a11y-role-supports-aria-props For accessibility of your website, enforce that elements with explicit or implicit roles defined contain only aria-* properties supported by that role. Many aria attributes (states and properties) can only be used on elements with particular roles. Some elements have implicit roles, such as , which will be resolved to role=’link’. A reference for the implicit roles can be found at Default Implicit ARIA Semantics.  Maintainability  
react-a11y-role For accessibility of your website, elements with aria roles must use a valid, non-abstractaria role. A reference to role defintions can be found at WAI-ARIA roles. Maintainability  
react-a11y-tabindex-no-positive For accessibility of your website, enforce tabindex value is not greater than zero. Avoid positive tabindex attribute values to synchronize the flow of the page with keyboard tab order. Maintainability  
react-a11y-titles For accessibility of your website, HTML title elements must not be empty, must be more than one word, and must not be more than 60 characters long. Maintainability  
react-anchor-blank-noopener For security reasons, anchor tags with target=”_blank” should also include rel=”noopener noreferrer”. In order to restrict the behavior window.opener access, the original page needs to add a rel=”noopener” attribute to any link that has target=”_blank”. However, Firefox does not support that tag, so you should actually use rel=”noopener noreferrer” for full coverage. For more info see: The target=”_blank” vulnerability by example Maintainability  
react-iframe-missing-sandbox React iframes must specify a sandbox attribute. If specified as an empty string, this attribute enables extra restrictions on the content that can appear in the inline frame. The value of the attribute can either be an empty string (all the restrictions are applied), or a space-separated list of tokens that lift particular restrictions. You many not use both allow-scripts and allow-same-origin at the same time, as that allows the embedded document to programmatically remove the sandbox attribute in some scenarios. Maintainability  
react-no-dangerous-html Do not use React’s dangerouslySetInnerHTML API. This rule finds usages of the dangerouslySetInnerHTML API (but not any JSX references). For more info see the react-no-dangerous-html Rule wiki page. Security  
react-this-binding-issue Several errors can occur when using React and React.Component subclasses. When using React components you must be careful to correctly bind the ‘this’ reference on any methods that you pass off to child components as callbacks. For example, it is common to define a private method called ‘onClick’ and then specify onClick={this.onClick} as a JSX attribute. If you do this then the ‘this’ reference will be undefined when your private method is invoked. The React documentation suggests that you bind the ‘this’ reference on all of your methods within the constructor: this.onClick = this.onClick.bind(this);. This rule will create a violation if 1) a method reference is passed to a JSX attribute without being bound in the constructor. And 2) a method is bound multiple times in the constructor. Another issue that can occur is binding the ‘this’ reference to a function within the render() method. For example, many people will create an anonymous lambda within the JSX attribute to avoid the ‘this’ binding issue: onClick={() => { this.onClick(); }}. The problem with this is that a new instance of an anonymous function is created every time render() is invoked. When React compares virutal DOM properties within shouldComponentUpdate() then the onClick property will look like a new property and force a re-render. You should avoid this pattern because creating function instances within render methods breaks any logic within shouldComponentUpdate() methods. This rule creates violations if 1) an anonymous function is passed as a JSX attribute. And 2) if a function instantiated in local scope is passed as a JSX attribute. This rule can be configured via the “allow-anonymous-listeners” parameter. If you want to suppress violations for the anonymous listener scenarios then configure that rule like this: “react-this-binding-issue”: [ true, { ‘allow-anonymous-listeners’: true } ] Maintainability  
underscore-consistent-invocation Enforce a consistent usage of the _ functions. By default, invoking underscore functions should begin with wrapping a variable in an underscore instance: _(list).map(…). An alternative is to prefer using the static methods on the _ variable:, …). The rule accepts single parameter called ‘style’ which can be the value ‘static’ or ‘instance’: [true, { “style”: “static” }] Maintainability  
use-named-parameter Do not reference the arguments object by numerical index; instead, use a named parameter. This rule is similar to JSLint’s Use a named parameter rule. Maintainability  
valid-typeof Deprecated – This rule is now enforced by the TypeScript compiler. Ensures that the results of typeof are compared against a valid string. This rule aims to prevent errors from likely typos by ensuring that when the result of a typeof operation is compared against a string, that the string is a valid value. Similar to the valid-typeof ESLint rule. Accuracy