1.2.5 • Public • Published


    • 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": [

    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"


    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.


    npm i eslint-config-ct-prodeng

    DownloadsWeekly Downloads






    Unpacked Size

    13.1 kB

    Total Files


    Last publish


    • a.frank
    • jessebluemr
    • schneiderlars
    • julkuh
    • m-scherpi
    • mbeckem_conterra
    • conterrade
    • mrun