palantir / tslint

:vertical_traffic_light: An extensible linter for the TypeScript language

TSLint

⚠️ TSLint is deprecated.

See this issue for more details: Roadmap: TSLint → ESLint. If you're interested in helping with the TSLint/ESLint migration, check out the typescript-eslint roadmap.

TSLint is an extensible static analysis tool that checks TypeScript code for readability, maintainability, and functionality errors. It is widely supported across modern editors & build systems and can be customized with your own lint rules, configurations, and formatters.

TSLint currently supports:

• an extensive set of core rules
• custom lint rules
• custom formatters (failure reporters)
• inline disabling and enabling of rules with comment flags in source code
• configuration presets (tslint:latest, tslint-react, etc.) and plugin composition
• automatic fixing of formatting & style violations
• integration with MSBuild, Grunt, Gulp, Atom, Eclipse, Emacs, Sublime, Vim, Visual Studio 2015, Visual Studio 2017, Visual Studio code (alternative: use this extension for TS <3.2), WebStorm and more

Installation & Usage

Please refer to the full installation & usage documentation on the TSLint website. There, you'll find information about

• configuration,
• core rules,
• core formatters, and
• customization of TSLint.
• inline disabling and enabling of rules with comment flags

TSLint Playground

There is a sandbox environment for TSLint at palantir.github.io/tslint-playground, which can be used to test rules and see how TSLint works. Issues can be filed against tslint-playground here.

Custom Rules & Plugins

Custom rule sets from Palantir

• tslint-react - Lint rules related to React & JSX.
• tslint-blueprint - Lint rules to enforce best practices with blueprintjs libraries

Custom rule sets from the community

If we don't have all the rules you're looking for, you can either write your own custom rules or use rules implementations developed by the community. The repos below are a good source of custom rules:

• ESLint rules for TSLint - Improve your TSLint with the missing ESLint Rules
• tslint-microsoft-contrib - A set of TSLint rules used on some Microsoft projects
• codelyzer - A set of tslint rules for static code analysis of Angular TypeScript projects
• vrsource-tslint-rules
• tslint-immutable - TSLint rules to disable mutation in TypeScript
• tslint-consistent-codestyle - TSLint rules to enforce consistent code style in TypeScript
• tslint-sonarts - Bug-finding rules based on advanced code models to spot hard to find errors in TypeScript
• tslint-clean-code - A set of TSLint rules inspired by the Clean Code handbook
• rxjs-tslint-rules - TSLint rules for RxJS

Development

Prerequisites:

• node v7+
• yarn v1.0+

Quick Start

git clone [email protected]:palantir/tslint.git --config core.autocrlf=input --config core.eol=lf
yarn
yarn compile
yarn test

tslint's Issues

Clarify ident rule

I'm not really sure what ident is about. Is it supposed to check indent levels? What about them?

We use tabs for indenting, and I cannot get this rule to give helpful info.

I think this rule or another could check for indenting consistency, maybe also like smarttabs in JSHint.

comment-format rule triggers on ///<reference>'s

The comment-format rule gets triggered by TypeScript's typical ///<reference path="foo.ts"> comments.

Is this intentional? Maybe a special-case is in order to let these pass?

New rule: variable names unique within their scope

By default TypeScript doesn't do anything to warn against scope confusion like this:

var myvar = "first value";
if (true) {
    var myvar = "second value";
}
console.log(myvar); // Outputs: "second value"

Developers from C#/Java backgrounds may expect the output to be "first value", but JavaScript's variable hoisting means this is not the case. The normal mitigation is the "single var per scope" rule, but that has a whole range of annoying drawbacks.

This is something a linting tool can easily fix - it just needs to warn if the same variable name is used more than once within a scope. Would you be interested in enabling such an optional rule in tslint?

I can provide a pull request with implementation and tests if desired - it's pretty simple.

External formatter modules?

Is (or will there be) support for external formatters?

