Generator EditorConfig

Co robi .editorconfig

Plik o nazwie .editorconfig w katalogu głównym projektu deklaruje konwencje formatowania. Edytory z obsługą EditorConfig (każde większe IDE i większość nowoczesnych edytorów tekstu) stosują te reguły przy otwarciu pliku. Wyszukiwanie wędruje w górę drzewa katalogów od edytowanego pliku i zatrzymuje się na pierwszym pliku, który mówi root = true.

Przykładowy wynik

Przy ustawieniach domyślnych (spacje, rozmiar wcięcia 4, LF, utf-8) i dwóch sekcjach zaznaczonych za ciebie generator zapisuje:

root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
max_line_length = 120

[*.{md,markdown}]
trim_trailing_whitespace = false

[{Makefile,makefile,GNUmakefile,*.mk}]
indent_style = tab

Zaznacz Python, Go albo YAML, a poniżej pojawi się pasująca sekcja, od razu z konwencją, którą wymusza formater tego ekosystemu.

Kluczowe dyrektywy

Trzy reguły, które psują build, a nie tylko przewodnik stylu

Większość wpisów w .editorconfig to preferencje. Te trzy nie są i właśnie dla nich warto mieć sekcje dla poszczególnych języków:

• YAML zabrania tabulatora we wcięciach. To błąd parsowania, a nie ostrzeżenie lintera. Jeśli twój projekt wcina tabulatorami, a masz workflow GitHub Actions, pliki Docker Compose albo manifesty Kubernetes, sekcja YAML musi wymusić z powrotem spacje.
• make wymaga dosłownego tabulatora na początku każdego wiersza z poleceniem w regule. Spacja daje missing separator. Stop. i build staje. Dlatego [{Makefile,makefile,GNUmakefile,*.mk}] wymienia kilka pisowni: EditorConfig dopasowuje nazwy plików z rozróżnianiem wielkości liter, a w repozytoriach są zarówno Makefile, jak i makefile.
• Skrypt powłoki zapisany z CRLF nie uruchamia się. Jądro odczytuje znak powrotu karetki jako część ścieżki interpretera i zgłasza coś w rodzaju /bin/bash^M: bad interpreter: No such file or directory. Pliki wsadowe Windows mają problem odwrotny: cmd.exe szuka goto i call :label po przesunięciu bajtowym, więc plik .bat zapisany z samym LF może skoczyć do złego wiersza albo zatrzymać się w połowie, w ogóle bez błędu.

Dwa z tych problemów blok globalny raczej wywołuje, niż naprawia, i właśnie dlatego ten generator ich pilnuje. Jeśli wybierzesz tabulatory i nie dodasz sekcji YAML albo wybierzesz CRLF i nie dodasz sekcji skryptów powłoki, zapisany plik zepsuje tamte pliki, choć ani razu ich w nim nie widać. Generator mówi o tym nad wynikiem, zamiast pozwolić ci odkryć to dopiero na nieudanym buildzie. Tak samo jest z kodowaniami utf-16: obowiązują w każdym pliku projektu, a make, interpretery powłoki i Python nie potrafią czytać kodu zapisanego w ten sposób.

Konwencje języków, które zapisuje ten generator

Zwróć uwagę, czego w tej tabeli nie ma: długości linii. PEP 8 mówi 79, Black mówi 88, PSR-12 mówi miękkie 120, a rustfmt mówi 100. Wpisanie którejkolwiek z tych liczb do sekcji języka po cichu nadpisałoby limit wybrany dla całego projektu, więc generator zostawia max_line_length wyłącznie w bloku [*], a te liczby trzyma tutaj, gdzie możesz je zastosować świadomie.

Czy twój edytor to obsługuje?

Wsparcie natywne: VS Code, rodzina JetBrains IntelliJ, Visual Studio, Sublime Text, Xcode i Notepad++. Vim, Emacs, Neovim i kilka innych potrzebuje niewielkiej wtyczki. Plik to zwykły INI, więc czytają go też lintery i formatery, i właśnie dzięki temu Prettier oraz część serwerów językowych trzyma się tych samych reguł.