| Rule | Description | KPI | URL |
|---|---|---|---|
| no-console | In general, console methods aren’t appropriate for production code. | Resource Utilization | https://palantir.github.io/tslint/rules/cyclomatic-complexity |
| 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 | https://palantir.github.io/tslint/rules/encoding |
| no-var-keyword | Disallows usage of the var keyword. Use let or const instead. | Maintainability | https://palantir.github.io/tslint/rules/no-inferred-empty-object-type |
| typeof-compare | Makes sure result of typeof is compared to correct string values | Maintainability | https://palantir.github.io/tslint/rules/use-isnan |
| no-switch-case-fall-through | Fall though in switch statements is often unintentional and a bug. | Accuracy | https://palantir.github.io/tslint/rules/no-invalid-template-strings |
| no-arg | Using arguments.callee makes various performance optimizations impossible. See MDN for more details on why to avoid arguments.callee. | Efficiency | https://palantir.github.io/tslint/rules/unified-signatures |
| arrow-return-shorthand | Suggests to convert () => { return x; } to () => x. | Understandability | https://palantir.github.io/tslint/rules/no-floating-promises |
| 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 | https://palantir.github.io/tslint/rules/no-object-literal-type-assertion |
| 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 | https://palantir.github.io/tslint/rules/no-debugger |
| no-inferrable-types | Explicit types where they can be easily inferred by the compiler make code more verbose. | Robustness | https://palantir.github.io/tslint/rules/no-unnecessary-initializer |
| no-redundant-jsdoc | Forbids JSDoc which duplicates TypeScript functionality. | Maintainability | https://palantir.github.io/tslint/rules/adjacent-overload-signatures |
| use-default-type-parameter | Warns if an explicitly specified type argument is the default for that type parameter. | Maintainability | https://palantir.github.io/tslint/rules/no-return-await |
| no-shadowed-variable | Shadowing a variable masks access to it and obscures to what value an identifier actually refers. | Robustness | https://palantir.github.io/tslint/rules/interface-over-type-literal |
| no-string-throw | Flags throwing plain strings or concatenations of strings because only Errors produce proper stack traces. | Maintainability | https://palantir.github.io/tslint/rules/no-non-null-assertion |
| no-string-literal | If –noImplicitAny is turned off, property access via a string literal will be ‘any’ if the property does not exist. | Robustness | https://palantir.github.io/tslint/rules/no-duplicate-switch-case |
| 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 | https://palantir.github.io/tslint/rules/max-line-length |
| no-any | Using any as a type declaration nullifies the compile-time benefits of the type system. | Robustness | https://palantir.github.io/tslint/rules/arrow-parens |
| prefer-switch | Prefer a switch statement to an if statement with simple === comparisons. | Maintainability | https://palantir.github.io/tslint/rules/new-parens |
| switch-final-break | Checks whether the final clause of a switch statement ends in break; | Robustness | https://palantir.github.io/tslint/rules/one-variable-per-declaration |
| no-sparse-arrays | Missing elements are probably an accidentally duplicated comma. | Robustness | https://palantir.github.io/tslint/rules/semicolon |
| ban-comma-operator | Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code. | Understandability | https://palantir.github.io/tslint/rules/no-consecutive-blank-lines |
| no-unnecessary-type-assertion | Warns if a type assertion does not change the type of an expression. | Understandability | https://palantir.github.io/tslint/rules/prefer-function-over-method |
| 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 | https://palantir.github.io/tslint/rules/completed-docs |
| prefer-for-of | A for(… of …) loop is easier to implement and read when the index is not needed. | Understandability | https://palantir.github.io/tslint/rules/linebreak-style |
| 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 | https://palantir.github.io/tslint/rules/no-default-export |
| 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 | https://palantir.github.io/tslint/rules/whitespace |
| no-implicit-dependencies | Disallows importing transient dependencies and modules installed above your package’s root directory. | Maintainability | https://palantir.github.io/tslint/rules/ordered-imports |
| no-unnecessary-qualifier | Warns when a namespace qualifier (A.x) is unnecessary. | Accuracy | https://palantir.github.io/tslint/rules/strict-boolean-expressions |
| 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 | https://palantir.github.io/tslint/rules/no-empty |
| prefer-const | If a variable is only assigned to once when it is declared, it should be declared using ‘const’. | Understandability | https://palantir.github.io/tslint/rules/object-literal-sort-keys |
| 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 | https://palantir.github.io/tslint/rules/comment-format |
| 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 | https://palantir.github.io/tslint/rules/typeof-compare |
| no-misused-new | Warns on apparent attempts to define constructors for interfaces or new for classes. | Accuracy | https://palantir.github.io/tslint/rules/no-var-requires |
| newline-per-chained-call | This style helps to keep code “vertical”, avoiding the need for side-scrolling in IDEs or text editors. | Understandability | https://palantir.github.io/tslint/rules/no-inferrable-types |
| 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 | https://palantir.github.io/tslint/rules/no-redundant-jsdoc |
| no-dynamic-delete | Deleting dynamically computed keys is dangerous and not well optimized. | Accuracy | https://palantir.github.io/tslint/rules/use-default-type-parameter |
| quotemark | Requires single or double quotes for string literals. | Accuracy | https://palantir.github.io/tslint/rules/no-string-literal |
| no-unused-expression | Detects potential errors where an assignment or function call was intended. | Maintainability | https://palantir.github.io/tslint/rules/forin |
| 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. |
Maintainability | https://palantir.github.io/tslint/rules/match-default-export-name |
| no-empty-interface | An empty interface is equivalent to its supertype (or {}). | Maintainability | https://palantir.github.io/tslint/rules/no-any |
| only-arrow-functions | Traditional functions don’t bind lexical scope, which can lead to unexpected behavior when accessing “this”. | Accuracy | https://palantir.github.io/tslint/rules/prefer-switch |
| 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 | https://palantir.github.io/tslint/rules/ban-comma-operator |
| no-void-expression | Requires expressions of type void to appear in statement position. | Maintainability | https://palantir.github.io/tslint/rules/no-conditional-assignment |
| array-type | Requires using either “T[]” or “Array” for arrays. | Maintainability | https://palantir.github.io/tslint/rules/prefer-for-of |
| Prefer-method-signature | Prefer foo(): void over foo: () => void in interfaces and types. | Maintainability | https://palantir.github.io/tslint/rules/promise-function-async |
| 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 | https://palantir.github.io/tslint/rules/no-implicit-dependencies |
| chai-vague-errors | Avoid Chai assertions that result in vague errors. For example, asserting expect(something).to.be.true 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 | https://palantir.github.io/tslint/rules/no-unnecessary-qualifier |
| 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 | https://palantir.github.io/tslint/rules/no-for-in-array |
| 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 | https://palantir.github.io/tslint/rules/prefer-const |
| 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 | https://palantir.github.io/tslint/rules/object-literal-key-quotes |
| 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 | https://palantir.github.io/tslint/rules/typedef |
| 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 | https://palantir.github.io/tslint/rules/class-name |
| 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 | https://palantir.github.io/tslint/rules/prefer-readonly |
| 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 | https://palantir.github.io/tslint/rules/member-access |
| 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 | https://palantir.github.io/tslint/rules/return-undefined |
| 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 | https://palantir.github.io/tslint/rules/no-reference-import |
| 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, live.com) but only to an appropriate subdomain (for example, billing.live.com). 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 | https://palantir.github.io/tslint/rules/no-misused-new |
| 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 | https://palantir.github.io/tslint/rules/no-unused-variable |
| no-empty-interfaces | Do not use empty interfaces. They are compile-time only artifacts and they serve no useful purpose | Maintainability | https://palantir.github.io/tslint/rules/quotemark |
| no-exec-script | Do not use the execScript functions. window.execScript is not crossing browsers, only IE supports it. | Robustness | https://palantir.github.io/tslint/rules/label-position |
| 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 | https://palantir.github.io/tslint/rules/array-type |
| no-invalid-regexp | Do not use invalid regular expression strings in the RegExp constructor. Similar to the ESLint no-invalid-regexp rule | Maintainability | https://palantir.github.io/tslint/rules/prefer-method-signature |
| 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: _.map(list, …). 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 |