Linter: Kleine Helfer, große Wirkung – so bringst du Qualität in den Code (und in deine Übersetzungen)
16. Okt 2025
Wer Software baut, kennt das: Deadlines drücken, Features wachsen, und irgendwann schleicht sich Kleinzeug ein – unnötige Konsolen-Logs, unsichere Pattern, vergessene Importe, Tippfehler in Übersetzungen. Genau hier helfen Linter: automatisierte Werkzeuge, die Code und Ressourcen nach definierten Regeln prüfen und dich früh auf Probleme stoßen lassen.
Was ist ein Linter?
Ein Linter analysiert Quelltext (und teils auch Konfigurationen/Assets) statisch, also ohne das Programm auszuführen. Er meldet:
- Fehler (z. B. unsichere Zugriffe, fehlende Variablen),
- Warnungen (z. B. ungenutzte Variablen),
- Stil-Abweichungen (z. B. Import-Reihenfolgen).
Für JavaScript/TypeScript-Projekte ist ESLint de facto Standard. Mit Plugins wird daraus ein Baukasten für Frameworks (React), Tests (Cypress), Sortierung von Imports und mehr.
Nutzen in drei Sätzen:
Linter verhindern Bugs, halten das Projektteam auf gemeinsame Regeln eingeschworen und sparen Review-Zeit. Für Product Owner bedeutet das weniger Regressions, kürzere Feedback-Zyklen und planbarere Releases. Für Entwickler:innen heißt es früheres Feedback direkt im Editor, im Commit oder in der CI.
„Qualität per Knopfdruck“: Integration in den Workflow
Der größte Hebel entsteht, wenn Linting automatisch läuft – und zwar an den entscheidenden Stellen:
1. Im Editor
Nahezu jede IDE kann ESLint live anzeigen. Fehler tauchen auf, bevor du commitest.
2. Pre-commit (Git Hook):
Commits werden nur akzeptiert, wenn der Linter sauber durchläuft. Beispiel mit Husky & lint-staged:
2. Pre-commit (Git Hook)
Commits werden nur akzeptiert, wenn der Linter sauber durchläuft. Beispiel mit Husky & lint-staged:
# .husky/pre-commit
npx lint-staged
// package.json (Ausschnitt)
{
"scripts": {
"lint": "eslint ."
},
"lint-staged": {
"*.{ts,tsx,js,jsx}": "eslint --fix"
}
}
3. CI/CD (Build breaker)
In GitHub Actions (oder GitLab CI, Azure DevOps, …) lässt du den Linter als eigenen Job laufen. Schlägt er fehl, schlägt der Build fehl – und damit kein Merge/Deploy.
# .github/workflows/ci.yml (Ausschnitt)
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npm ci
- run: npm run lint
Resultat: Qualität „skaliert“ – ohne Heldentaten im Review. Commits und Builds sind Gatekeeper für Standards.
Ein Blick in eine praxisnahe ESLint-Konfiguration
In meinen Frontend-Projekten kombiniere ich typischerweise:
- TypeScript-Regeln (inkl. type-aware Checks),
- React Hooks-Regeln,
- Import-Sortierung,
- Prettier-Kompatibilität (Formatierung bleibt außen vor),
- Cypress-Regeln für Tests,
- und eigene i18n-Checks für Übersetzungen.
Übersetzungen zuverlässig prüfen (i18n)
Neben Codequalität ist für Frontends die Qualität der Übersetzungen kritisch: Fehlende Keys, Tippfehler in Platzhaltern ({name} vs. {username}), oder unvollständige Sprachdateien führen schnell zu Runtimern oder leeren Texten. Ich nutze dafür ein ESlint-Plugin wie zum Beispiel eslint-plugin-i18n-keys.
So gehe ich vor:
- ESLint bekommt ein i18n-Plugin, das die Sprachdateien (z. B. en.json, de.json) einliest.
- Die Regel i18n-keys/key-exists prüft, ob alle verwendeten Keys in den Translation-Dateien existieren. Ist ein Key nicht vorhanden, gibt’s einen Error – Commit/Build blockiert.
// eslint.config.js (Ausschnitte)
import i18nKeys from './tools/eslint-plugin-i18n-keys.js'
...
export default tseslint.config(
...
plugins: {
'i18n-keys': i18nKeys,
},
...
rules: {
'i18n-keys/key-exists': 'error',
...
}
....
}
// usage.tsx
t('profile.welcome', { name: user.name })
// de.json
{
"profile": {
"welcome": "Willkommen, {name}!"
}
}
Fehlerfälle, die der Linter findet:
- t('profile.welcom') → Tippfehler im Key (existiert nicht) → Error
- t('profile.welcome', { username: user.name }) → Platzhalter {name} fehlt/inkonsistent → Error (je nach Regelkonfiguration)
Das Schöne: Diese Checks laufen wie jeder andere Lint-Schritt auch im Editor, im Pre-commit und in der CI. Du fängst i18n-Fehler vor dem Merge ab — nicht im Bugreport einer anderen Sprache. In der oben erwähnten Projekt-Config ist genau so ein i18n-Check enthalten.
TL;DR / Entscheidungshilfe für POs
- Risiko runter: Linter fangen ganze Klassen von Fehlern ab – bevor sie Nutzer:innen treffen.
- Tempo hoch: Weniger Reviewer-Zeit für Stilfragen, mehr für echtes Design/Architektur.
- Vorhersehbare Qualität: Commits und Builds werden zu Qualitäts-Gates.
- Bessere Lokalisierung: i18n-Linting bewahrt vor leeren Keys und kaputten Platzhaltern.
Fazit
Linter sind der einfachste Hebel für messbar bessere Code- und Übersetzungsqualität. Mit wenigen Zeilen Konfiguration machst du sie zu Gatekeepern für Commits und Builds – und ersparst dir Flakes, i18n-Fehler und endlose Stil-Diskussionen. Die gezeigte Projekt-Konfiguration ist ein erprobter, pragmatischer Startpunkt – inklusive i18n-Checks, TypeScript-Schärfe und testfreundlichen Ausnahmen.
