Improving Angular style and code quality


The Angular CLI makes our lives a lot easier by scaffolding our projects and generating a lot of boilerplate code and this code usually conforms to the Angular Style guide found here But we also need to make sure our code stays readable, functional and maintainable and with entire teams working on Angular applications, code reviews are not the right place for spotting style errors!

This post describes a couple of things you can do to avoid the typical pitfalls AND improve developer workflow 🙂

Note: this post assumes you use the Angular CLI to start your project. If not, you will have to include the required dependencies yourself. Also, although you are not required to work with Typescript, this post assumes you do.

#1 Make sure team members run TSLint

With every Angular CLI generated project Codelyzer and tslint rules come right out of the box (at least in versions 6.0.x). But if nobody runs these locally, we catch lint errors during CI builds. And that is usually too late, because builds take time and we need this feedback as quickly as possible (preferably with the file still open in the IDE).

Committing-Workflow Hooks to the rescue.

At least with Git, but everybody uses Git right? Git includes a pre-commit hook. This particular hook is run first, before you even type in a commit message and is the perfect stage to ensure we run without lint errors. These hooks are client side (or local) hooks and with the right permissions can be bypassed, altered or deleted. Still I consider them very useful.

In our case we need to run a simple “npm run lint” on every pre-commit and halt if it returns anything other than “0”. Git hooks are simple script files (of any executable script language) located in the hidden .git folder. There are quite a few samples in there for you to explore, but we will provide a very simple pre-commit file:

# If there are lint errors we fail
exec npm run lint


Tip: hooks are not copied over when you clone a directory so team members have to do that themselves. I find it the easiest to have a directory under source control within the repo that contains the scripts.

#2 Extend TSLint with SonarQube rules

Now that we have tslint in place and running on every commit, we can begin to extend the ruleset. I like SonarQube J and besides having a great code analysis server product, the same team also provides a SonarTS TSLint extension. Let’s add this to our ruleset:

npm install tslint-sonarts --save-dev

The next thing we need to do is add the Sonar ruleset to the default tslint configuration. If you have used the Angular CLI to generate the project, you will end up with 2 tslint.json files. If we add our extension to the one located in the src directory, we are good to go:

"extends": ["../tslint.json", "tslint-sonarts"],
"rules": {
"directive-selector": [
"component-selector": [

Now if we run lint, we include the sonar rules!


#3 Have the IDE show style violations

Even before we run the linter or commit our source code, we should have indications on our style errors. All the top JavaScript IDE’s have either support for indicating violations or available through the use of extensions.

For example, to enable TSLint checking in Visual Studio Code you need to install the TSLint extension:


After installation (and reload) the IDE displays the squiggly lines (red curly underlines):


More information on this:

Sublime Plugin:
Visual Studio Code Extension:

 #4 Have the build run tslint

If the code actually reaches the build server it should be free of lint errors. If you want to be sure, you can run the npm task as part of your CI (and other) builds. This will slow down the CI feedback, but ensures code follows your style guide. In case people bypass your Git commit hook, which they will never do of course 😉

For Microsoft TFS/ VSTS this is just another “NPM run command” task. I recommend failing the build if the linter produces errors.



#5 Final tip: don’t stop here

After the linter is in place, you can start extending the scenarios. The next obvious task is to enforce any of your custom rules. Maybe you have guidelines regarding importing 3rd party stuff or specific company coding styles. For example:

Managing RxJS Imports with TSLint

Sample code on GitHub, happy coding!