CHAPTER 3
TSLint is a powerful linting option, and the default installed by Angular. However, there are other linters to consider. While TSLint will still be available, the author has indicated the program will be deprecated, and development on ESLint will be his priority. You can still use TSLint, but at some point, Angular may switch to ESLint. In this chapter, we will cover installing ESLint and using it in an Angular application, and we will look at SonarLint, a linting tool you can integrate into most IDEs.
SonarQube is a static code analysis tool that provides extremely thorough code analysis. Lint checking generally works on a statement level, for example, to report use of the debugger keyword, or to require lines end with a semicolon. There are some features that will check a component module, such as member ordering (how fields and methods are ordered in a component), but for the most part they focus on style rules, formatting, maintainability, and so on.
SonarQube is more focused on the overall, looking at things like function size (functions shouldn’t be too big), credentials (should not be hard-coded), and commented-out code (comments should not contain code). Adding SonarLint (from SonarQube) to your lint process can identify issues beyond what the lint checker detects.
You can search for SonarLint in the Visual Studio Marketplace, or find it directly at this link.
Once you install it, you might be prompted to install a Java runtime. SonarLint should find the Java runtime automatically, or you can add the location in your Visual Studio Code settings.
{
"sonarlint.ls.javaHome": "C:\\Program Files\\Java\\jre1.8.0_131"
}
You can visit this link if you want to install it in other code editors or integrated development environments. The top of the page lists other IDEs SonarLint can be integrated with.
SonarLint has over 100 TypeScript rules, and they are classified as code smells, bugs, and security hotspots.
Code smells are items that technically will compile, but possibly point to a problem. For example, duplicated code in multiple locations will compile but cause issues if the code needs to be updated and one or more of the locations is not updated. This bug would be very hard to catch.
Figure 2 shows an example code smell identified by SonarLint.

Figure 2: SonarLint code smell
By right-clicking on the light bulb icon, you will be able to bring up the related help or disable the rule itself. In the example shown in Figure 2, the delete command replaced the array element with undefined, rather than removing the element from the array (which array.splice will do).
Bugs are code elements that compile but won’t do what the code suggests. Figure 3 shows an example of a bug detected by SonarLint.

Figure 3: SonarLint bug
The in command works on array indexes, not values. SonarLint shows hint text with the suggested fix, and you can also right-click the light bulb for more details about the issue.
Security hotspots identify areas of the code that pose a security risk. Figure 4 shows an example where the credentials were hard-coded, which SonarLint identified as a potential security concern.

Figure 4: SonarLint security hotspot
Some of the issues raised by SonarLint may also be caught by the lint checker, but installing the SonarLint extension into your IDE will help you catch the errors while coding, so they can be addressed prior to the lint step.
ESLint is the linter package that the TypeScript development team has decided to use. In some future Angular release, it is possible that the CLI will generate the lint configuration to use ESLint instead. You can add ESLint to your current configuration (while keeping TSLint) if you want to get familiar with this linter.
The first step is to install the ESLint package using npm. The syntax is:
npm install eslint –save-dev
Once you’ve installed ESLint, you will need to create a configuration file using the command syntax:
eslint –init
This command will lead you through a series of questions and then create the .eslintrc.json file, which contains the ESLint configuration options. Figure 5 shows the questions.

Figure 5: Creating ESLint config file
Once you’ve installed ESLint and created the configuration file, you can run the following command to use it against your files.
eslint ./src/**/*.ts --ext .ts --ignore-pattern **/*.spec.ts --fix-dry-run
The command looks for all .ts files in the indicated directory, ignoring the spec files (testing source files). We also asked it to show us any fixes it could potentially apply. If you run eslint by itself, you can get a complete list of command-line parameters.
You can also add the output information if you want to save the lint output to a file. For example, adding the following code will save the output to a JSON file called lint.json in the current directory:
--format json --o lint.json
This can be handy if you want some sort of automated CI process to check for linting issues.
Figure 6 shows a sample output from eslint.

Figure 6: eslint output example
It is interesting to note that tslint gave the app-routing module no errors, but eslint detected the unused stringify command and the loop variable error in a for loop. This is not to say one is better than the other, but that the tools can be used together to analyze and improve your software.
In this chapter, we looked at SonarLint and ESLint, two additional tools to consider adding to your Angular application development environment. See Chapter 9 to find out more about these two tools.