fulls1z3/angular-tslint-rules

Shared TSLint & codelyzer rules to enforce a consistent code style for Angular development

angular-tslint-rules

Shared TSLint & codelyzer rules to enforce a consistent code style for Angular development

Please support this project by simply putting a Github star. Share this library with friends on Twitter and everywhere else you can.

The value of the software produced is directly affected by the quality of the codebase, and not every developer might

• be aware of the potential pitfalls of certain constructions in TypeScript,
• be introduced into certain conventions when using the Angular framework,
• know that not every developer is as capable in understanding an elegant (but abstract) solution as the original developer.

For that purpose, we need to use static code analysis tools such as TSLint and codelyzer to check readability, maintainability, and functionality errors.

Although complying with these tools may seem to appear as undesired overhead or may limit creativity, it becomes easier for any new developers to read, preventing a lot of time/frustration spent figuring out the structure and characteristics of the code.

Containing a set of TSLint and codelyzer rules, angular-tslint-rules has been compiled using many contributions from colleagues, commercial/open-source projects and some other sources from the Internet, as well as years of development using the Angular framework.

NOTE

All TSLint rules covered by this project are explained on this article https://medium.com/burak-tasci/angular-tslint-rules-a-configuration-preset-for-both-tslint-codelyzer-8b5fa1455908, in depth.

If you have questions, comments or suggestions, just create an issue on this repository. I'll try to revise and republish these rules with new insights, experiences and remarks in alignment with the updates on TSLint and codelyzer.

Contributing

If you want to file a bug, contribute some code, or improve documentation, please read up on the following contribution guidelines:

• Issue guidelines
• Contributing guidelines
• Coding rules
• ChangeLog

Thanks to

• JetBrains, for their support to this open source project with free WebStorm licenses.

License

The MIT License (MIT)

Copyright (c) 2019 Burak Tasci

angular-tslint-rules's Issues

remove rules without implementation in codelyzer 4.x

I'm submitting a ...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[X] Feature request
[ ] Documentation issue or request

Current behavior
After updating to Angular 5.0.1 and TsLint 5.8.1 I get the following messagre when running tslint:

Could not find implementations for the following rules specified in the configuration:
    templates-use-public
    no-access-missing-member
    invoke-injectable
    template-to-ng-template

Expected/desired behavior
No error shown

Minimal reproduction of the problem with instructions
Install all dependencies as outlined below and run tslint -p ./tslint.json --fix --force

What is the motivation / use case for changing the behavior?
Suppress the console message.

Environment

    "@angular/animations": "^5.0.1",
    "@angular/cdk": "^5.0.0-rc0",
    "@angular/common": "^5.0.1",
    "@angular/compiler": "^5.0.1",
    "@angular/core": "^5.0.1",
    "@angular/flex-layout": "2.0.0-beta.10-4905443",
    "@angular/forms": "^5.0.1",
    "@angular/http": "^5.0.1",
    "@angular/material": "^5.0.0-rc0",
    "@angular/platform-browser": "^5.0.1",
    "@angular/platform-browser-dynamic": "^5.0.1",
    "@angular/platform-server": "^5.0.1",
    "@angular/router": "^5.0.1",
    "@nguniversal/express-engine": "^5.0.0-beta.5",
    "@ngx-cache/core": "^4.0.1",
    "@ngx-translate/core": "^8.0.0",
    "@ngx-translate/http-loader": "^2.0.0",
    "@ngx-universal/translate-loader": "^4.0.1",
    "@types/lodash": "^4.14.82",
    "core-js": "^2.4.1",
    "hammerjs": "^2.0.8",
    "lodash": "^4.17.4",
    "ngx-cookie-service": "^1.0.9",
    "rxjs": "^5.5.2",
    "spider-detector": "^1.0.18",
    "zone.js": "^0.8.18"

