AngularRB linter rules library to enforce a consistent code style.
You can install @ngxrb/rules, and all its dependencies, using npm.
npm install @ngxrb/rules tslint codelyzer tslint-sonarts tslint-eslint-rules tslint-microsoft-contrib tslint-clean-code --save-dev
- Codelyzer >= 4.3.0: A set of tslint rules for static code analysis of Angular TypeScript projects.
- ESLint rules for TSLint >= 5.3.0: Improve your TSLint with the missing ESLint rules.
- SonarTS >= 1.6.0: Static code analyzer for TypeScript detecting bugs and suspicious patterns in your code.
- tslint-microsoft-contrib >= 5.0.0: A set of TSLint rules used on some Microsoft projects.
- tslint-clean-code >= 0.2.7: A set of TSLint rules used to enforce Clean Code practices. Inspired by Clean Code: A Handbook of Agile Software Craftsmanship.
To use these TSLint rules, use configuration inheritance via the extends keyword.
A sample configuration is shown below, where tslint.json lives adjacent to your node_modules folder:
{
"extends": ["ngxrb-rules"],
"rules": {
// override tslint rules here
}
}
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
- MUST NOT allow function declarations in nested blocks [doc]
- Arrow lambdas MUST prefer return as
() => x
over() => { return x; }
[doc] - MUST require arrow functions as callbacks [doc]
- MUST NOT allow variable declarations in nested blocks [doc]
- MUST use an empty newline after variable declarations [doc]
- MUST ensure that the results of typeof are compared against a valid string [doc]
- MUST NOT allow sparse arrays [doc]
- MUST avoid a duplicate case label [doc]
- MUST NOT allow assigning to the exception in a catch block [doc]
- MUST enforce error handling in callbacks [doc]
- MUST NOT use constant expressions in conditions [doc]
- MUST NOT use double-negation boolean casts in a boolean context [doc]
- MUST NOT allow comparisons where both sides are exactly the same [doc]
- MUST NOT allow unnecessary semicolons [doc]
- SHOULD avoid code that looks like two expressions but is actually one [doc]
- MUST enforce valid JSDoc comments [doc]
- SHOULD NOT use control characters in regular expressions [doc]
- MUST NOT use empty character classes in regular expressions [doc]
- MUST NOT allow invalid regular expression strings in the
RegExp
constructor [doc] - MUST NOT allow multiple spaces in a regular expression literal [doc]
- MUST enforce sorting import declarations within module [doc]
The MIT License (MIT)
Copyright (c) 2018 Ricardo Javier Barrios Díaz