practical-tslint-config
A TSLint ruleset based on the Airbnb JavaScript style guide, Prettier, and TypeScript best practices.
Goal
To build a ruleset that promotes consistency, efficiency, optimized code, and most of all to not get in the developer's way.
Installation
npm install practical-tslint-config --save-dev
Usage
The only thing that your tslint.json
should consist of:
"extends": "practical-tslint-config"
Some of the rules in the set require type info. Therefore when you run the linter via CLI,
specifying the --project
flag is recommended.
tslint --project tsconfig.json --config tslint.json
Prettier
This ruleset is specifically designed to not lint for any rules that you can set (and automatically fix) through Prettier. Therefore it is highly recommended that you configure Prettier for your project with this custom configuration.
npm install prettier prettier-airbnb-config --save-dev
Custom Rules
The Airbnb JavaScript style guide does an excellent job of being a mostly reasonable guide to JavaScript. However, linting rules don't exist for every recommendation in the style guide nor do they capture all of TypeScript's nuances. Furthermore, a fair number of rules can be fixed using Prettier. Therefore the other rules that this configuration lints for that aren't outlined in the Airbnb guide are mentioned here.
Imports
-
c1.1 Requires that import statements be alphabetized and grouped.
// bad;;// good;;
Variables
- c2.1 Variables initialized with
let
or destructuring initializer should not be assigned toundefined
.
Values in JavaScript default to undefined. There’s no need to do so manually.
// bad; // good;
-
c2.2 Disallows shadowing variable declarations.
When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs. Shadowing makes it impossible to access the variable in the containing scope and obscures to what value an identifier actually refers.
// bad;print; // logs 'shadow'.// good;print; // logs 'no shadow'.
Classes
-
c3.1 Requires explicit visibility declarations for class members.
Members lacking a visibility declaration may be an indication of an accidental leak of class internals.
// bad// good
-
c3.2 Enforces member ordering.
A consistent ordering for class members can make classes easier to read, navigate, and edit.
// bad// good
-
c3.3 Warns if
super()
appears twice in a constructor.The second call to
super()
will fail at runtime.// bad// good
Interfaces
-
c4.1 Forbids empty interfaces.
// bad// good -
c4.2 Requires interface names to not have an “I” prefix
// bad// good
Functions
-
c5.1 Disallows empty blocks.
Empty blocks are often indicators of missing code.
// bad// good
Maintainability
-
c6.1 Disallows use of the
null
keyword literal.To remove confusion over the two similar values, it’s better to stick with just
undefined
.// bad;// good;
-
c6.2 Disallows non-null assertions using the
!
postfix operator.Using non-null assertion cancels the benefits of the strict null checking mode.
// bad// good