• For Tooling issues:

    "@angular/cli": "^1.5.0",
    "@angular/compiler-cli": "^5.0.1",
    "@angular/language-service": "^5.0.1",
    "@types/jasmine": "~2.6.3",
    "@types/jasminewd2": "~2.0.2",
    "@types/node": "~8.0.50",
    "angular-tslint-rules": "^1.0.4",
    "codelyzer": "~4.0.1",
    "jasmine-core": "~2.8.0",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~1.7.0",
    "karma-chrome-launcher": "~2.2.0",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "^1.2.1",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "parse5": "git+https://github.com/ghego1/parse5.git",
    "protractor": "~5.2.0",
    "ts-loader": "^3.1.1",
    "ts-node": "~3.3.0",
    "tslint": "^5.8.0",
    "typescript": ">=2.4.2 <2.5.0",
    "webpack-node-externals": "^1.6.0"

Support Codelyzer 5

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior

warning " > [email protected]" has incorrect peer dependency "codelyzer@>=4.5.0 <5.0.0".

Expected/desired behavior
No warning.

What is the motivation / use case for changing the behavior?
Warningless :)

Other
What was the reason to remove support for 5.0.0?

blank line between angular and regular imports

Hi,

versions

    "angular-tslint-rules": "^1.12.0",
    "tslint": "^5.12.0",
    "typescript": "^2.8.0"

I believe Angular Style Guide forces us to use a blank line between @angular imports and regular imports.

So grouped-imports should be

"grouped-imports": false

Else tslint says:

Import sources of the same type (package, same folder, different folder) must be grouped together.tslint(ordered-imports)

example, this fails with grouped-imports: true

import { Component, OnDestroy, OnInit } from '@angular/core';
import { ActivatedRoute } from '@angular/router';

import * as _ from 'lodash';
import { Subject } from 'rxjs';

no-implicit-dependencies should be [true, "dev"]

I'm submitting a ... (check one with "x")

[x] Feature request

Current behavior
The lint rule no-implicit-depencies has it's setting to true

Expected/desired behavior
It should be [true, "dev"]

Minimal reproduction of the problem with instructions
angular-cli create a project, install angular tslint rules and run.

What is the motivation / use case for changing the behavior?
angular or angular-cli usually uses dependencies and devDependencies in package.json. If you run tslint over the whole code including for example e2e test cases and test configuration it will fail if packages are imported only under devDependencies.
e2e/app.po.ts[1, 38]: Module 'protractor' is not listed as dependency in package.json

Environment

• Angular version: 5.0.4

• For Tooling issues:

• Node version: 8.9.1
• Platform: Mac

bug: "cyclomatic-complexity" is being ignored

Hi,

versions

    "angular-tslint-rules": "^1.12.1",
    "codelyzer": "^4.5.0",
    "ts-node": "~5.0.1",
    "tslint": "^5.12.0",
    "typescript": "^2.9.2" 

I have inside my tslint.json:

    "cyclomatic-complexity": false,

but while running 'npm run lint
im getting

ERROR: /app/shared/table/table/table.component.html:58:11 - The cyclomatic complexity exceeded the defined limit (cost '5'). Your template should be refactored.

Migrate to typescript-eslint

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ x] Feature request
[ ] Documentation issue or request

What is the motivation / use case for changing the behavior?

tslint is deprecated. It would be great if this library was migrated to typescript-eslint

Environment

• Angular version: X.Y.Z

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

Update to codelyzer v6 or have less strict versioning

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior
Currently the following warning is shown when installing.

warning "tslint-config-suiyobi > [email protected]" has incorrect peer dependency "codelyzer@^5.0.0".

Expected/desired behavior
I would expect codelyzer@^6.0.0 to be supported

Minimal reproduction of the problem with instructions
Install the package with codelyzer@^6.0.0 installed in the same project.

What is the motivation / use case for changing the behavior?
To avoid false positive warnings when installing.

Environment

• Angular version: 10.1.0

• For Tooling issues:

• Node version: 12.18.1
• Platform: macOS

• Others:

angular-tslint-rules/package.json

Line 36 in 9c30c2f

"codelyzer": "^5.0.0",

Changelog.md is not up-to-date

Currently changelog.md lastest version is 1.14.0, but 1.20.0 was released. I'd love to see tese listed too to see what changed recently.

Thanks!

contribution: max-line-length

Hi,

imports can be longer than 140 characters, exceeding my set max-line-length.

I have a ignore rule inside my tslint, which maybe you'd like to add to your default tslint.json

    "max-line-length": [true, {
      "limit": 140,
      "ignore-pattern": "^import [^,]+ from"
    }],

