ESLint und Prettier vereinen

In Projekten mit mehreren Entwicklern kommt es immer wieder dazu, dass ganz verschiedene Arten des Programmierens aufeinandertreffen. Hierunter leidet oft die Qualität des Codes. Aus diesem Grund kann man in einem Projekt Konfigurationsdateien mit abgestimmten Regeln anlegen, an die sich jeder halten muss, damit eine hohe Code-Qualität sichergestellt ist.

Seitdem wir bei ORDIX unsere Frontend-Anwendungen mit Angular entwickeln, haben wir TSLint verwendet und in jedem Projekt Regeln festgelegt. Da TSLint veraltet ist, haben wir uns dazu entschieden auf ESLint umzusteigen.

TSLint konnte den Code sowohl linten als auch formatieren. Aber worin bestehen eigentlich die Unterschiede von einem Code-Linter zu einem Code-Formatter?

Linter vs. Formatter 

Ein Linter ist dafür verantwortlich, dass der Code keine Fehler und keine widersprüchlichen oder irrelevanten Ausdrücke, wie zum Beispiel if(true) {…} enthält.

Ein Formatter hingegen beschäftigt sich überhaupt nicht mit dem Inhalt des Codes. Er achtet nur auf eine korrekte Syntax. Zum Beispiel sollen in TypeScript einfache Anführungszeichen statt doppelten verwendet werden oder geschweifte Klammern müssen an der richtigen Stelle stehen.

ESLint hat nur sehr wenige Funktionen Code zu formatieren, weswegen wir uns dazu entschieden haben, Prettier als Code-Formatter zusätzlich zu ESLint zu verwenden.

Eine genaue Grenze zu ziehen, was ein Code-Formatter und was ein Code-Linter erledigt, ist ziemlich schwierig. Darum gibt es ein paar Regeln, bei denen es Überschneidungen in den Tools gibt. In der Konfiguration muss besonders aufgepasst werden, damit man keine Widersprüche in den Regeln erzeugt.

Konfigurationsdatei für Prettier 

Wie man die Konfigurationsdateien für Prettier anlegt, findet Ihr hier.

Eine Übersicht über die verfügbaren Regeln kann man ebenso auf der Seite finden.

Bei Prettier sind die meisten Regeln vorgegeben und man kann nur ein paar wenige selbst konfigurieren.

Eine solche Konfigurationsdatei mit dem Dateinamen .prettierrc.json könnte wie folgt aussehen:

{
  "printWidth": 80,
  "tabWidth": 4,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "quoteProps": "as-needed",
  "trailingComma": "none",
  "bracketSpacing": false,
  "bracketSameLine": true,
  "arrowParens": "avoid",
  "htmlWhitespaceSensitivity": "css",
  "endOfLine": "lf",
  "embeddedLanguageFormatting": "auto"
} 

Konfigurationsdatei für ESLint 

Wie man eine Konfigurationsdatei für ESLint anlegt, findet Ihr hier.

Bei der .eslintrc.json ist es wichtig, dass in der Konfigurationsdatei unter „extends“ „plugin:prettier/recommended“ und unter „rules“ „prettier/prettier“ angegeben ist, damit die beiden Tools zusammen funktionieren und Prettier automatisch ausgeführt wird, wenn ESLint ausgeführt wird.

Eine solche .eslintrc.json könnte zum Beispiel so aussehen:

{
  "root": true,
  "overrides": [
    {
      "files": [
        "**/*.ts?(x)"
      ],
      "parserOptions": {
        "project": [
          "tsconfig.json"
        ],
        "createDefaultProgram": true
      },
      "extends": [
        "plugin:prettier/recommended"
      ],
      "rules": {
        "prettier/prettier": "error",
        "array-callback-return": "off",
        "curly": "error",
        "eol-last": "error",
        "no-restricted-imports": [
          "error",
          "rxjs/Rx"
        ],
        "keyword-spacing": "error",
        "max-len": [
          "error",
          140
        ],
        "no-console": "error",
        "no-empty": "off",
        "no-fallthrough": "error",
        "no-var": "error",
        "space-before-function-paren": [
          "error",
          "never"
        ], 
        "camelcase": [
          "error",
          {
            "properties": "always"
          }
        ],
        "no-irregular-whitespace": "error",
        "no-whitespace-before-property": "error",
        "no-eval": "error",
        "no-caller": "error",
        "no-new": "error",
        "no-bitwise": "error",
        "no-new-wrappers": "error",
        "no-debugger": "error",
        "no-duplicate-imports": "error",
        "constructor-super": "error",
        "no-throw-literal": "error",
        "dot-notation": "error",
        "no-trailing-spaces": "error",
        "no-undef-init": "error",
        "no-unused-expressions": "error",
        "no-unused-vars": [ "error", { "argsIgnorePattern": "^_" } ],
        "prefer-const": "error",
        "radix": "error",
        "no-lonely-if": "error",
        "no-unreachable": "error",
        "default-case": "error",
        "comma-spacing": ["error", { "before": false, "after": true }],
        "no-multi-spaces": "error",
        "eqeqeq": [
          "error",
          "smart"
        ],
        "no-multiple-empty-lines": [
          "error",
          {
            "max": 1,
            "maxEOF": 1
          }
        ]
      }
    }
  ]
}
 

