Usage of TypeScript's powerful type system decreases specific type of bugs. Linting tools provide additional static code analysis to spot common mistakes and ensure consistency across the large codebase. In each project team decides which of the rules generate an error. In this blog post, I'll cover how to setup a TSLint in your TypeScript project and show some example errors that TSLint spotted for us.
Installing TSLint on an existing project
I am not a big fan of global npm package installations; instead, I install TSLint as a devDependency. The local TSLint allows project members to have the same version on the current project and therefore the output is consistent across team members and build tools.
yarn add tslint --dev
yarn tslint --project ./tsconfig.json
The first line installs tslint as a devDependency. The second line run tslint using yarn, this way I don't have to write
./node_modules/.bin/tslint. As I have an existing TypeScript project, I'll point tslint to the project configuration file.
With init command I could create an empty configuration for the tslint. As an example, I use my current setting file.
"interface-name": [true, "never-prefix"],
"no-implicit-dependencies": [true, "dev"]
The configuration is a JSON file (by default it is named tslint.json). The JSON contains several keys, extends and rules being the most used ones.
In the example, I extend tslint's built-in configuration preset that contains latest recommended rules. When I update tslint, I might get additional errors compared to the previous version as new checks have been created that might be recommended.
As this tslint-config-prettier is not built-in, I need to install it first.
yarn add tslint-config-prettier --dev
In the config file, the order of the extends array is significant. The latter line ("tslint-config-prettier") will override rules from the tslint:latest.
In the example configuration, I have disabled or changed some of the rules.
A rule is a single check that can be either built-in or a custom rule.
Lint rules encode logic for syntactic & semantic checks of TypeScript source code. --TSLint Rules page
Rules can have a configuration, for example, to provide exceptions to the rule or varying levels of strictness. If the rule has a configuration, then they have a schema.
prefer-object-spread is a straightforward rule that has no configuration. The prefer-object-spread check has a description "Enforces the use of the ES2015 object spread operator over Object.assign() where appropriate., " and the rationale section "Object spread allows for better type checking and inference."
In the picture below, I have used TSLint together with Visual Studio Code using a fantastic 3rd party extension.
Behind the scenes, the VS Code extension is using TSLint, so I would get the same error as using
yarn tslint command.
The screenshot has a light bulb, and by clicking it, I get a helpful context menu that allows me to fix the issue automatically! Again, this can also be done from the command-line.
prefer-object-spread is one of the rules that have an automatic fix available, rules with automatic fix can be identified from the list by looking for a keyword "Has Fixer."
If for some reason, I would like to disable that rule then I'll add a new property to the rules:
Or, I can add a comment that in the next line I want to use
Object.assign instead of spread:
Linting tools are not only useful for finding errors and providing consistency across codebase, but also linting tools are great for learning.
&&). In our codebase, those bit operators were correctly used, so I marked them to be valid lines instead of disabling the rule.
Let me know if you have any questions.