As we have seen, the compiler does lots of useful checks against our TypeScript code to help us write error-free code. We can take this a step further and lint the code to help us make our code even more readable and maintainable. TSLint is a linter that is very popular in TypeScript projects, and we will explore it in this section.

The home page for TSLint is at https://palantir.github.io/tslint/.

We'll install TSLint in the next section.

We'll install TSLint in this section, along with a Visual Studio Code extension that will highlight linting problems right in the code:

1. Let's install TSLint globally via npm, as follows:

npm install -g tslint

2. Now, we can open Visual Studio Code and go to the extensions area (Ctrl + Shift + X) and type tslint in the search box at the top-left. The extension is called TSLint and was published by egamma:

3. We need to click the Install option to install the extension.
4. After it has been installed, we'll need to reload Visual Studio Code for the extension to become enabled.

Now that this extension is installed, along with TSLint globally, linting errors will be highlighted right in our code, as we'll see in the following sections.

The rules that tslint uses when checking our code are configurable in a file called tslint.json. In order to explore some of the rules, we first need a TypeScript file:

1. So, let's create a file called orderDetail.ts with the following content in Visual Studio Code:

export interface Product {
  name: string;
  unitPrice: number;
}

export class OrderDetail {
  product: Product;
  quantity: number;
  getTotal(discount: number): number {
    const priceWithoutDiscount = this.product.unitPrice * this.quantity;
    const discountAmount = priceWithoutDiscount * discount;
    return priceWithoutDiscount - discountAmount;
  }
}

2. Let's now create a tslint.json file. We define the rules we want to implement in a rules field. Let's add the following rule:

{
  "rules": {
    "member-access": true
  }
}

3. A full list of the rules can be found at: https://palantir.github.io/tslint/rules/. The member-access rule forces us to explicitly declare the access modifier for classes. We haven't explicitly defined the property and method access modifiers in the OrderDetail class because they are public by default. So, with our linting rule in place, Visual Studio Code will highlight the lack of access modifiers to us:

4. As we put a public access modifier in front of the properties and method, the warnings go away:

export class OrderDetail {
  public product: Product;
  public quantity: number;
  public getTotal(discount: number): number {
    const priceWithoutDiscount = this.product.unitPrice * this.quantity;
    const discountAmount = priceWithoutDiscount * discount;
    return priceWithoutDiscount - discountAmount;
  }
}

The member-access rule forces us to write more code – how can this be a good thing? The rule is useful if you're reading the code and don't know TypeScript well enough to understand that class members without access modifiers are public. So, it's great if our team consists of developers who don't know TypeScript that well yet, but not necessarily for an experienced team of TypeScript developers.

Lots of the tslint rules are like member-access – in some teams, they will work well and in others, they don't really add value. This is why rules are configurable!

tslint has a handy collection of built-in rulesets that can be used. We can use these by specifying the ruleset name in the extends field. We can use multiple rulesets by putting all their names in the array:

1. Let's adopt the opinionated set of rules that tslint ships with, called "tslint:recommended". So, in our tslint.json file, let's remove the rules field and add an extends field, as follows:

{
  "extends": ["tslint:recommended"]
}

We immediately get lint errors when tslint.json is saved. The error is complaining about the lack of an I prefix on our Product interface. The logic behind the rule is that, while reading code, if a type starts with an I, we immediately know that it is an interface.

2. Let's pretend that this rule isn't valuable to us. We can override this rule from "tslint:recommended" in the "rules" field. The rule is called "interface-name". So, let's override this to false:

{
  "extends": ["tslint:recommended"],
  "rules": {
    "interface-name": false
  }
}

When tslint.json is saved, the linting errors immediately go away.

We can exclude files from the linting process. This is useful for excluding third-party code. We do this by specifying an array of files in an exclude field in the linterOptions field:

{
 "extends": ["tslint:recommended"],
 "linterOptions": {
 "exclude": ["node_modules/**/*.ts"]
 }
}

The preceding configuration excludes third-party node packages from the linting process.

Now that we've added TSLint to our tool belt, we are going to add another tool that will automatically format our code for us. This will help our code adhere to some of the code formattings TSLint rules.