Adventures in Angular

Adventures in Angular is a weekly podcast dedicated to the Angular JavaScript framework and related technologies, tools, languages, and practices.

Subscribe

Get episodes automatically

147

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


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

The week on Adventures in Angular features panelists Alyssa Nicoll, Shai Reznik, Lukas Ruebbelke, 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 ready yet but it will be ready in a couple of configurations.

Is the idea of searching through of finding either redundant or non-used style, is this something Codelyzer's doing for the very first time (no one has ever done it) or are there tools that this would replace?

For Angular, there is no other tool like that. JavaScript or HTML may be close. The Browser can do that.

If I want to write a rule do I take the abstract syntax and tell it what to look for? How does that work?

You can’t learn it by heart, so I usually copy and paste the existing code and then modify it. It is a standard typescript rule so you need to provide an abstract rule; you'll need to provide the visitor. If the rule is super complicated, you need four visitors.

Are you relying on tslint to break things down into tokens and the abstract syntax and then doing the work from there?

Yeah. I did some extensions of tslint. Just extending tslint because it would have been too much work to create something from scratch. He is relying on tslint’s error reporting.

So in order to set this up on a CI machine, it needs to be able to run node and install some mpm packages?

Yes. Run node, install tslint, install Codelyzer and have this rule directory with the Codelyzer rules inside tslint.

Is there a visual proof for knowing what the rule does?

There is documentation on codelyzer.com/rules.

Picks:

Shai:

  • Reflect API
  • Driving on the right side of the road
  • Minko Gechev

Alyssa:

Lukas:

Charles:

Minko:

This episode is sponsored by

comments powered by Disqus
x