Terminus TSLint Frontend Configuration

A collection of TypeScript & Angular lint rules for Terminus frontend codebases.

For ESLint configuration, see: https://github.com/GetTerminus/eslint-config-frontend

Table of Contents

• Installation
• Rulesets overview
• Set up
  • CI
  • Development
  • Testing
• Rule Decisions

Installation

$ yarn add tslint @terminus/tslint-config-frontend -D

Rulesets overview

There are 3 rulesets defined for TSLint:

1. CI: This is the default ruleset. This is meant to be used during your CI builds so it throws hard errors when issues are found.
2. Development: This enforces all the same rules as the CI ruleset but infractions are reported as warnings rather than errors.
3. Testing: This ruleset extends the development ruleset and then further disables certain tests that make writing spec files less arduous (no-non-null-assertion, component naming requirements, etc).

Set up

You will need to set up separate configs and scripts for each ruleset: ci, development and testing. Creating a custom script call for each within your package.json will allow for easy composability of commands once all linters are set up.

CI

CI Rules

1. Create the file and extend our ruleset

Create a TSLint config file at the root level named tslint.ci.json and extend the base ruleset:

{
  "extends": "@terminus/tslint-config-frontend"
}

Linting during the CI process is the most strict and will fail if any issues are found. The only way a linting issue makes it to CI is because someone didn't lint before commiting.

2. Add a linting command to package.json

• The --project flag reference should point to the primary app tsconfig file.
• The --config flag reference should point to the ci tslint file.

{
  "name": "My Project",
  "scripts": {
    "lint:tslint:ci": "npx tslint --project ./src/tsconfig.app.json --config ./tslint.ci.json"
  }
}

Development

This ruleset extends the ci ruleset but softens the rules to turn many stylistic issues into warnings in order to not impede development.

Development Rules

1. Create the file and extend our ruleset

Create a TSLint config file at the root level named tslint.json and extend the development ruleset:

{
  "extends": "@terminus/tslint-config-frontend/development"
}

2. Add project specific rules

NOTE: When adjusting a TSLint rule, the entire rule must be defined again.

{
  "extends": "@terminus/tslint-config-frontend/development",
  "rules": {
    "component-selector": [
      true,
      "element",
      "foo",
      "kebab-case"
    ],
    "directive-selector": [
      true,
      "attribute",
      "foo",
      "camelCase"
    ],
    "pipe-prefix": [
      true,
      "foo"
    ]
  }
}

3. Add a linting command to package.json

After the --project flag, the reference should point to your primary app tsconfig file.

{
  "name": "My Project",
  "scripts": {
    "lint:tslint": "npx tslint --project ./src/tsconfig.app.json"
  }
}

Testing

Testing Rules

1. Create the file and extend our ruleset

Create a TSLint config file at the root level named tslint.spec.json and extend the testing ruleset:

{
  "extends": "@terminus/tslint-config-frontend/testing"
}

2. Add a linting command to package.json

• The --project flag reference should point to the spec tsconfig file.
• The --config flag reference should point to the spec tslint file.

{
  "name": "My Project",
  "scripts": {
    "lint:tslint:spec": "npx tslint --project ./src/tsconfig.spec.json --config ./tslint.spec.json"
  }
}

Rule Decisions

Each rule is accompanied by a comment outlining the reasoning behind the decision to include the rule.

For most rules, see ci.js.