FR: validate-decorators

[rafaelss95]

Currently we have many rules to disallow/enforce decorator properties values. Here's the list:

List of rules
component-selector
directive-selector
no-host-metadata-property
no-inputs-metadata-property
no-outputs-metadata-property
no-queries-metadata-property
no-pipe-impure
pipe-prefix
prefer-on-push-component-change-detection
relative-url-prefix
use-component-selector
use-component-view-encapsulation
use-injectable-provided-in

Instead of maintaining all these rules, I want bring back the discussion about porting the rule components#validateDecoratorsRule, which provides flexibility to support custom options and even custom decorators.

Note that it was mentioned sometimes in Codelyzer repo:

• Feature request: Enforce value of @Component.changeDetection mgechev/codelyzer#135 (comment)
• add new rule to enforce the use of providedIn flag mgechev/codelyzer#558 (comment)
• [feature request]: Add a new rule validate decorators mgechev/codelyzer#966

An example config could be:

{
  "rules": {
    "validate-decorators": [
      "error", {
        "Component": {
          "argument": 0,
          "properties": {
            "changeDetection": "\\.OnPush$",
            "host": "^[a-z]", // addresses https://github.com/angular-eslint/angular-eslint/issues/161
            "selector": "^apn-",
            "templateUrl": "^\.{1,2}\/[^.\/]",
            "!encapsulation": "\\.None$",
            "!inputs": ".*",
            "!outputs": ".*",
            "!queries": ".*"
          }
        },
        "Directive": {
          "argument": 0,
          "properties": {
            "host": "^[a-z]", // addresses https://github.com/angular-eslint/angular-eslint/issues/161
            "selector": "^apn-",
            "!inputs": ".*",
            "!outputs": ".*",
            "!queries": ".*"
          }
        },
        "Injectable": {
          "argument": 0,
          "properties": {
            "providedIn": {
              "ignoreClassPattern": "(Effects|Guard|Interceptor|Store)$", // addresses https://github.com/angular-eslint/angular-eslint/issues/236 ?
              "match": ".*",
            }
          }
        },
        "Pipe": {
          "argument": 0,
          "properties": {
            "name": "^apn[A-Z][a-zA-Z]+$", // addresses https://github.com/mgechev/codelyzer/issues/519#issuecomment-758099917
            "!pure": ".*"
          }
        },
        "ContentChildren": {
          "argument": 1,
          "required": true,
          "properties": {
            "descendants": "^(true|false)$"
          }
        },
        "MyCustomDecorator": {
          "argument": 0,
          "properties": {
            "myCustomProperty": ".*"
          }
        }
      }
    ]
  }
}

We can discuss about the default config and about how the merge configuration would happen.

[rafaelss95]

WDYT, @JamesHenry?

If it isn't something desired for now, I can work on issues #161 and #236, but I believe that with this proposed rule we can resolve this better and leave the developers with the freedom to configure it as they see fit in their projects.

Also note that we probably will need to a new rule soon (so the list will keep growing 😐), because as described in mgechev/codelyzer#519 (comment), according to the Angular style guide pipe name strings should use lowerCamelCase. Already covered in pipe-prefix.

[snowinmars]

Awaiting for prefer-on-push-component-change-detection rule :3

[JounQin]

Why not all rules from @angular/components?

I extracted them into a single tslint package ng-tslint, and hope they can all be ported into @angular-eslint!

[JounQin]

Awaiting for prefer-on-push-component-change-detection rule :3

It is already available via #7.

[rafaelss95]

Why not all rules from @angular/components?

Hey @JounQin, I see a lot of rules there that are specific to their ecosystem... can you expand a bit more which rules do you find useful to be part of @angular-eslint?

[JounQin]

@rafaelss95 I'd like to use class-list-signatures, coercion-types, lightweight-tokens, ng-on-changes-property-access, no-undecorated-base-class-di, no-undecorated-class-with-angular-features, etc.