In this article we’ll look at how to set up the linting configuration, in the tslint.json file.

Linting Configuration

When I discovered linting it was like all my prayers had been answered. While it doesn’t solve all problems, linting gets rid of a good portion of code-writing errors. The configuration here is pretty basic, but you can adjust it to your tastes:

JavaScript

1

2

{

"class-name":true,

This first rule ensures that the class names are all in Pascal-case (LikeThis), the way the gods intended.

JavaScript

1

2

3

4

"comment-format":[

true,

"check-space"

],

Next up is how comments are formatted. I loathe when comments start without a space (//like this), since I think it makes them harder to read.

JavaScript

1

2

3

4

"indent":[

true,

"spaces"

],

All my code is indented with spaces, which this rule enforces. If you say you like tabs, just know that I pray everyday for you. Also, you can set it to tabs.

JavaScript

1

"no-duplicate-variable":true,

This one is sort of obvious, but accidents happen and you will eventually double up on a variable declaration.

JavaScript

1

"no-eval":true,

Say no to eval, it’s only one letter separated from “evil”.

JavaScript

1

"no-internal-module":true,

In TypeScript there’s a module keyword that tends to cause confusion, so this forces using namespace instead.

JavaScript

1

"no-trailing-whitespace":true,

I once worked with a guy who had tons of white space at the end of every line, it was infuriating to work on his code. The nice thing is that most modern editors & IDEs will strip trailing white space for you anyways, but it’s always good to have a second check.

JavaScript

1

"no-var-keyword":true,

This is one of those that some may disagree with. I think that in modern development with the block-scoped let and const at our disposal, the day of var is slowly ending.

JavaScript

1

2

3

4

5

"one-line":[

true,

"check-open-brace",

"check-whitespace"

],

Maybe a confusing name for a rule, but this one says that given an expression, the specified rule parameters must also be on the same line as the expression. I have it set up to ensure that opening braces are on the same line and preceded by a white space.

JavaScript

1

2

3

4

"quotemark":[

true,

"single"

],

I also use single-quote marks because I like my code like that. If you don’t, use double-quote marks because the world is your oyster.

JavaScript

1

"semicolon":true,

This isn’t CoffeeScript, so if you aren’t putting semicolons at the end of lines, you’re probably causing yourself more headaches than it’s worth.

JavaScript

1

2

3

4

"triple-equals":[

true,

"allow-null-check"

],

Using triple-equals (===) is a must. JavaScript’s type inference has more than its share of documented quirks. And this is TypeScript, so we don’t need to infer anything!

JavaScript

1

2

3

4

5

6

7

8

9

10

"typedef-whitespace":[

true,

{

"call-signature":"nospace",

"index-signature":"nospace",

"parameter":"nospace",

"property-declaration":"nospace",

"variable-declaration":"nospace"

}

],

This establishes the rules on white space for defining types. These rules say that to the left of a type definition colon, we should not have a space for declaring the return type of a function, index types, function parameters, properties, or variables. This argument also takes a second argument, which specifies how spacing to the right of the colon should be.

JavaScript

1

2

3

4

5

"variable-name":[

true,

"ban-keywords",

"check-format"

],

When checking variable names, I want to make sure that I don’t use any TypeScript keywords and that I only use camel-case (likeThis) or all upper-case (LIKE_THIS).

JavaScript

1

2

3

4

5

6

7

8

"whitespace":[

true,

"check-branch",

"check-decl",

"check-operator",

"check-separator",

"check-type"

],

The last rule does more checking of white space in the code (there sure are a lot of white space concerns here). I check that branching statements, variable declarations’ equals sign, operators, separators (, / ;), and type definitions all have the proper spacing around them.

The Final Product

The full configuration looks like this:

JavaScript

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

{

"rules":{

"class-name":true,

"comment-format":[

true,

"check-space"

],

"indent":[

true,

"spaces"

],

"no-duplicate-variable":true,

"no-eval":true,

"no-internal-module":true,

"no-trailing-whitespace":true,

"no-var-keyword":true,

"one-line":[

true,

"check-open-brace",

"check-whitespace"

],

"quotemark":[

true,

"single"

],

"semicolon":true,

"triple-equals":[

true,

"allow-null-check"

],

"typedef-whitespace":[

true,

{

"call-signature":"nospace",

"index-signature":"nospace",

"parameter":"nospace",

"property-declaration":"nospace",

"variable-declaration":"nospace"

}

],

"variable-name":[

true,

"ban-keywords",

"check-format"

],

"whitespace":[

true,

"check-branch",

"check-decl",

"check-operator",

"check-separator",

"check-type"

]

}

}

And That’s It!

Pretty straightforward stuff again, but will save you a ton of time in coding errors. In the next post, I’ll explain my configuration for the TypeScript compiler, through the tsconfig.json file.