Bug: angular-whitespace issue in some *.ts files

Hi,

im using

"angular-tslint-rules": "^1.4.1",
"codelyzer": "^4.4.2",
"tslint": "^5.11.0",

(complete list)

  "devDependencies": {
    "@angular/cli": "1.7.2",
    "@angular/compiler-cli": "^5.0.0",
    "@angular/language-service": "^5.0.0",
    "@types/jasmine": "~2.8.6",
    "@types/jasminewd2": "~2.0.2",
    "@types/node": "~9.4.6",
    "angular-tslint-rules": "^1.4.1",
    "codelyzer": "^4.4.2",
    "cors-anywhere": "^0.4.1",
    "http-proxy": "^1.16.2",
    "jasmine-core": "~3.1.0",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~2.0.0",
    "karma-chrome-launcher": "~2.2.0",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "^1.2.1",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.3.0",
    "ts-node": "~5.0.1",
    "tslint": "^5.11.0",
    "typescript": "~2.7.2"
  }

when i run ng lint I get around 20 the same errors on different files about whitepace interpolation... but these files are controllers.. I think it is a bug.

ERROR: /Users/username/repos/repo/src/app/somemodule/some.component.ts[43, 1]: Missing whitespace in interpolation end; expecting {{ expr }}

my components are as simple as below... but tslint thinks i should have extra }} at the end.. (as if it is a template?)

import { Component, Input, OnInit } from '@angular/core';
import { Activity } from '../../_types/models/activity';

@Component({
  selector: 'card-activity',
  templateUrl: './card-activity.component.html',
  styleUrls: ['./card-activity.component.css']
})
export class CardActivityComponent implements OnInit {

  @Input() activity: Activity;

  constructor() {
    //
  }

  ngOnInit(): void {
    //
  }
} // <-- the problem exists here in some components... I see red line and tslint balloon .. when I auto fix tslint... it adds extra }} ... which is illegal typescript :P

Note: when i add "angular-whitespace" false to my rules... the error is not showing anymore, so I really think it is related to angular-tslint-rules

  "rules": {
    "angular-whitespace": false
}

complete tslint.json

{
  "rulesDirectory": [
    "node_modules/codelyzer"
  ],
  "extends": [
    "angular-tslint-rules"
  ],
  "rules": {
    "array-type": [
      true,
      "array"
    ],
    "comment-format": [
      true,
      "check-space"
    ],
    "curly": true,
    "component-selector": false,
    "directive-selector": [
      true,
      "attribute"
    ],
    "i18n": false,
    "newline-per-chained-call": false,
    "no-angle-bracket-type-assertion": false,
    "no-empty": [true, "allow-empty-catch", "allow-empty-functions"],
    "no-inferrable-types": false,
    "no-implicit-dependencies": [
      true,
      "dev"
    ],
    "no-null-keyword": false,
    "quotemark": [
      true,
      "single",
      "avoid-escape",
      "avoid-template"
    ],
    "trackBy-function": false,
    "newline-before-return": false,
    "variable-name": [
      true,
      "check-format",
      "allow-pascal-case",
      "allow-leading-underscore",
      "ban-keywords"
    ]
  }
}

disable `prefer-method-signature`

I'm submitting a ... (check one with "x")

[x] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

support for codelyzer 4

I'm submitting a ...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior

npm WARN [email protected] requires a peer of codelyzer@^3.1.2 but none is installed. You must install peer dependencies yourself.

Expected/desired behavior
No warning when codelyzer 4.0 is used.

no class member rule fails in standard angular modules

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ x] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior
After running tslint with angular-tslint-rules I do get
This class has no members.

Expected/desired behavior
This Error should not occur as it is a standard angular design to export classes in modules without 'member'

