Einrichten von Prettier für unser Projekt

Ziel

In dieser Übung werden wir mit Hilfe von Prettier unserer Frontend Anwendung die Möglichkeit geben den Source Code automatisch zu formatieren und somit einen standardisierten Code Style einzuführen.

Hierzu werden wir folgende Schritte unternehmen:

• Projekt um die notwendigen Fremdkomponenten erweitern
• Konfiguration für Prettier erzeugen
• Das Projekt formatieren damit unserer Projekt dem neuen Code Style folgt

Einführung von Prettier

Wir werden in der Übung auf Prettier setzen.

Prettier ist ein Tool das automatisiert den Source Code formatiert und so für konistenten Code Style sorgt. Prettier selbst bezeichnet sich als “An opinionated code formatter” was bereits implizieren das die Konfigrationsoptionen überschaubar sind. Dies kann in diesem Fall als Vorteil gewertet werden da dadurch häufig potenzielle Style Diskussionen vermieden oder zumindest reduziert werden können.

Tipp

Nimm dir 5 - 10 Minuten Zeit um dich kurz über “Code Style” und über Prettier zu informieren.

Nachdem du nun einen Überblick über Code Style und Prettier hast setzen wir in der Übung fort.

Installation Prettier und ESLint-Plugins

Zu Beginn starten wir wieder indem wir einen neuen Branch anlegen und unsere IDE starten.

In der IDE angekommen öffnen wir die Konsole und fügen das unten angeführte Kommando ein.

Installation von Prettier und der notwendigen ESLint-Plugins

npm install --save-dev prettier eslint-config-prettier eslint-plugin-prettier

Dies installiert Prettier und ein Plugin um Prettier mit ESLint zu integrieren. Zusätzlich wird für die Integration auch noch eine Abhängigkeit installiert die dafür zuständig ist das die gleiche Konfiguration verwendet werden kann.

Konfiguration von Prettier

Nachdem wir Prettier samt Plugins fehlerfrei installieren konnten geht es nun darum die notwendigen Konfigurationen für Prettier zu erstellen.

Zu Beginn erstellen wir nun eine Datei names “.prettierrc” in der Wurzel unseres Repos.

In dieser Datei konfigurieren wir nun unsere Basiseinstellungen.

.prettierrc

{
  "$schema": "https://json.schemastore.org/prettierrc",
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,

  "semi": true,
  "singleQuote": true,
  "jsxSingleQuote": false,

  "trailingComma": "all",
  "bracketSpacing": true,
  "bracketSameLine": false,

  "arrowParens": "always",

  "quoteProps": "as-needed",

  "endOfLine": "lf",

  "embeddedLanguageFormatting": "auto"
}

Zusätzlich legen wir auch eine Datei names “.prettierignore” ebenfalls in der Wurzel des Repos an.

.prettierignore

# Ignore artifacts and build output
dist
build

# Ignore node_modules
node_modules

# Ignore NPM-Package-Lock File
package-lock.json

# Ignore Shadcn/ui components - these are dependencies therefore we do not want these formatted
src/components/ui

Diese Datei sorgt dafür das weder der Output unseres Builds welcher in “dist” abgelegt noch die Abhängigkeiten die wir mittels NPM installieren und im Ordner “node_modules” abgelegt werden von Prettier verändert werden.

Zusätzlich ignorieren wir auch alle Dateien im Verzeichnis “src/components/ui” da diese die Shadcn/ui Komponenten enthalten.

Im nächsten Schritt stellen wir die Verbindung zwischen ESLint und Prettier her. Hierzu nehmen wir die unten angeführte Änderung in der Datei “eslint.config.js” vor.

eslint.config.js

import js from '@eslint/js'
import globals from 'globals'
import reactHooks from 'eslint-plugin-react-hooks'
import reactRefresh from 'eslint-plugin-react-refresh'
import tseslint from 'typescript-eslint'
import prettier from 'eslint-plugin-prettier'
import prettierConfig from 'eslint-config-prettier'

export default tseslint.config(
  { ignores: ['dist', 'src/components/ui'] },
  {
    extends: [js.configs.recommended, ...tseslint.configs.recommended],
    extends: [js.configs.recommended, ...tseslint.configs.recommended, prettierConfig],
    files: ['**/*.{ts,tsx}'],
    languageOptions: {
      ecmaVersion: 2020,
      globals: globals.browser,
    },
    plugins: {
      'react-hooks': reactHooks,
      'react-refresh': reactRefresh,
      prettier: prettier,
    },
    rules: {
      ...reactHooks.configs.recommended.rules,
      'react-refresh/only-export-components': [
        'warn',
        { allowConstantExport: true },
      ],
      'prettier/prettier': 'error',
    },
  },
)

