Pure heroes

Automate code review with static code analysis.
TSLint & SonarQube configuration and rules for the Tour of Heroes original Angular tutorial. Overview of ways to speed up the code review process.
Check out this project on stackblitz.

Table of contents

• Motivation
• Built With
• Getting Started
• TSLint
• SonarQube vs SonarCloud
• CI pipeline
• License
• Credits

Motivation

It is always good to ask yourself about the quality of the code, whether it will be easy to maintain, and maybe management also wants to know about it. When the SonarQube report can help, TSLint can check and enforce the high quality code of your peers.

Built With

• Angular v. 8.0.0 - The web framework used
• Node.js v. 10.16.3 - JavaScript runtime built
• NPM v. 6.9.0 - Dependency Management
• CircleCI - Continuous Integration

Getting Started

Show instructions on how to get a copy of the project up and running on your local machine with SonarCloud

Prerequisites

• VS Code (you will get extensions that I recommend) or other IDE
• Node.js v. 10.16.3 or higher

Installing

1. Clone repo

   $ git clone https://github.com/crappylime/pure-heroes.git

2. Go to the project root

   $ cd pure-heroes 

3. Install dependencies

   $ npm i

4. Run tests with code coverage

   $ npm run test-ci

5. Log in to SonarCloud. You can log in with your Github account.

6. Click analyze new project.

   

7. Click set up manually and fill out the form.

   

8. Click analyze your project manually.

   

9. Click other, Linux and copy values of Dsonar.login, Dsonar.projectKey and Dsonar.organization.

   

10. Paste copied values to sonar-project.properties:

    - sonar.projectKey=crappylime_pure-heroes
    + sonar.projectKey=YOUR_KEY
    - sonar.organization=crappylime
    + sonar.organization=YOUR_ORGANIZATION
    + sonar.login=YOUR_LOGIN

11. Run sonar

    $ npm run sonar

12. Check out the produced SonarQube analysis on SonarCloud.

TSLint

the standard linter for TypeScript. The default linting tool for Angular.

1. Why?

   Having lint rules in place means that you will get a nice error when you are doing something that you should not be. This will enforce consistency in your application and readability. Some lint rules even come with fixes to resolve the lint error. If you want to configure your own custom lint rule, you can do that too.

2. Configuration

   The default configuration for Angular is specified in the project's tslint.json file.

   tslint.json extends "tslint:recommended" to include rules recommended for TypeScript projects, they can be found here.

   The Angular tslint.json file also contains Codelyzer rules that are specific to Angular:

     "rulesDirectory": [
       "codelyzer"
   ]
   

   All tslint rules are described here along with the given scheme and example.

   The TS rules are divided into 5 categories:

   • TS-specific,
   • Functionality,
   • Maintainability,
   • Style,
   • Format.

   Each rule can have one of the flags: TS Only, Has Fixer, Requires type info.

   There is a playground available to test each of them.

3. Custom rule sets from the community

   If you follow the Angular Style Guide, there are several npm packages that implement these rules:

   • tslint-angular,
   • angular-tslint-rules

4. You can exclude files from linting in the angular.json, for example tests:

       "lint": {
         "builder": "@angular-devkit/build-angular:tslint",
         "options": {
           "tsConfig": [
             "tsconfig.app.json",
             "tsconfig.spec.json",
             "e2e/tsconfig.json"
           ],
           "exclude": [
   -         "**/node_modules/**"
   +         "**/node_modules/**",
   +         "**/*.spec.ts"
           ]
         }

   You can also exclude some files in the tslint.json using linterOptions?: { exclude?: string[] }.

5. Running tslint

   lint script is defined in the package.json:

   "lint": "ng lint"
   

   ng lint has several flags. Among them --fix that automatically fixes errors for rules marked with Has Fixer.

   You can run it with npm:

   $ npm run lint

   or

   $ ng lint

   or with tslint cli, for example:

   $ tslint ./src/**/*.ts -t verbose

   will lint only ts files within src directory and display the errors in verbose format.

6. Are default rules not enough?

   It depends on your team's workflow. However, if you tend to put the same comment over and over when reviewing the code, you can probably automate it.

   Some tslint rules that I found interesting in the angular-tslint-rules: no-implicit-dependencies, prefer-template, typedef, strict-boolean-expressions, no-boolean-literal-compare, arrow-return-shorthand, max-file-line-count, restrict-plus-operands, prefer-conditional-expression, template-cyclomatic-complexity, prefer-readonly.

7. Deprecation

   TSLint will be deprecated some time in 2019. See this issue for more details: Roadmap: TSLint → ESLint. If you're interested in helping with the TSLint/ESLint migration, please check out our OSS Fellowship program.

   --tslint readme as of 15th October 2019.

SonarQube vs SonarCloud

• SonarQube:

  • platform for continuous inspection of code quality,
  • performs automatic reviews with static analysis of code, detects bugs, code smells, security vulnerabilities,
  • on 20+ programming languages,
  • installed and runs on computers of the person or organization using the software,
  • community version available.

• SonarCloud is the same as SonarQube, but works in the cloud, free for open-source projects - used in this repository.

Show instructions on how to integrate an existing Angular project with Sonar

1. Install sonar-scanner:

   $ npm i -D sonar-scanner

2. Install tslint-sonarts:

   $ npm i -D tslint-sonarts

3. Add the sonar script to your package.json:

     "scripts": {
       "build": "ng build --prod",
   +   "sonar": "sonar-scanner",
       "e2e": "e2e"
     }

4. Create sonar-project.properties file in the project root, content example:

   sonar.host.url=https://sonarcloud.io
   sonar.projectKey=crappylime_pure-heroes
   sonar.organization=crappylime
   sonar.projectName=pure-heroes
   sonar.projectVersion=1.0
   sonar.sources=src
   sonar.sourceEncoding=UTF-8
   sonar.ts.tslintconfigpath=tslint.json
   sonar.exclusions=**/*.spec.ts,**/src/assets/**/*,**/src/favicon.ico,**/src/karma.conf.js
   sonar.typescript.exclusions=**/main.ts,**/environments/environment*.ts,**/*routing.module.ts
   sonar.tests.inclusions=**/*.spec.ts
   sonar.javascript.lcov.reportPaths=coverage/angular.io-example/lcov.info
   

   SonarQube docs:

   • Analysis properties
   • Narrowing the focus with sonar.sources.

5. Do not forget to change in sonar-project.properties the following:

   • sonar.host.url to your host if you have SonarQube deployed
   • sonar.projectKey
   • sonar.organization
   • sonar.projectName
   • add sonar.login if necessary

6. Extend reports types with lcov in the karma.conf.js file:

     coverageInstanbulReporter: {}
   -   reports: ['html', 'lcovonly', 'text-summary'],
   +   reports: ['html', 'lcov', 'lcovonly', 'text-summary'],

7. Extend tslint.json with sonar rules for typescript that are documented here:

     {
   -   "extends": "tslint:recommended",
   +   "extends": ["tslint:recommended", "tslint-sonarts"],

8. Run tests with code coverage:

   $ ng test --code-coverage --no-watch --browsers=ChromeHeadless

9. Trigger the sonar analysis for project:

   $ npm run sonar

CI Pipeline

CI Pipeline example with linter, tests and sonar:
- build that fails on linter
- build that succeeds

License

This project is licensed under the MIT License - see the LICENSE file for details

Credits

• analyzed code from Tour of Heroes App and Tutorial
• inspiration for sonar-project.properties content from Isaac Martinez
• why customize tslint from 11. Make use of lint rules