Rule: comment-format

Enforces formatting rules for single-line comments.

Rationale

Helps maintain a consistent, readable style in your codebase.

Notes

• Has Fix

Config

Four arguments may be optionally provided:

• "check-space" requires that all single-line comments must begin with a space, as in // comment
  • note that for comments starting with multiple slashes, e.g. ///, leading slashes are ignored
  • TypeScript reference comments are ignored completely
• "check-lowercase" requires that the first non-whitespace character of a comment must be lowercase, if applicable.
• "check-uppercase" requires that the first non-whitespace character of a comment must be uppercase, if applicable.
• "allow-trailing-lowercase" allows that only the first comment of a series of comments needs to be uppercase.
  • requires "check-uppercase"
  • comments must start at the same position

Exceptions to "check-lowercase" or "check-uppercase" can be managed with object that may be passed as last argument.

One of two options can be provided in this object:

• "ignore-words" - array of strings - words that will be ignored at the beginning of the comment.
• "ignore-pattern" - string - RegExp pattern that will be ignored at the beginning of the comment.

Examples

"comment-format": true,check-space,check-uppercase,allow-trailing-lowercase

"comment-format": true,check-lowercase,[object Object]

"comment-format": true,check-lowercase,[object Object]

Schema

{
  "type": "array",
  "items": {
    "anyOf": [
      {
        "type": "string",
        "enum": [
          "check-space",
          "check-lowercase",
          "check-uppercase",
          "allow-trailing-lowercase"
        ]
      },
      {
        "type": "object",
        "properties": {
          "ignore-words": {
            "type": "array",
            "items": {
              "type": "string"
            }
          },
          "ignore-pattern": {
            "type": "string"
          }
        },
        "minProperties": 1,
        "maxProperties": 1
      }
    ]
  },
  "minLength": 1,
  "maxLength": 5
}

For more information see this page.

Rule: no-inferrable-types

Disallows explicit type declarations for variables or parameters initialized to a number, string, or boolean.

Rationale

Explicit types where they can be easily inferred by the compiler make code more verbose.

Notes

• TypeScript Only
• Has Fix

Config

Two arguments may be optionally provided:

• ignore-params allows specifying an inferrable type annotation for function params. This can be useful when combining with the typedef rule.
• ignore-properties allows specifying an inferrable type annotation for class properties.

Examples

"no-inferrable-types": true

"no-inferrable-types": true,ignore-params

"no-inferrable-types": true,ignore-params,ignore-properties

Schema

{
  "type": "array",
  "items": {
    "type": "string",
    "enum": [
      "ignore-params",
      "ignore-properties"
    ]
  },
  "minLength": 0,
  "maxLength": 2
}

For more information see this page.

Rule: no-inferrable-types

Disallows explicit type declarations for variables or parameters initialized to a number, string, or boolean.

Rationale

Explicit types where they can be easily inferred by the compiler make code more verbose.

Notes

• TypeScript Only
• Has Fix

Config

Two arguments may be optionally provided:

• ignore-params allows specifying an inferrable type annotation for function params. This can be useful when combining with the typedef rule.
• ignore-properties allows specifying an inferrable type annotation for class properties.

Examples

"no-inferrable-types": true

"no-inferrable-types": true,ignore-params

"no-inferrable-types": true,ignore-params,ignore-properties

Schema

{
  "type": "array",
  "items": {
    "type": "string",
    "enum": [
      "ignore-params",
      "ignore-properties"
    ]
  },
  "minLength": 0,
  "maxLength": 2
}

For more information see this page.

Rule: component-selector

Component selectors should follow given naming rules.

See more at https://angular.io/guide/styleguide#style-02-07, https://angular.io/guide/styleguide#style-05-02 and https://angular.io/guide/styleguide#style-05-03.

Rationale

• Consistent conventions make it easy to quickly identify and reference assets of different types.
• Makes it easier to promote and share the component in other apps.
• Components are easy to identify in the DOM.
• Keeps the element names consistent with the specification for Custom Elements.
• Components have templates containing HTML and optional Angular template syntax.
• They display content. Developers place components on the page as they would native HTML elements and WebComponents.
• It is easier to recognize that a symbol is a component by looking at the template's HTML.

Notes

• TypeScript Only

Config

Options accept three obligatory items as an array: 1. element or attribute forces components to be used as either elements, attributes, or both (not recommended) 2. A single prefix (string) or array of prefixes (strings) which have to be used in component selectors. 3. kebab-case or camelCase allows you to pick a case.

Examples

"component-selector": true,element,my-prefix,kebab-case

"component-selector": true,element,ng,ngx,kebab-case

"component-selector": true,attribute,myPrefix,camelCase

"component-selector": true,element,attribute,myPrefix,camelCase

Schema

{
  "items": [
    {
      "enum": [
        "attribute",
        "element"
      ]
    },
    {
      "oneOf": [
        {
          "items": {
            "type": "string"
          },
          "type": "array"
        },
        {
          "type": "string"
        }
      ]
    },
    {
      "enum": [
        "camelCase",
        "kebab-case"
      ]
    }
  ],
  "maxLength": 3,
  "minLength": 3,
  "type": "array"
}

For more information see this page.