@lego/eslint-config-angular

@lego/eslint-config-angular

This package will setup and config ESLinting rules for your Angular TypeScript files. If you want, and you do, to also lint Angular Templates (HTML) then you also need @lego/eslint-config-angular-template in addition to @lego/eslint-config-angular.

Installation

Install this config package:

$ npm i -D @lego/eslint-config-angular

NOTE: @lego/eslint-config-angular includes @lego/eslint-config-typescript which includes @lego/eslint-config

Usage

Make a tsconfig.eslint.json that targets everything. Else @typescript-eslint will complain if it encounters a file that is not covered by your tsconfig. For example environment.prod.ts.

// tsconfig.eslint.json
{
  "extends": "tsconfig.json" // this is the generated tsconfig from the angular-cli
}

Extend your eslint.json, and make sure @lego/eslint-config-angular has been added, but make sure it's add at the end. Note that the config for this linting config is added via overrides. This is a requirement from @angular-eslint which this is built on top of.

"overrides": [
  {
    "files": ["*.ts"],
    "parserOptions": {
      "project": "tsconfig.eslint.json"
      // "createDefaultProgram": true <-- REMOVE THIS from your config
    },
    "extends": ["@lego/eslint-config-angular"]
  }
]

with Prettier:

"overrides": [
  {
    "files": ["*.ts"],
    "parserOptions": {
      "project": "tsconfig.eslint.json"
      // "createDefaultProgram": true <-- REMOVE THIS from your config
    },
    "extends": [
      "@lego/eslint-config-angular",
      "@lego/eslint-config-prettier" // note prettier MUST come last
    ]
  }
]

NOTE: the above examples will only lint TypeScript files. In order to lint Angular Templates (HTML) check out @lego/eslint-config-angular-template

Overriding Rules

With the above eslint.json configuration example, you can still use or override already defined rules as such:

"overrides": [
  {
    "parserOptions": {
      "project": "tsconfig.eslint.json"
      // "createDefaultProgram": true <-- REMOVE THIS from your config
    },
    "extends": [
      "@lego/eslint-config-angular",
      "@lego/eslint-config-prettier"
    ],
    "rules": {
      // eslint-config rules
      "camelcase": "warn",

      // @typescript-eslint/eslint-plugin rules
      "@typescript-eslint/no-useless-constructor": "error",

      // @angular-eslint rules
      "@angular-eslint/component-class-suffix": [
        "error",
        {
          "suffixes": ["Component", "Page", "Modal", "Drawer"]
        }
      ],

      // eslint-plugin-prettier rules
      "prettier/prettier": [
        "error",
        {
          "singleQuote": false
        }
      ]
    }
  }
]

Working with multi-project workspaces

Are you using the multi-project workspace structure (stuff is in the projects folder) then you can put project specific rules in the related project folder. You still need to make a tsconfig.eslint.json file that targets everything within your project. Put the below file next to your projects/<YOUR_PROJECT_NAME>/tsconfig.lib.prod.json file

// projects/<YOUR_PROJECT_NAME>/tsconfig.eslint.json
{
  "extends": "../../tsconfig.json"
}

Then alter the ESLint config to your heart's content

// projects/<YOUR_PROJECT_NAME>/.eslintrc.json
{
  "extends": "../../.eslintrc",
  "ignorePatterns": ["!**/*"],
  "overrides": [
    {
      "files": ["*.ts"],
      "parserOptions": {
        "project": "projects/<YOUR_PROJECT_NAME>/tsconfig.eslint.json" // <-- replace <YOUR_PROJECT_NAME>
        // "createDefaultProgram": true <-- REMOVE THIS from your config
      },
      "rules": {
        "@angular-eslint/component-selector": [
          "error", { "type": "element", "style": "kebab-case", "prefix": "<YOUR_PROJECT_PREFIX>" }
        ],
        "@angular-eslint/directive-selector": [
          "error", { "type": "attribute", "style": "camelCase", "prefix": "<YOUR_PROJECT_PREFIX>" }
        ],
        "@angular-eslint/pipe-prefix": [
          "error", { "prefixes": ["<YOUR_PROJECT_PREFIX>"] }
        ]
      }
    }
  ]
}

It's recommended to inspect the defined rule's configurations where the reasoning for the configuration lives. If a configuration could benefit more than just the project you're working on, feel free to create a pull request.