Rule: no-shadowed-variable

Disallows shadowing variable declarations.

Rationale

When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs. Shadowing makes it impossible to access the variable in the containing scope and obscures to what value an identifier actually refers. Compare the following snippets:

const a = 'no shadow';
function print() {
    console.log(a);
}
print(); // logs 'no shadow'.

const a = 'no shadow';
function print() {
    const a = 'shadow'; // TSLint will complain here.
    console.log(a);
}
print(); // logs 'shadow'.

ESLint has an equivalent rule. For more background information, refer to this MDN closure doc.

Config

You can optionally pass an object to disable checking for certain kinds of declarations. Possible keys are "class", "enum", "function", "import", "interface", "namespace", "typeAlias" and "typeParameter". You can also pass "underscore" to ignore variable names that begin with _. Just set the value to false for the check you want to disable. All checks default to true, i.e. are enabled by default. Note that you cannot disable variables and parameters.

The option "temporalDeadZone" defaults to true which shows errors when shadowing block scoped declarations in their temporal dead zone. When set to false parameters, classes, enums and variables declared with let or const are not considered shadowed if the shadowing occurs within their temporal dead zone.

The following example shows how the "temporalDeadZone" option changes the linting result:

function fn(value) {
    if (value) {
        const tmp = value; // no error on this line if "temporalDeadZone" is false
        return tmp;
    }
    let tmp = undefined;
    if (!value) {
        const tmp = value; // this line always contains an error
        return tmp;
    }
}

Examples

"no-shadowed-variable": true

"no-shadowed-variable": true,[object Object]

Schema

{
  "type": "object",
  "properties": {
    "class": {
      "type": "boolean"
    },
    "enum": {
      "type": "boolean"
    },
    "function": {
      "type": "boolean"
    },
    "import": {
      "type": "boolean"
    },
    "interface": {
      "type": "boolean"
    },
    "namespace": {
      "type": "boolean"
    },
    "typeAlias": {
      "type": "boolean"
    },
    "typeParameter": {
      "type": "boolean"
    },
    "temporalDeadZone": {
      "type": "boolean"
    },
    "underscore": {
      "type": "boolean"
    }
  }
}

For more information see this page.

Rule: no-empty

Disallows empty blocks.

Blocks with a comment inside are not considered empty.

Rationale

Empty blocks are often indicators of missing code.

Config

If allow-empty-catch is specified, then catch blocks are allowed to be empty. If allow-empty-functions is specified, then function definitions are allowed to be empty.

Examples

"no-empty": true

"no-empty": true,allow-empty-catch

"no-empty": true,allow-empty-functions

"no-empty": true,allow-empty-catch,allow-empty-functions

Schema

{
  "type": "array",
  "items": {
    "anyOf": [
      {
        "type": "string",
        "enum": [
          "allow-empty-catch"
        ]
      },
      {
        "type": "string",
        "enum": [
          "allow-empty-functions"
        ]
      }
    ]
  }
}

For more information see this page.

Rule: no-console

Bans the use of specified console methods.

Rationale

In general, console methods aren't appropriate for production code.

Config

A list of method names to ban. If no method names are provided, all console methods are banned.

Examples

"no-console": true,log,error

Schema

{
  "type": "array",
  "items": {
    "type": "string"
  }
}

For more information see this page.

Rule: callable-types

An interface or literal type with just a call signature can be written as a function type.

Rationale

style

Notes

• TypeScript Only
• Has Fix

Config

Not configurable.

For more information see this page.

Rule: array-type

Requires using either 'T[]' or 'Array<t>' for arrays.</t>

Notes

• TypeScript Only
• Has Fix

Config

One of the following arguments must be provided:

• "array" enforces use of T[] for all types T.
• "generic" enforces use of Array<T> for all types T.
• "array-simple" enforces use of T[] if T is a simple type (primitive or type reference).

Examples

"array-type": true,array

"array-type": true,generic

