Co robi .editorconfig
Trzech inżynierów w jednym repo, trzy różne edytory: VS Code na Windowsie, który dorzuca CRLF, vim na Linuksie z tabami po 4 spacje, JetBrains na macOS z osobistym overridem szerokości taba. Trzy tygodnie później diff jest pełen niewidocznych zmian białych znaków, każdy PR ma szum, blame staje się bezużyteczny.
Plik `.editorconfig` to prosty fix. To jednorazowa konfiguracja w korzeniu repo, którą każdy nowoczesny edytor czyta automatycznie (VS Code, JetBrains, vim, emacs, Sublime, Atom): jaki styl wcięć, ile spacji, jakie zakończenie linii, jaki charset, czy trimować trailing whitespace, czy dodawać końcowy newline. Bez instalacji wtyczki w popularnych edytorach, bez konfigu per developer.
Ten generator pisze ten plik za Ciebie. Wybierz preset dla swojego stacka (JavaScript / TypeScript, Python, Go, Polyglot, Windows-friendly, Strict Linux), pokombinuj z domyślnymi wartościami, dodaj per-pattern overrides dla plików potrzebujących innych reguł (`Makefile` zawsze chce tabów, `*.md` powinien zachowywać trailing whitespace, bo tak są kodowane łamania linii), skopiuj albo pobierz jako `.editorconfig`, commituj. Gotowe w dwie minuty.
Jak używać
- Wybierz preset u góry: JavaScript / TypeScript, Python, Go, Polyglot, Windows-friendly, Strict Linux. Każdy preset wypełnia sensowne wartości, które potem zmienisz.
- Zostaw root = true włączone. Mówi edytorom „przestań szukać wyżej w drzewie katalogów". Bez tego `.editorconfig` wyżej w hierarchii (np. w katalogu domowym) może nadpisać Twój.
- Edytuj **domyślną sekcję [*]: charset, end_of_line, insert_final_newline, trim_trailing_whitespace, indent_style, indent_size, max_line_length**.
- Dodaj per-pattern overrides dla plików potrzebujących innych reguł. `Makefile` musi używać prawdziwych tabów (Make odmawia tabów zamienionych na spacje). **`*.md` powinien zachowywać trailing whitespace (markdown koduje łamanie linii jako dwie spacje na końcu). `*.go`** zwykle używa tabów szerokości 4.
- Dla repo Windows-only ze skryptami powłoki, możesz mieszać zakończenia: **`*.{ps1,bat,cmd}` = crlf, `*.sh` = lf**. Niedopasowane zakończenia w plikach `.sh` łamią uruchomienie na Linuksie.
- Wyczyść pole klikając „keep" w segmentowanym pasku. Klucz zostanie pominięty w output dla tej sekcji, więc wygra wartość z sekcji rodzica (albo domyślna edytora).
- Kliknij Kopiuj albo Pobierz, żeby zapisać jako `.editorconfig`. Potem zacommituj do korzenia repo. Każde IDE wyłapie przy następnym otwarciu, bez instalacji w popularnych edytorach.
Kiedy się przydaje
Sześć konkretnych sytuacji, w których dodanie .editorconfig oszczędza zespołowi realny czas:
- Pierwszy commit w nowym repo. Wybierasz odpowiedni preset dla stacka, wrzucasz `.editorconfig` do korzenia, commitujesz. Każdy edytor otwierający to repo od teraz używa tych samych wcięć i zakończeń linii bez konfiguracji per dev.
- Zespół z mieszanym OS (Windows + macOS + Linux). Numer jeden źródła „dziwnych" diffów to zakończenia linii. Ustawienie `end_of_line = lf` raz zabija całą kategorię, niezależnie od magii autocrlf w gicie.
- Onboarding nowego developera. Klonuje repo, otwiera w swoim edytorze, wcięcia po prostu działają. Bez „a czemu IDE wcina mi tu po 4 spacje?".
- Open-source z zewnętrznymi PR-ami. Zewnętrzni kontrybutorzy używają różnych edytorów. Bez `.editorconfig` połowa PR-ów wymaga „fix whitespace" follow-upu. Z nim diff PR-a to faktyczna zmiana.',
- Repo wielojęzyczne. Python chce 4 spacje, JS chce 2, Go chce tabów po 4, YAML chce 2 spacje, Makefile chce dosłownych tabów. Jeden `.editorconfig` z kilkoma per-pattern blokami obsługuje wszystkie w dwudziestu liniach.
- Pre-commit hook dla whitespace. W połączeniu z pre-commit hookiem (framework `pre-commit` ma integrację z `editorconfig-checker`), reguły stają się wymuszane, a nie tylko sugerowane.