Was .editorconfig macht
Drei Engineers auf demselben Repo, drei verschiedene Editoren: VS Code auf Windows, das CRLF ergänzt, vim auf Linux mit Tabs zu 4 Spaces, JetBrains auf macOS mit einem persönlichen Tab-Width-Override. Drei Wochen später ist das Diff voller unsichtbarer Whitespace-Änderungen, jeder PR ist Rauschen, Blame ist nutzlos.
Eine `.editorconfig` ist der einfache Fix. One-Shot-Config im Repo-Root, die jeder moderne Editor automatisch liest (VS Code, JetBrains, vim, emacs, Sublime, Atom): welcher Indent-Style, wie viele Spaces, welche Line-Endings, welcher Charset, ob Trailing-Whitespace getrimmt wird, ob ein finaler Newline ergänzt wird. Kein Plugin für die populären Editoren, keine Config pro Entwickler.
Dieser Generator schreibt die Datei für dich. Preset für deinen Stack wählen (JavaScript / TypeScript, Python, Go, Polyglot, Windows-friendly, Strict Linux), Defaults anpassen, Per-Pattern-Overrides für Files mit anderen Regeln ergänzen (`Makefile` will immer Tabs, `*.md` will Trailing-Whitespace behalten, weil so Line-Breaks kodiert sind), kopieren oder als `.editorconfig` runterladen, commiten. In zwei Minuten erledigt.
So nutzt du das Tool
- Oben Preset wählen: JavaScript / TypeScript, Python, Go, Polyglot, Windows-friendly, Strict Linux. Jedes Preset füllt sinnvolle Defaults, die du ändern kannst.
- root = true anlassen. Sagt den Editoren "hör auf, den Verzeichnisbaum hochzuwandern". Ohne das kann eine `.editorconfig` weiter oben (z. B. in deinem Home) deine überschreiben.
- **Default-Section [*] editieren: welche charset, end_of_line, insert_final_newline, trim_trailing_whitespace, indent_style, indent_size, max_line_length**.
- Per-Pattern-Overrides für Files mit anderen Regeln ergänzen. `Makefile` muss echte Tabs nutzen (Make weigert sich, Tabs als Spaces zu lesen). **`*.md` sollte Trailing-Whitespace behalten (Markdown kodiert Line-Breaks als zwei nachgestellte Spaces). `*.go`** nutzt typisch Tabs mit Breite 4.
- Für Windows-only-Repos mit Shell-Skripten kannst du Endings mischen: **`*.{ps1,bat,cmd}` = crlf, `*.sh` = lf**. Falsche Endings auf `.sh`-Files brechen die Ausführung unter Linux.
- Ein Feld leeren mit "keep" in der segmentierten Leiste. Der Key wird für diese Section weggelassen, der Wert aus einer Parent-Section (oder dem Editor-Default) gewinnt.
- Copy oder Download klicken, als `.editorconfig` speichern, in den Repo-Root commiten. Jede IDE liest sie beim nächsten Öffnen, keine Installation für die Populären nötig.
Wann das nützlich ist
Sechs konkrete Situationen, in denen eine .editorconfig deinem Team echt Zeit spart:
- Erster Commit in einem neuen Repo. Passendes Preset für den Stack, `.editorconfig` in den Root, commiten. Jeder Editor, der dieses Repo ab jetzt öffnet, nutzt dieselbe Indentierung und Line-Endings ohne dass jemand was konfigurieren muss.
- Gemischtes OS-Team (Windows + macOS + Linux). Die mit Abstand häufigste Quelle von "Phantom-Diff"-PRs sind Line-Endings. Einmal `end_of_line = lf` setzen killt die ganze Kategorie, unabhängig von git's autocrlf-Zauberei.
- Neuen Entwickler onboarden. Sie klonen das Repo, öffnen es im Editor ihrer Wahl, Indentierung passt einfach. Keine "wait, warum indentiert meine IDE hier mit 4 Spaces?"-Überraschungen.
- Open-Source-Projekt mit externen PRs. Externe Contributors nutzen zufällige Editoren. Ohne `.editorconfig` braucht die Hälfte der PRs ein "fix whitespace"-Followup. Mit ist das PR-Diff nur die echte Änderung.
- Repo mit mehreren Sprachen. Python will 4 Spaces, JS will 2, Go will Tabs mit 4, YAML will 2 Spaces, Makefiles wollen Literal-Tabs. Eine `.editorconfig` mit ein paar Per-Pattern-Blöcken deckt sie alle in zwanzig Zeilen.
- Pre-Commit-Hook für Whitespace. In Kombination mit einem Pre-Commit-Hook (das `pre-commit`-Framework hat eine `editorconfig-checker`-Integration) werden die Regeln durchsetzbar statt nur empfohlen.