Generator .editorconfig

Generator .editorconfig — jedne reguły wcięć dla całego zespołu

Generator .editorconfig składa gotowy plik konfiguracyjny z siedmiu decyzji: spacje czy tabulatory, szerokość wcięcia, kodowanie, znak końca linii, pusty wiersz na końcu pliku, obcinanie białych znaków i wyjątek dla Markdown. Wynik kopiujesz do katalogu głównego repozytorium i od tej pory edytory całego zespołu formatują kod tak samo, niezależnie od prywatnych ustawień.

Czym jest .editorconfig i dlaczego działa

.editorconfig to plik tekstowy w formacie INI, który opisuje reguły formatowania per wzorzec nazwy pliku. Nie jest narzędziem uruchamianym w terminalu ani zależnością projektu — to konfiguracja, którą czyta sam edytor. Ponieważ plik jest wersjonowany razem z kodem, nowa osoba w projekcie dostaje właściwe wcięcia po pierwszym git clone. Ważny jest wpis root = true na początku: bez niego edytor szuka dalej w katalogach nadrzędnych i może dociągnąć reguły z innego projektu. Generator zawsze dopisuje ten wiersz.

Które reguły ustawia generator

Jak zbudować plik krok po kroku

1. Wybierz kafelek Spacje albo Tabulatory. Przy tabulatorach generator zapisuje tab_width, bo szerokość tabulatora to kwestia wyświetlania, a nie liczby znaków.
2. Podaj rozmiar wcięcia z zakresu od 1 do 12. Wartość poza zakresem zatrzymuje generowanie i pokazuje komunikat, zamiast po cichu podstawić coś innego.
3. Ustaw kodowanie i znak końca linii. Domyślne utf-8 i lf to bezpieczny wybór dla projektów budowanych na Linuksie.
4. Zdecyduj o pustym wierszu na końcu pliku i o obcinaniu białych znaków. Oba przełączniki zapisują wprost true lub false.
5. Kliknij Generuj .editorconfig, skopiuj wynik i zapisz jako .editorconfig w katalogu głównym repozytorium.

Na starcie repozytorium warto dołożyć obok niego listę ignorowanych ścieżek z generatora .gitignore, a przy projektach na Apache konfigurację z generatora pliku .htaccess.

Węższe wcięcia dla plików frontendowych

Gdy wybierzesz spacje i rozmiar większy niż dwa, generator dopisuje sekcję dla plików js, jsx, ts, tsx, css, scss, json, yml, yaml i html z wcięciem dwóch spacji. Taka konwencja obowiązuje w ekosystemie JavaScriptu i w plikach danych o głębokich zagnieżdżeniach. Przy wcięciu jednej lub dwóch spacji sekcja nie powstaje, bo byłaby kopią reguły globalnej.

Pliki .php, .py, .go i .rs świadomie nie trafiają do tej listy: PSR-12, PEP 8 i rustfmt wymagają czterech spacji, a gofmt tabulatorów. Dziedziczą regułę z sekcji [*]. Jeden wyjątek generator narzuca zawsze: przy globalnych tabulatorach dla .yml i .yaml powstaje osobna sekcja ze spacjami, bo specyfikacja YAML zabrania tabulatorów jako wcięcia. Plik z tabulacjami nie sparsuje się — sprawdzisz to walidatorem YAML.

Koniec linii, Git i fałszywe zmiany w diffach

Windows kończy wiersz parą CR i LF, systemy uniksowe pojedynczym LF. Bez wspólnej reguły Git pokazuje cały plik jako zmieniony, choć nikt nie tknął logiki. Ustawienie end_of_line = lf rozwiązuje problem po stronie edytora, a uzupełnia je plik .gitattributes z wpisem * text=auto eol=lf, który normalizuje zawartość już w repozytorium. Jeżeli diff nadal wygląda podejrzanie, sprawdź go narzędziem do porównywania różnic w kodzie, a wcięcia w HTML lub CSS uporządkuj upiększaczem kodu JS, CSS i HTML.

Dlaczego Markdown wymaga wyjątku

W Markdownie dwie spacje na końcu wiersza oznaczają wymuszone złamanie linii. Edytor z włączonym trim_trailing_whitespace usuwa je przy każdym zapisie i cicho psuje formatowanie dokumentacji. Dlatego generator dopisuje sekcję wyłączającą tę regułę dla plików .md i .markdown:

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

Sekcja pojawia się tylko wtedy, gdy globalnie obcinasz białe znaki — inaczej byłaby wpisem bez efektu.

Najczęściej zadawane pytania