How I Use Angular 2 with Webpack: Linting

Reading time: 2 minutes

A disclaimer: I’m not claiming to be an expert here and I’m open to any corrections or input from everyone; this is just what’s worked for me so far. Please enjoy!

As I mentioned in the first post of this series, this series looks out how I have been using Angular 2 with Webpack. The topics in the series are:

  1. Directory Structure
  2. Node Modules & NPM Configuration
  3. Typings
  4. Code Linting
  5. TypeScript Configuration
  6. Karma Configuration
  7. Webpack Configuration
  8. Sample Application

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:

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

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.

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.

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

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

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

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.

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.

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.

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.

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.

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!

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.

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).

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:

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.

Leave a Comment

Your email address will not be published. Required fields are marked *