Packages in der „package.json" 

In der package.json müssen einige Angaben gemacht werden, damit unsere Konfiguration einwandfrei funktioniert.

Eine package.json könnte für TypeScript-Dateien folgendermaßen aussehen:

{
  "babel": {
    "presets": [
      "@babel/typescript"
    ]
  },
  "dependencies": {
    "@babel/eslint-parser": "^7.18.2",
    "@babel/preset-typescript": "^7.16.7",
    "@babel/core": "^7.18.2",
    "@typescript-eslint/parser": "^5.22.0",
    "@typescript-eslint/eslint-plugin": "^5.22.0",
    "eslint": "^7.26.0",
    "eslint-config-prettier": "^8.5.0",
    "eslint-plugin-prettier": "^4.0.0",
    "prettier": "^2.6.0",
    "typescript": "^4.6.4"
  }
}
 

Skripte 

Um den eigenen Code nach den festgelegten Regeln zu überprüfen, muss man lediglich folgenden Befehl absetzen:

eslint --ext [Dateiformate] [Ordner]

Beispiel:

eslint --ext ts src

Dieser Befehl zeigt jedoch nur die Fehler an, die gemacht wurden. Wenn ihr den Befehl "--fix" hinzufügt, versucht ESLint so viele Fehler wie möglich automatisch zu korrigieren:

eslint --fix -- ext [Dateiformate] [Ordner]

Falls ESLint nicht alle Probleme selbstständig beheben konnte, werden die verbleibenden Fehler in der Konsole aufgelistet.

Die IDE bestmöglich anpassen 

Jede IDE hat die Möglichkeit, Code zu formatieren. Die Regeln, die die IDE standardmäßig verwendet, sind natürlich andere als die, die in den Konfigurationsdateien manuell angelegt wurden. Deshalb wollen wir die selbst definierten Regeln jetzt auch in der IDE verwenden.

Unter IntelliJ kann man in ESLint unter Languages & Frameworks ➔ JavaScript ➔
Code Quality Tools auf den Haken bei „Automatic ESLint configuration“ klicken und schon wird automatisch die .eslintrc verwendet. Für Prettier muss zusätzlich das gleichnamige Plugin installiert werden. In den Einstellungen findet man nach der Installation auf gleicher Höhe wie Code Quality Tools die Einstellungen für Prettier. Hier muss als Prettier package der Pfad zu Prettier aus dem node_modules-Ordner angegeben werden. Wenn man jetzt noch den Haken bei On 'Reformat Code' action setzt, formatiert IntelliJ automatisch nach den Regeln von Prettier.

Unter VSCode müssen das „ESLint“-Plugin sowie das „Prettier - Code formatter“-Plugin installiert werden. Nun muss man in eine beliebige .ts- oder .js-Datei aus dem Projekt wechseln und mit
STRG + SHIFT + P nach „Dokument formatieren mit ... (Format Document ...)“ suchen und Prettier auswählen.

Fazit 

In diesem Artikel haben wir gelernt, wie man ESLint und Prettier gemeinsam einsetzen und so die Qualität des Codes enorm verbessern kann. Des Weiteren ist es für die Entwickler wesentlich einfacher den Code zu lesen und zu verstehen, wenn sich überall an die gleiche Syntax gehalten wurde.

In meinem nächsten Artikel möchte ich Euch dann zeigen, wie man diese Konfigurationsdateien zentralisieren und in mehrere Projekte einbinden kann. 

Seminarempfehlungen