"array-type": true,array-simple

Schema

{
  "type": "string",
  "enum": [
    "array",
    "generic",
    "array-simple"
  ]
}

For more information see this page.

Rule: triple-equals

Requires === and !== in place of == and !=.

Config

Two arguments may be optionally provided:

• "allow-null-check" allows == and != when comparing to null.
• "allow-undefined-check" allows == and != when comparing to undefined.

Examples

"triple-equals": true

"triple-equals": true,allow-null-check

"triple-equals": true,allow-undefined-check

Schema

{
  "type": "array",
  "items": {
    "type": "string",
    "enum": [
      "allow-null-check",
      "allow-undefined-check"
    ]
  },
  "minLength": 0,
  "maxLength": 2
}

For more information see this page.

Rule: no-console

Bans the use of specified console methods.

Rationale

In general, console methods aren't appropriate for production code.

Config

A list of method names to ban. If no method names are provided, all console methods are banned.

Examples

"no-console": true,log,error

Schema

{
  "type": "array",
  "items": {
    "type": "string"
  }
}

For more information see this page.

Rule: array-type

Requires using either 'T[]' or 'Array<t>' for arrays.</t>

Notes

• TypeScript Only
• Has Fix

Config

One of the following arguments must be provided:

• "array" enforces use of T[] for all types T.
• "generic" enforces use of Array<T> for all types T.
• "array-simple" enforces use of T[] if T is a simple type (primitive or type reference).

Examples

"array-type": true,array

"array-type": true,generic

"array-type": true,array-simple

Schema

{
  "type": "string",
  "enum": [
    "array",
    "generic",
    "array-simple"
  ]
}

For more information see this page.

Rule: no-empty

Disallows empty blocks.

Blocks with a comment inside are not considered empty.

Rationale

Empty blocks are often indicators of missing code.

Config

If allow-empty-catch is specified, then catch blocks are allowed to be empty. If allow-empty-functions is specified, then function definitions are allowed to be empty.

Examples

"no-empty": true

"no-empty": true,allow-empty-catch

"no-empty": true,allow-empty-functions

"no-empty": true,allow-empty-catch,allow-empty-functions

Schema

{
  "type": "array",
  "items": {
    "anyOf": [
      {
        "type": "string",
        "enum": [
          "allow-empty-catch"
        ]
      },
      {
        "type": "string",
        "enum": [
          "allow-empty-functions"
        ]
      }
    ]
  }
}

For more information see this page.

Rule: semicolon

Enforces consistent semicolon usage at the end of every statement.

Notes

• Has Fix

Config

One of the following arguments must be provided:

• "always" enforces semicolons at the end of every statement.
• "never" disallows semicolons at the end of every statement except for when they are necessary.

The following arguments may be optionally provided:

• "ignore-interfaces" skips checking semicolons at the end of interface members.
• "ignore-bound-class-methods" skips checking semicolons at the end of bound class methods.
• "strict-bound-class-methods" disables any special handling of bound class methods and treats them as any other assignment. This option overrides "ignore-bound-class-methods".

Examples

"semicolon": true,always

"semicolon": true,never

"semicolon": true,always,ignore-interfaces

"semicolon": true,always,ignore-bound-class-methods

Schema

{
  "type": "array",
  "items": [
    {
      "type": "string",
      "enum": [
        "always",
        "never"
      ]
    },
    {
      "type": "string",
      "enum": [
        "ignore-interfaces"
      ]
    }
  ],
  "additionalItems": false
}

For more information see this page.

Rule: 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 ES2015-style imports or import foo = require('foo') imports.

Rationale

AMD-style require([]) and CommonJS-style require("") statements are environment-specific and more difficult to statically analyze.

ES2015-style imports are part of the JavaScript language specfication and recommended as the path going forward. TypeScript will compile them to environment-specific forms as needed.

Notes

• TypeScript Only

Config

Not configurable.

Examples

"no-var-requires": true

For more information see this page.