Diese Konfigurationserweiterungen sorgen dafür das Prettier zukünftig als Teil vom ESLint-Prozess läuft, dies geschieht über das Prettier-Plugin.

Die Erweiterung im Block “rules” sorgt dafür das Rückmeldungen von Prettier als Fehler gewertet werden.

Dies verifizieren wir mittels eines Aufrufs von

Aufruf von ESLint inkl. Prettier mittels npm run lint

npm run lint

Wie wir sehen liefert das Script eine lange Ausgabe

Gekürzte Ausgabe von ESLint (npm run lint)

@FHB-Student ➜ /workspaces/Kanban-Frontend-Starter-Test (test/prettier-2026) $ npm run lint

> hb-kanban-frontend@0.0.0 lint
> eslint .


/workspaces/Kanban-Frontend-Starter-Test/src/App.tsx
   3:1   error  Delete `⏎`                                                  prettier/prettier
   5:10  error  Replace `(⏎····<KanbanBoard·/>⏎··)` with `<KanbanBoard·/>`  prettier/prettier
  10:19  error  Insert `;`                                                  prettier/prettier

/workspaces/Kanban-Frontend-Starter-Test/src/components/KanbanBoard.tsx
    3:25  error  Replace `"@/components/ui/sonner"` with `'@/components/ui/sonner'`                                                                                                                                                                                                prettier/prettier
    4:23  error  Replace `"sonner"` with `'sonner'`                                                                                                                                                                                                                                prettier/prettier

Nachdem wir nun Prettier und dessen Anbindung an ESLint konfiguriert haben fehlt nur noch ein NPM-Script für den Prettier-Aufruf.

Hierzu navigieren wir erneut in die Datei “package.json” und erweitern diese um ein neues Script.

package.json

    "lint": "eslint ."
    "lint": "eslint .",
    "lint:fix": "eslint --fix .",
    "format": "prettier --check .",
    "format:fix": "prettier --write ."
  },

Nun müssen wir nur noch unser neues Script ausführen. Dieses können wir mittels

Aufruf unseres Prettier Format Scripts

npm run format

erledigen.

$ npm run format

> hb-kanban-frontend@0.0.0 format
> prettier --check .

Checking formatting...
[warn] .github/workflows/ci.yml
[warn] .prettierrc
[warn] components.json
[warn] eslint.config.js
[warn] openapi.json
[warn] src/App.tsx
[warn] src/components/KanbanBoard.tsx
[warn] src/components/KanbanItem.tsx
[warn] src/components/KanbanItemCard.tsx
[warn] src/components/KanbanItemPriority.tsx
[warn] src/components/KanbanSheet.tsx
[warn] src/data/types.ts
[warn] src/index.css
[warn] src/lib/utils.ts
[warn] src/main.tsx
[warn] tsconfig.app.json
[warn] tsconfig.json
[warn] vite.config.ts
[warn] Code style issues found in 18 files. Run Prettier with --write to fix.

Die Analyse von Prettier ergibt das 18 Dateien dem konfigurierten Code-Style nicht entsprechen und angepasst werden müssen.

Einführung in bestehende Projekte

Wir sehen jetzt auch ein großes Problem bei der Einführung solcher Tools in Bestandsprojekte.

Selbst bei unserem sehr einfachen und kleinem Projekt ist die Liste der Änderung recht lang. Bei einem jahrelang gewachsenen großen Projekt werden die Änderung normalerweise so umfangreich sein das diese nicht so reviewed werden können das Fehler ausgeschlossen werden können.

Deshalb kann es in solchen Fällen sinnvoll sein auf andere Strategien zurückzugreifen oder mit mehr Vorbereitung, vor allem in Richtung Mindset der anderen Mitarbeiter, diese Formatänderungen durchzuführen.

Prettier weißt uns darauf hin das wir die notwendigen Änderungen, wenn wir unsere Code-Style-Regel einhalten wollen, mittels “—write”-Flag festschreiben können, wenn wir das wollen.

Wir haben zuvor bereits ein NPM-Script mit dieser Option angelegt. Da wir in diesem Projekt dem Coding-Style folgen wollen nehmen wir in Kauf das mit diesem Commit eine Vielzahl an Dateien nun neu formatiert werden.

