Usage

• Add eslint-config-ct-prodeng to your project's (dev-)dependencies.
• Create a .eslintrc file at the root of your project or close to your JS code depending on your project settings.
• Add the following content to your newly created .eslintrc file:

  {
  	"extends": "eslint-config-ct-prodeng"
  }

• You can easily overwrite and extend this set of rules by adding your own rules in your project's .eslintrc file:

  {
    "extends": "...",
    "rules": {
      ...
    }
  }

Usage in IntelliJ

If you want to enable the linting rules for the .vue files in IntelliJ, you'll also have to add the vue plugin to your .eslintrc file:

  {
  	"extends": "eslint-config-ct-prodeng",
  	"plugins": [
  	  "vue"
  	]
  }

About Typescript-Linting

Enforced Rules

• "@typescript-eslint/ban-ts-ignore": "warn"
  (this is a long term goal as we will probably have to use // @ts-ignore in the beginning)

• "@typescript-eslint/camelcase": "warn" (no error because it is not enforced in Javascript yet [the default is: "@typescript-eslint/camelcase": ["error", { "properties": "always" }]])

• "@typescript-eslint/indent": ["warn", 4, {"SwitchCase": 1}]
  (could be a long term goal if the indent rule from ESLint may not work correctly but could also be fixed in the future for TS files)

• "@typescript-eslint/member-naming": ["warn", { "private": "^_"}]
  (optionally as we already name private methods with the prefix _*)

• "@typescript-eslint/member-ordering": "error"
  (default order is: field, constructor, method)

• "@typescript-eslint/no-for-in-array": "error"

• "@typescript-eslint/no-require-imports": "warn"
  (this is a long term goal, because require-imports still appear in some projects and the d.ts-autocompletion [by esri] also uses them)

• "@typescript-eslint/no-unnecessary-type-assertion": "warn"

• "@typescript-eslint/no-useless-constructor": "error"

• ~~"@typescript-eslint/prefer-interface": "error"~~
  ~~(This rule is deprecated. In the future we might have to use the following "@typescript-eslint/consistent-type-definitions": ["error", "interface"]. It is not clear to me when the update will happen, maybe in version 2.0.0)~~

• "@typescript-eslint/consistent-type-definitions": ["error", "interface"] (this is a replacement for the "prefer-interface" rule. However this is not part of the recommended rules anymore, so should be discussed in the future.)

• "@typescript-eslint/restrict-plus-operands": "error"

Suggested Rules

So far we are using the recommended rule set but in the future we could look into adjusting the rules to our needs. Here are some recommended rules:

• "@typescript-eslint/adjacent-overload-signatures": "warn"

• "@typescript-eslint/ban-types": "error"
  (the types we want to use need to be defined, e.g. string instead of String ["String": "Use string instead"]to use a common type pattern)

• "@typescript-eslint/class-name-casing": "error"

• "@typescript-eslint/explicit-function-return-type": "warn"

• "@typescript-eslint/explicit-member-accessibility": "error"

• "@typescript-eslint/interface-name-prefix": "never"
  (needs a decision on how we want to name interfaces but should then be enforced)

• "@typescript-eslint/member-delimiter-style": "error"
  (The default requires semicolons)

• "@typescript-eslint/no-array-constructor": "error"

• "@typescript-eslint/no-empty-interface": "warn"

• "@typescript-eslint/no-explicit-any": "warn"
  (another long term goal, however, we can already show warnings for explicit any usages and as soon as we have all the type definitions ready we can throw errors then)

• "@typescript-eslint/no-misused-new": "warn"

• "@typescript-eslint/no-namespace": "error"

• "@typescript-eslint/no-non-null-assertion": "error"

• "@typescript-eslint/no-parameter-properties": "error"

• "@typescript-eslint/no-unused-vars": "error"
  (we already have this rule for our JS files)

• "@typescript-eslint/no-use-before-define": "error"

• "@typescript-eslint/type-annotation-spacing": "error"

see

all supported typescript rules

About vue-a11y-linting

An eslint plugin helping to support a11y in custom developed vue components. It will check for required ARIA attributes, roles and alternate keyboard events when defining @mouse... events. Currently, we are using the recommended set of rules. Documentation for the rules with passing and failing examples can be found in the docs.