Similar to how JSHint and ESLint both accept a path to a module, or otherwise like Mocha that accepts a module name to be require()-ed.

This because I maintain a set of reporters that use a specific format that works excellent with smart editors like WebStorm and I would like to make and use one for TSLint as well.

I have these 2 already: original jshint-path-reporter and recent eslint-path-formatter that I use daily, and they need a little TSLint brother :)

Add travis-ci and npm badges to readme

Maybe it is cool to add some badges to the readme.md, so we can see what the latest npm version is.

This goes for grunt-tslint as well.

If you need the markdown snippets you can copy it from one of my projects

Also you might want to look into your travis-ci hook as it is failing on the typescript git-module. I don't know why, but they have very helpful support if you email them.

It would be nice if it'd work to test any Pull Requests that might come your way (hint, hint :)

Incorrect array indentation

tslint incorrectly flags indentation of object literals in arrays such as

[
    {
        a: 4
    }, {
        b: 10
    }
]

Catch trailing commas within object hashes

Write a rule to catch the following:

{
  a: "alan",
  b: "bob",
  c: "cathy",
}

Warn on the trailing comma for the last key-value pair.

Support else / catch on next line

It should be possible to enforce the position of trailing block headers like else/catch statements:

Currently this is expected:

if (myVar) {
    //...
} else {
    //...
}

Otherwise you get the 'misplaced else' warning.

But we want the trailing block bumped a line like this::

if (myVar) {
    //...
}
else {
    //...
}

Or for try/catch

try {
    //..
}
catch (e) {
    //..
}
finally {
    //..
}

An all other similar structures.

We find it easier to read as the keyword is tight on the left margin and the closing brace's position enforces a nearly blank line, just like in the starting block.

Support typescript 0.9.5

Warning: Property 'codeGenTarget' of object # is not a function Use --force to continue.
TypeError: Property 'codeGenTarget' of object # is not a function
at Object.getParseOptions (C:\usr\sources\node_modules\grunt-typescript\node_modules\typescript\bin\typescript.js:33181:53)
at LanguageService.createSyntaxTree (C:\usr\sources\node_modules\tslint\lib\tslint.js:59772:113)
at LanguageService.getSyntaxTreeInternal (C:\usr\sources\node_modules\tslint\lib\tslint.js:59754:35)
at LanguageService.getSyntaxTree (C:\usr\sources\node_modules\tslint\lib\tslint.js:59746:25)
at Linter.lint (C:\usr\sources\node_modules\tslint\lib\tslint.js:62891:46)
at C:\usr\sources\node_modules\grunt-tslint\tasks\tslint.js:37:29
at Array.forEach (native)
at Object. (C:\usr\sources\node_modules\grunt-tslint\tasks\tslint.js:30:19)
at Object. (C:\usr\sources\node_modules\grunt\lib\grunt\task.js:264:15)
at Object.thisTask.fn (C:\usr\sources\node_modules\grunt\lib\grunt\task.js:82:16)
at Object. (C:\usr\sources\node_modules\grunt\lib\util\task.js:282:30)
at Task.runTaskFn (C:\usr\sources\node_modules\grunt\lib\util\task.js:235:24)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:281:12)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:215:7)
at Task.runTaskFn (C:\usr\sources\node_modules\grunt\lib\util\task.js:238:9)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:281:12)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:215:7)
at Task.runTaskFn (C:\usr\sources\node_modules\grunt\lib\util\task.js:238:9)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:281:12)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:215:7)
at Task.runTaskFn (C:\usr\sources\node_modules\grunt\lib\util\task.js:238:9)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:281:12)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:215:7)
at Task.runTaskFn (C:\usr\sources\node_modules\grunt\lib\util\task.js:238:9)
at Task. (C:\usr\sources\node_modules\grunt\lib\util\task.js:281:12)
at Task.start (C:\usr\sources\node_modules\grunt\lib\util\task.js:290:5)
at Object.grunt.tasks (C:\usr\sources\node_modules\grunt\lib\grunt.js:155:8)
at Object.module.exports as cli
at Object. (C:\Users\usr\AppData\Roaming\npm\node_modules\grunt-cli\bin\grunt:41:20)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:901:3

