AiA 147: Codelyzer and Static Analysis Tools for Angular with Minko Gechev

The week on Adventures in Angular features panelists Alyssa Nicoll, Shi Resnick, Lukas Ruebbelk, and Charles Max Wood. The special guest this week is Minko Gechev who is here to discuss Codelyzer. Minko is currently working on a start up. Angular JavaScript is the programming language that excites him the most.

How do you work in a start up and still have free time?

He tries to find an overlap between the work he's doing in the startup and work he does in his spare time. This is why he had previous work that was completely Angular (Angular Seed). This startup is more complicated because the overlap isn't as much.

What is Codelyzer?      

Last year, he worked on the Angular Style Guide. He thought it was a good idea to have an automated way to verify a given project that follows the Angular Style Guide. He built on top of that and built Angular and provided similar style checks on top of templates, Angular CSS Styles inside of the components, and the Angular expressions inside of the templates. Codelyzer is a tool for static code analysis for Angular applications.

How is it used?                                              

It can be used as a set of rules on top of tslint. You install it with mpm. Then tslint performs static analysis and verifies whether the source code follows some style guidelines that our team has agreed upon. When Codelyzer is used, we can also analyze the templates on Angular applications. After that, you can confirm it follows these rules by running tslint on top of the entire project.

How many of the default tslint rules do you agree with?

Minko states that that is a lot of tslint and Angular rules that align and that he agrees with most of them. He does admit there are some he finds annoying, such as specific semi colon rules. Overall, he believes that if the team has agreed upon the rule, it is following in order to avoid arguing.

What do you recommend as the best way to add Codelyzer to a project that started without it?

He thinks you should add one rule at a time. All the wordings will be fixed one by one, eventually fixing the entire project. He has also started working on style analysis on top of the application, which is performance analysis. He doesn’t know what data the application will process. But he still considers that a given component will have performance if it has a huge -- in the template. So static analysis we can find such templates and eventually warn the users about eventual performance issues that are possible.

How hard is it to add or change in Codelyzer?

It might be slightly harder compared to tslint because there are more things that can be statically verified. In Tslint there's a visitor pattern. There is a classical design from the Ganga; it is used for the reversal of syntax 3 of a Typescript code. So when you implement the visitor pattern, you visit a specific construct, verify whether the name follows some guidelines. It is pretty much the same thing in Codelyzer but you can also implement the same visitor pattern for visiting the template of the component. Currently, the project has more than 20 contributors. It looks complicated but not if you spend 30 to 40 minutes looking at the code.

What was the motivation behind going deep into Angular?

The style was easy for static (automated) verification. This way saved a lot of time from code reviews. Code reviews still have to be performed, but at least can skip the verification from style guides because they can be automatically done.

He likes compilers, it is the front end of a compiler: analyzing Syntax 3 part of a compiler itself interesting algorithms. There is another rule from Codelyzer being worked on that isn't completely stable yet. It is to find out which styles are actually used inside of the template. Codelyzer can find out some of the styles that are no longer applied to some of the styles within the template. This is not r