Codelyzer: TSLint Rules for Angular Static Analysis

Understanding Codelyzer: Angular Static Analysis

Codelyzer is a TSLint plugin that adds Angular-specific static analysis rules, checking things like component selector naming, lifecycle interface usage, and template bindings. It works across Angular CLI projects, NativeScript, and Ionic apps, and hooks in through a tslint.json file that extends its rule set, per the README.

Key Rules for Angular Code Quality

• ✓component-class-suffix and directive-class-suffix check that Angular class names end in Component or Directive, or a custom suffix you configure.
• ✓component-selector and directive-selector enforce a naming convention and prefix for selectors, such as requiring kebab-case elements or camelCase attributes.
• ✓Lifecycle rules — contextual-lifecycle, no-conflicting-lifecycle, use-lifecycle-interface — catch Angular lifecycle hooks that are misused or missing their interface.
• ✓Template rules — template-banana-in-box, template-no-negated-async, template-use-track-by-function, template-cyclomatic-complexity — flag common Angular template mistakes.
• ✓Accessibility-focused template rules, like template-accessibility-alt-text and template-accessibility-valid-aria, are listed as Experimental in the README's rules table.
• ✓no-unused-css flags CSS selectors in a component's stylesheet that don't match anything in its template; it's also marked Experimental.
• ✓Advanced configuration through a .codelyzer.js file lets you plug in custom template and style transforms, such as compiling Sass before analysis, per the README's example.

How to Integrate Codelyzer into Your Project

Codelyzer installs differently depending on your setup. Angular CLI projects get it for free. The README says running ng lint on a project created with ng new applies Codelyzer's Angular rules with no extra work, since components already follow the style guide by default. The angular-seed starter also ships with it wired into its own npm run lint script, per the README. For a custom project, install Codelyzer directly with npm i codelyzer tslint @angular/compiler @angular/core, or pull in the tslint-angular preset (npm i tslint-angular) if you'd rather extend one config than list every rule yourself. Either path needs a tslint.json file that extends "codelyzer" or "tslint-angular", and you can install Codelyzer globally with npm install -g codelyzer if you don't want to call it through node_modules/.bin/tslint.

Configuring and Running Codelyzer

Configuration lives in tslint.json. Extending "codelyzer" and turning on individual rules — component-class-suffix, component-selector, no-input-rename, template-banana-in-box, and dozens more — gives you the Angular-aware checks; the README's custom-installation example lists over 30 of them explicitly. There's also a separate Recommended configuration in the README, drawn from the Angular Style Guide, that sets selector prefixes and class suffixes as arrays so you can match your own project's naming convention. To turn off one rule in a single file instead of project-wide, add a tslint:disable:rule-name comment above the offending code. For non-standard templates or styles, Sass included, the README shows an advanced setup: a .codelyzer.js file at your project root where you define transformStyle and transformTemplate hooks, plus custom interpolation markers and a predefinedDirectives list for template references Codelyzer can't otherwise resolve.

Modern Alternatives for Angular Linting

Common Questions About Codelyzer

The problem it solves

Angular projects that lint with TSLint don't get Angular-aware rules for free — a generic TSLint config catches TypeScript problems but has no idea what a valid component selector, a correctly implemented lifecycle hook, or a safe template binding looks like. Codelyzer closes that specific gap by packaging the Angular Style Guide's conventions — selector prefixes, class suffixes, lifecycle interface usage, template checks — as a TSLint rule set instead of leaving each team to hand-roll its own.

Best use cases

• •Angular teams still standardized on TSLint who want the framework's own style guide — selector prefixes, class suffixes, lifecycle interfaces — enforced automatically instead of caught in code review.
• •NativeScript or Ionic apps built with Angular, since the README explicitly lists both as supported alongside plain web apps.
• •Projects built on the angular-seed starter, which the README says ships with Codelyzer already wired into its npm run lint script.
• •Teams that need per-file rule exceptions: the tslint:disable marker turns off one rule, like template-use-track-by-function, without disabling the whole linter.

Who should try it — and who should skip

Try Codelyzer if your Angular project is already on TSLint and you want the framework's style guide enforced without hand-writing rules — the selector, lifecycle, and template checks plus the tslint:disable escape hatch make it a fairly complete drop-in. Skip it if you're starting fresh or moving off TSLint: Codelyzer's own README sends ESLint users to angular-eslint instead, so a new project has little reason to adopt a TSLint-only rule set today.

Related repositories