block is empty should allow for field declarations in constructor parameters

The following code currently reports as "block is empty", but because it's a constructor with parameters that define fields, the empty block is needed and shouldn't be considered an error.

class Compile implements ng.IDirective {
    constructor(private $compile: ng.ICompileService) {
    }
}

Use TypeScript as a package dependency

Right now, it's a git submodule. Make it an npm package dependency instead.

Similar classes trigger duplicate-variable rule

Similar classes in same module trigger the rule:

module MyModule {
    export class ClassA {
        id:string;
        label:string;
        index:number;
    }

    export class ClassB {
        id:string;
        label:string;
        index:number;
        title:number;
    }
}

>> src/raw.ts[9, 3]: duplicate variable: 'id'
>> src/raw.ts[10, 3]: duplicate variable: 'label'
>> src/raw.ts[11, 3]: duplicate variable: 'index'

Request: ///<reference> formatting rule

I was cleaning some code and noticed I had inconsistent formatting in references:

/// <reference path="foo.d.ts" />
///<reference path="foo.d.ts" />
///<reference path="foo.d.ts"/>
///<reference path="foo.d.ts">

I think this is the most correct form (max. whitespace).

/// <reference path="foo.d.ts" />

Maybe keep custom attributes (it is XML tag)

/// <reference path="foo.d.ts" special="bar" />

Windows usage instructions

Can we have some instructions about using tslint on Windows? Tried cscript tslint-cli.js -f myfile.ts but no joy

File ending with a block comment and a newline still shows newline error

Incorrect duplicate-variable rule error

With this code:

module tmp {
    var path = require('path');
    export class MyType {
        path:string;
    }
}

I get this error:

>> src/tmp.ts[4, 3]: duplicate variable: 'path'

I think this should pass: class members do not shadow their module vars.

Enforce spacing around operators

For example, the whitespace around =, !=, ==, etc... We'd like to enforce a single space around these operators.

New rule: unused import

It would be great to catch unused module imports.

Rule to enforce IInterface naming convention

Specifically the "I" at the beginning is what we'd want to enforce.

improve unreachable rule

the current code block should not raise an error:

    for (var o in obj) {
        if (o) continue;
        console.log("o");
    }

Error for whitespace in object type