Somit führen wir nun

Aufruf unseres Prettier Format Scripts zur automatischen Bereinigung

npm run format:fix

aus.

Wir sehen das das Script nun unsere Dateien neu formatiert. Auch im Output informiert uns Prettier welche Dateien angepasst wurden.

Ausgabe von "npm run format:fix"

$ npm run format:fix

> hb-kanban-frontend@0.0.0 format:fix
> prettier --write .

.github/workflows/ci.yml 30ms
.prettierrc 22ms
components.json 4ms
eslint.config.js 14ms
index.html 39ms (unchanged)
openapi.json 26ms
package.json 7ms (unchanged)
README.md 41ms (unchanged)
src/App.css 12ms (unchanged)
src/App.tsx 29ms
src/components/KanbanBoard.tsx 80ms
src/components/KanbanItem.tsx 55ms
src/components/KanbanItemCard.tsx 22ms
src/components/KanbanItemPriority.tsx 4ms
src/components/KanbanSheet.tsx 7ms
src/data/types.ts 2ms
src/index.css 52ms
src/lib/utils.ts 2ms
src/main.tsx 2ms
src/vite-env.d.ts 2ms (unchanged)
tsconfig.app.json 2ms
tsconfig.json 1ms
tsconfig.node.json 4ms (unchanged)
vite.config.ts 2ms

Nun versuchen wir eine Änderung rückgängig zu machen und speichern anschließend. Sobald wir nun wieder

Aufruf unseres Prettier Format Scripts

npm run format:fix

ausführen wird der Source Code nun so angepasst das er dem konfigurierten Code Style entspricht. Unterschiedliche Formatierungen gehören nun der Vergangenheit an.

Automatische Ausführung beim Speichern

Nun wäre es doch sinnvoll wenn ESLint bzw. Prettier automatisch bei Veränderungen ausgeführt werden würden.

Um dies zu erreichen gibt es unterschiedliche Möglichkeiten, eine davon werden wir nun implementieren.

Änderungen im Branch commiten

Damit es zu keinem Datenverlust kommt wenn in einem der nächsten Schritte etwas fehlschlägt commiten wir den aktuellen Status und pushen die Änderungen.

Automatische Ausführung beim Speichern in VS Code (GitHub Codespace)

Hierzu erstellen wir einen Ordner names “.devcontainer” im Root des Projektes. Anschließend erstellen wir im neu erstellten Verzeichnis eine Datei mit dem Namen “devcontainer.json”.

Der Inhalt der Datei ist wie folgt:

devcontainer.json

{
  "name": "Node.js & TypeScript",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:latest",
  "customizations": {
    "vscode": {
      "settings": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode",
        "[css]": {
          "editor.defaultFormatter": "esbenp.prettier-vscode"
        },
        "editor.codeActionsOnSave": {
          "source.fixAll.eslint": "explicit"
        }
      },
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  },
  "postCreateCommand": "npm install"
}

Nachdem wir diese Datei angepasst haben ist es nun notwendig müssen wir den Container erneut bauen. Hierzu drücken wir die “F1”-Taste und geben den Text “Codespaces: Rebuild Container” und wählen diese Option aus.

GitHub Codespaces benötigt noch eine Bestätigung von uns. Wir wählen die Option “Rebuild”.

Achtung: Datenverlustgefahr

Die Option “Full Rebuild” löscht die Daten die noch nicht mittels eines commits festgeschrieben wurden.

Optional kann der Codespace auch mittels folgenden Terminal-Befehl

gh codespace rebuild

neu gebaut werden.

Nachdem Rebuild steht unsere Umgebung wieder zur Verfügung, wir können unsere Änderungen nun testen.

Änderungen übernehmen

Abschließend erstellen wir einen Commit mit allen Änderungen, pushen diese und stoppen unseren GitHub Codespace.

Wir sollten nun die laufenden Actions sehen. Nachdem diese erfolgreich durchgelaufen sind können wir den Pull-Request mergen.

Zusammenfassung

In diesem Lab wurden die nachfolgenden Themen erklärt:

• Installation und Konfiguration von Prettier im Zusammenspiel mit ESLint
• Einheitliche Formatierung des Source Codes durch Nutzung eines einheitlichen Code Styles
• Anpassung und erweitern unseres GitHub Codespaces