Minimal reproduction of the problem with instructions
Simply run lint with the rules over a new project, normally the app.module.ts looks like

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
  ],
  exports: [],
  providers: [
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

What is the motivation / use case for changing the behavior?
This rules should be disabled or rewritten? Not sure here. Which rule is that?

Environment

• Angular version: 5.0.3

• Browser:

• [x ] Chrome (desktop) version 62
• [ x] Firefox version 57
• [ x] Safari (desktop) version High Sierra

• For Tooling issues:

• Node version: XX
• Platform: Mac High Sierra

• Others:
  angular-cli, IntelliJ

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

always require trailing-commas, documentation mismatch

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior

The description demands the use of trailing commas:

Always prefer trailing commas in array and object literals, destructuring assignments, function typings, named imports/exports and function parameters.

But all trailing commas are disallowed

"trailing-comma": [
  true,
  {
    "multiline": "never",
    "singleline": "never",
    "esSpecCompliant": true
  }
]

Tslint rule: https://palantir.github.io/tslint/rules/trailing-comma/
Similar Eslint rule: https://eslint.org/docs/rules/comma-dangle

Expected/desired behavior

Change rule to always enforce trailing comma. So instead would expect something like this:

"trailing-comma": [
  true,
  {
    "multiline": "always",
    "singleline": "never",
    "esSpecCompliant": true
  }
]

Minimal reproduction of the problem with instructions

Made an array and object to validate that they could not have trailing commas.

What is the motivation / use case for changing the behavior?

Description does not match behavior. And as described for the equivalent Eslint rule, this rule:

improves the clarity of diffs when an item is added or removed from an object or array

So would rather change the behavior to match the description than the other way round.

Environment

• Angular version: 5.0.3

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: 8
• Platform: Windows

• Others:

explain `curly as-needed` rule

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[x] Documentation issue or request

Current behavior
The "curly" rule currently specifies the "as-needed" behavior which goes against most coding standards including Google Javascript guide and Typescript Guidelines. A rationale explaining this behavior would be be useful.

Expected/desired behavior
That the documentation contains an explanation (or a link to an explanation) of why this rule makes sense in the context of angular development.

Minimal reproduction of the problem with instructions

1. Read angular-tslint-rules documentation
2. Google "tslint curly as-needed reason"
3. Go through commit messages in tslint to try to find a reason for the "as-needed" option to exist
4. Give up attempts to understand.

What is the motivation / use case for changing the behavior?
Agreeing with a motivation for a coding style rule is not necessary to apply it, but applying it without understanding the underlying the motivation might result in writing code that only follows the letter but not the spirit of the coding style.

Warning: member-ordering - Direct string option is deprecated

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior

I'm getting warnings for one of the rules in this library

Expected/desired behavior

I should not get any warnings

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

add "extends": ["angular-tslint-rules"] to tslint.json and run linting

Environment

• Angular version: 8.2.14

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: v10.19.0
• Platform: Linux

• Others:

"typescript": "~3.4.5",

Full warning:

Warning: member-ordering - Direct string option is deprecated and does not support accessors.
See also https://palantir.github.io/tslint/rules/member-ordering/
You should replace "public-before-private","static-before-instance","variables-before-functions"
with the following equivalent options and add -accessor categories as appropriate:
[
  {
    "name": "public static field",
    "kinds": [
      "public-static-field",
      "protected-static-field"
    ]
  },
  {
    "name": "private static field",
    "kinds": [
      "private-static-field"
    ]
  },
  {
    "name": "public instance field",
    "kinds": [
      "public-instance-field",
      "protected-instance-field"
    ]
  },
  {
    "name": "private instance field",
    "kinds": [
      "private-instance-field"
    ]
  },
  {
    "name": "public static method",
    "kinds": [
      "public-static-method",
      "protected-static-method",
      "public-static-accessor",
      "protected-static-accessor"
    ]
  },
  {
    "name": "private static method",
    "kinds": [
      "private-static-method",
      "private-static-accessor"
    ]
  },
  {
    "name": "public instance method",
    "kinds": [
      "public-constructor",
      "protected-constructor",
      "public-instance-method",
      "protected-instance-method",
      "public-instance-accessor",
      "protected-instance-accessor"
    ]
  },
  {
    "name": "private instance method",
    "kinds": [
      "private-constructor",
      "private-instance-method",
      "private-instance-accessor"
    ]
  }
]

contribution: max-file-line-count

Hi,

please consider:
https://angular.io/guide/styleguide

Consider limiting files to 400 lines of code.

"max-file-line-count": [true, 400]

Maybe this helps :)