codelyzer

What is codelyzer?

Codelyzer is a static analysis tool for Angular projects that helps developers follow best practices and coding standards. It integrates with TSLint to provide a set of rules specific to Angular applications.

What are codelyzer's main functionalities?

Template Accessibility

Codelyzer can check for accessibility issues in Angular templates, such as ensuring that interactive elements are accessible to screen readers.

<button (click)="doSomething()">Click me</button>

Component Class Style

Codelyzer enforces consistent coding styles in Angular component classes, such as proper use of dependency injection and class member ordering.

class MyComponent { constructor(private myService: MyService) {} }

Template Syntax

Codelyzer checks for correct usage of Angular template syntax, ensuring that structural directives like *ngIf and *ngFor are used properly.

<div *ngIf="isVisible">Content</div>

Lifecycle Hooks

Codelyzer ensures that Angular lifecycle hooks are implemented correctly and follow best practices.

class MyComponent implements OnInit { ngOnInit() { console.log('Initialized'); } }

Other packages similar to codelyzer

eslint-plugin-angular

ESLint plugin for AngularJS applications. It provides a set of rules for AngularJS, similar to how Codelyzer provides rules for Angular. However, it is focused on AngularJS (1.x) rather than Angular (2+).

angular-eslint

A set of ESLint rules, configurations, and tools to lint Angular applications. It is similar to Codelyzer but uses ESLint instead of TSLint, which is beneficial as TSLint is deprecated.

tslint

TSLint is a static analysis tool for TypeScript code. While it is not specific to Angular, it can be extended with custom rules like those provided by Codelyzer. Note that TSLint is deprecated in favor of ESLint.

README

Codelyzer

A set of tslint rules for static code analysis of Angular 2 TypeScript projects.

Install

npm install --save-dev codelyzer

Then hop to your tslint.json and add rulesDirectory which points to codelyzer, like this:

{
  "rulesDirectory": [
    "node_modules/codelyzer"
  ],
  "rules":{
  }
}

Now you can apply codelyzer rules to your tslint config. Enjoy!

Recommended configuration

Below you can find a recommended configuration which is based on the Angular 2 Style Guide.

{
  "directive-selector-name": [true, "camelCase"],
  "component-selector-name": [true, "kebab-case"],
  "directive-selector-type": [true, "attribute"],
  "component-selector-type": [true, "element"],
  "directive-selector-prefix": [true, "sg"],
  "component-selector-prefix": [true, "sg"],
  "use-input-property-decorator": true,
  "use-output-property-decorator": true,
  "use-host-property-decorator": true,
  "no-attribute-parameter-decorator": true,
  "no-input-rename": true,
  "no-output-rename": true,
  "no-forward-ref" :true,
  "use-life-cycle-interface": true,
  "use-pipe-transform-interface": true,
  "pipe-naming": [true, "camelCase", "sg"],
  "component-class-suffix": true,
  "directive-class-suffix": true
}

Roadmap

• Directive selector type.
• Directive selector name convention.
• Directive selector name prefix.
• Component selector type.
• Component selector name convention.
• Component selector name prefix.
• Use @Input instead of inputs decorator property.
• Use @Output instead of outputs decorator property.
• Use @HostListeners and @HostBindings instead of host decorator property.
• Implement life-cycle hooks explicitly.
• Implement Pipe transform interface for pipes.
• Proper naming for pipes (kebab-case, optionally prefixed).
• Do not rename outputs.
• Do not rename inputs.
• Do not use forwardRef.
• Do not use the @Attribute decorator.
• Proper naming of directives and components (name plus (Directive|Component) suffix).
• Do not use nativeElement injected with ElementRef.
• Externalize template above n lines of code.
• Rise a warning for impure pipes.
• Do not declare global providers.
• Follow convention for naming the routes.
• Use @Injectable instead of @Inject.
• Single export per module, except facade modules.
• Proper naming of modules (kebab-case followed by module type followed by extension for regular modules, module name plus extension name for facades).
• Verify if used directive is declared in the current component or any parent component.
• Verify that property or method used in the template exists in the current context.
• Locate component templates in the same directory.
• Locate tests in the same directory (rise optional warning when no test file is found).
• Rise warning on complex logic inside of the templates.
• Do not manipulate elements referenced within the template.

License

MIT