The first thing I do on any Typescript/Angular project

Having worked with many Typescript projects throughout my career, there is one thing that I usually do as my first contribution to the project.
This article focuses on projects created with the Angular CLI and its default tslint.json configuration.

tslint — fix

tslint has this awesome flag called “ — fix”. It allows us to solve many codestyle issues automatically.

Following is an excerpt of tslint rules that I always add/enable on any Typescript project that I start working with.

After having added all additional tslint rules you then call

tslint — fix — project tsconfig.json

to have many lint violations fixed without you doing anything else.

Stricter ts-lint rules

"unnecessary-constructor": true,

Removes empty constructors (usually autogenerated with “ng generate”)

"prefer-const": true,

Automatically refactors ‘let‘ and ‘var’ to const (as long as they’re not reassigned)

"no-unnecessary-initializer": true,

Forbids a ‘var’/’let’ statement or destructuring initializer to be initialized to ‘undefined’.

"no-unused-expression": true,

Disallows unused expression statements.

"no-var-keyword": true,

Disallows the use of ‘var’.

"no-debugger": true,

Disallows the use of ‘debugger’. Useful when you often use that keyword for debugging purposes.

"no-duplicate-super": true,

Self-explanatory.

"no-construct": true,

Disallows the use of (uppercase) String, Number, Boolean constructors (oftentimes spotted on projects written by Java developers)

"no-unused-variable": [true, { “ignore-pattern”: “^_” }]

Disallows unused variable. Also removes unused imports when using ‘ — fix’

"member-ordering": [true, { 
  "order": [
    "constructor", 
    "static-field", 
    "instance-field", 
    "static-method",
    "instance-method"
  ]
}],

Orders members in a class. I like constructors to be always at the very beginning of a class definition. This is especially true in Angular projects so you immediately see what things the given class depends on.

"arrow-return-shorthand": true,

() => x vs () => {return x;})
I find the shorthand much more readable, than the regular way of returning things.

"array-type": [true, "array-simple"],

This rule enforces the use of T[] notation for most array definitions, like string[], number[], any[].
UNLESS, the definition is a complex type, e.g. number | string, then the resulting array type would be formatted as Array<number | string>.

Again, I find the Array<T | U> notation more readable for complex types, while T[] is more readable for simple ones.

Code formatting

When looking at PRs, how often were you annoyed because the diffs contained unnecessary formatting changes, different amount of whitespaces, spaces vs tabs, etc?

I know I have been countless times.

To the rescue comes prettier, a opinionated code formatter with a minimal set of options so teams don’t have to (aren’t able to) argue on formatting and can just write code.

npm install -D prettier tslint-config-prettier

Additionally we install “tslint-config-prettier” which disables clashing tslint rules. We just need to add it to the extends property of tslint.json

"extends": ["tslint:recommended", "tslint-config-prettier"],

I also like to create a prettier config file (.prettierrc) with the following options that I found work very well in Angular projects.

{
  "singleQuote": true,
  "printWidth": 100,
  "trailingComma": "es5"
}

Next, you call the following command to run prettier on all files under ‘/src’

npx prettier — write src

Automatic code formatting

Code formatting is great, but only when everyone remembers to run it.

If there only was a tool that would take that burden off of us.

npm i -D husky lint-staged

Husky is a tool to run commands in response to git events, like precommit, prepush, etc.

Lint-staged runs specified commands only on staged files (thus saving time, especially on huge code bases).

With the following config added to package.json, we make use of husky to run lint-staged everytime we commit code, and lint-staged in turns runs prettier on all changed files.

"lint-staged": {
  "src/**/*.ts": [
    "tslint --project tsconfig.json --fix --force"
  ],
  "src/**/*": [
    "prettier --write"
  ]
},

Do you have any additional tslint rules or lint-staged commands that I haven’t mentioned?

Let me know in the comments.