The following code generates an error:

    public get(key: K, valueLoader?: { (): V; }): V {

Running "tslint:files" (tslint) task

web/modules/common/cache.ts[25, 40]: unexpected tab width: expected 8, got 0

Add a link to quick-start/reference config

I was replacing my old tslint file with the 0.3.0 update and see many new rules.

Is there a quick-start/reference JSON with all the rules and all their options enabled?

Might be nice to link that from the README so we can quickly get a config ready (and then start relaxing rules where needed)

(of course there is a tslint.json there but is might be the one used on the project itself with some practical changes)

`use strict`; rule random false result

Something is triggering this rule in some files that have the statement:

module git {
    'use-strict';

}

Split whitespace rule

These should probably be separate rules. From the docs:

• enforces whitespace between a keyword and a conditional,
• surrounding an operator,
• and enclosing "=" within variable declarations
• and import/export statements.

Also it check the space between a var declaration and its type, that should also be a separate rule:

var name: string = 'value';
         ^

Request: 'use strict' rule

Requires to specify use strict'; for every top level scope. Equivalent to JSHint's strict -> http://www.jshint.com/docs/options/#strict

For TS it should be the top-most module, or all the functions if you don't use a module.

Quote style should probably mesh with the quotemark rule.

Bug with one-liner object literals.

This oneliner literal:

var valueA = {a: 1, b: 'B', c: [1, 2, 3], d: {a: 11, b: 'bravo', c: [11, 22, 33]}};

First gives this warning:

>> test/modules/xm/hash.ts[39, 73]: duplicate key 'a'
>> test/modules/xm/hash.ts[39, 79]: duplicate key 'b'

Later followed by:

>> test/modules/xm/hash.ts[39, 18]: unexpected tab width: expected 16, got 0
>> test/modules/xm/hash.ts[39, 32]: unexpected tab width: expected 16, got 0
>> test/modules/xm/hash.ts[39, 36]: unexpected tab width: expected 20, got 0
>> test/modules/xm/hash.ts[39, 48]: unexpected tab width: expected 20, got 0
>> test/modules/xm/hash.ts[39, 55]: unexpected tab width: expected 20, got 0
>> test/modules/xm/hash.ts[39, 73]: unexpected tab width: expected 16, got 0
>> test/modules/xm/hash.ts[39, 79]: unexpected tab width: expected 16, got 0

block is empty should allow an empty block containing a comment

That is how it works with out code style checking tools.

Add new comments control

It will be very helpful for me if you extend this cool tool by adding new control that checks if every class, method and function is commented.

Thanks

Unable to disable rules with options in them

Migrate grunt's typescript plugin to grunt-ts

grunt-ts is better maintained and is already on 0.9.5.

Indentation control error

Indentation control in tslint disallows me to write a pretty function calls.

registerController('baseCtrl',
                    BaseCtrl,
                    [
                        "$scope",
                        "$compile",
                        "$http",
                        "$routeParams"
                    ]);
/**
* For lines 4-7 it raises error:
* "Unexpected tab width, expected 4, got 24"
*/

OR

show(addr, function(data) {
                alert(data);
            }
    );
/**
* For line 2 it raises error:
* "Unexpected tab width, expected 4, got 16"
*/

OR

show(addr,
    (data) =>{
        alert(data);
    },
    "hello",
    "how",
    "are",
    "you"
    );

/**
* For line 3 it raises error:
* "Unexpected tab width, expected 4, got 8"
*/

tslint plugins

Create tslint plugins for frame-work aware linting like Backbone, Angular etc.

User-defined formatters shouldn't need to be specified with two commandline options

Currently, in order for a user to use their own formatter with the CLI, they need to specify both the directory where the formatter is located and the formatter name in two separate commandline options. But since only one formatter is ever used, there's no good reason to do this from a user perspective -- just makes using a formatter with tslint more complicated. So this should be changed to just use a single commandline argument.

for loops with no variable declaration cause "missing whitespace" error

The following snippet causes an unnecessary "missing whitespace" error.

for (x = 0, y = 0; x < 2; ++x) {
}

CLI ouput in JSON OR any custom format

Please add support for custom reporters. Please implement a similar --reporter flag so we can get the errors in the desired format.

Like JsHint provided formatter. We have it here:

https://github.com/madskristensen/WebEssentials2013/blob/master/EditorExtensions/Resources/Scripts/jshint-node-reporter.js

We need to transform:

[
  {
    "name":"C:\\Users\\Adeel\\Documents\\Visual Studio 2013\\WebSites\\WebSite1\\type.ts",
    "failure":"missing semicolon",
    "startPosition":{
      "position":29,
      "line":1,
      "character":7
    },
    "endPosition":{
      "position":29,
      "line":1,
      "character":7
    }
  }
]

into

[
  {
    "File":"C:\\Users\\Adeel\\Documents\\Visual Studio 2013\\WebSites\\WebSite1\\type.ts",
    "Message":"missing semicolon",
    "Line":1,
    "Column":7
  }
]

(Btw, what's the difference b/w position and character?)

We had to use this hack to transform it into the desired format. Would be nice if the reporter feature is provided OOTB.

Thanks.

Can't run tslint without config file.

tslint is installed from npm.
ubuntu.

tslint -f ./client/scripts/app.ts 
unable to find tslint configuration

Separate out single-line object literals into its own rule

Right now, it's a part of the indentation rule, which might get confusing.

default switch case after a break statement causes "unreachable code" warning

New rule: unused variable

It would be great to catch unused variables

maxLineLengthRule: wrong calculation on Windows

In our project we use a maximum line length rule of 120 characters. Lines with exactly 120 characters pass this rule on the computers of my co-workers who all run Linux, but they do not pass on my Windows machine unless I set the limit to 121. Looking into the code I see that the calculation takes the difference of two line start positions minus 1 as the line length. I guess thats for the line break. But on Windows a line break is 2 characters long, and so the calculation is wrong.

(We have our git configured so that it adapts line break characters to the OS defaults, that's why my co-workers have other line break characters than I. But that's not the cause of the problem - the rule should not take the line break into account regardless which and how many characters are used to encode it.)

npm borked the 0.4.1 update

I was updating my (grunt-)tslint but it looks like npm is suffering some problems (happens a lot):

It cannot find the tarball: https://registry.npmjs.org/tslint/-/tslint-0.4.1.tgz

Not sure if this is temporary or needs a re-publish.

Using variable name _this.

I´d like to use variable names that starts with underscore.

var _this;

But it causes "variable name must be in camelcase or uppercase" error.
I'm not sure if is it right or not.

CLI - provide compiler switch --help

Most of npm's have details when we do node path\to\npm-name --help.

In tslintrc, it shows collapsed list of commands followed by this message:

Missing required arguments: f

Please give us a dedicated --help switch (/argument) for elaboration on usage.

Thanks.

Support to temporarily disable rules

This looks great, we extensively used jshint and jslint before switching to typescript and we were hoping to find an equivalent.

We used to use the syntax

/*jshint bitwise: false*/

quite a bit to allow certain rules to be broken in places. Are there any plans to allow a similar style with

/*tslint bitwise: false*/

Sample TsLintRc file with ALL options

I found this gist very useful, which contains all the possible .jshitnrc options with comments. It was easy for us to adjust our desire settings from this super-set.

Please provide a similar gist, or a sample .tslintrc somewhere in the repo.

Add rule names to failures

Add rule names to failure objects, create a new formatter (prose-verbose or just verbose) that does the same thing as prose but prepends the rule name, add the rule name to the json formatter.

add option to allow the use of string literals

Would it be possible to update the no-string-literal rule so when an interface contains a string literal signature it allows its use?

The AngularJS definitions have this on the ng.IAttribute interface which is where my errors are coming from. I'd like to use string literals in this instance but not elsewhere in my code.

Don't transform rule names with leading or trailing non-word-characters

I found a weird behaviour in the way rules are enabled:

Today I restarted from a new tslint.json: when editing the settings I keep renamed JSON elements with the properties or value I don't use around in my file (so I don't forget about them in a new tslint version).

For years I use this 'json comment' trick by padding the properties with some underscores, for example:

"__whitespace": [true,
    "check-type"
],
"whitespace": [true,
    "check-branch",
    "check-decl",
    "check-separator",
    "check-operator"
]

But the util you use (underscore_string's camelize()) will strip these leading underscores: I verified this by adding a extra character to my commented copy:

So this is properly ignored:

"x__whitespace": [
    true,
    "check-type"
],

This is unexpected behaviour (magic transforms). I think for correctness the logic should not blindly use camelise() but check if the value starts and ends with a word character (stricter is better).

Switch causes Unreachable code

When I write this code:

var trySwitch = function(num) {
    switch (num) {
        case 1:
            console.log("OK", 1);
            break;
        case 2:
            console.log("OK", 2);
            break;
        case 3:
            console.log("OK", 3);
            break;
        case 4:
            console.log("OK", 4);
            break;
    }
};

on the lines 6,9,12 tslint shows error:
"Unreachable code"
This is caused by break statements.

I found this error only in [email protected]

String literal access rule is incorrect

The rule should only complain if there's actually a better way to rewrite a string-literal access. For example: a["blah"] should throw an error since it can be rewritten as a.blah, but a["123"] or a["hey there"] shouldn't.