EditorConfig-generator

Vad .editorconfig gör

En fil med namnet .editorconfig i roten av ett projekt deklarerar formateringskonventioner. Editorer med EditorConfig-stöd (varje större IDE och de flesta moderna textredigerare) tillämpar de reglerna när en fil öppnas. Sökningen går uppåt i katalogträdet från filen som redigeras och stannar vid den första filen som säger root = true.

Exempel på utdata

Med standardinställningarna (mellanslag, indragsstorlek 4, LF, utf-8) och de två sektioner som redan är ikryssade genererar verktyget:

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

Kryssa i Python, Go eller YAML så dyker motsvarande sektion upp nedanför, redan med den konvention som ekosystemets formaterare tvingar fram.

Viktiga direktiv

Tre regler som stoppar bygget, inte bara bryter mot en stilguide

De flesta inställningarna i en .editorconfig är smaksak. De här tre är det inte, och de är skälet till att det är värt att ha en sektion per språk:

• YAML förbjuder tabbtecknet för indrag. Det är ett parsningsfel, inte en lint-varning. Om ditt projekt gör indrag med tabbar och du har workflows i GitHub Actions, Docker Compose-filer eller Kubernetes-manifest måste YAML-sektionen tvinga tillbaka mellanslag.
• make kräver ett riktigt tabbtecken i början av varje kommandorad i en regel. Ett mellanslag ger missing separator. Stop. och bygget avbryts. Det är därför [{Makefile,makefile,GNUmakefile,*.mk}] räknar upp flera stavningar: EditorConfig matchar filnamn skiftlägeskänsligt, och repon innehåller både Makefile och makefile.
• Ett skalskript som sparats med CRLF går inte att köra. Kärnan läser vagnreturen som en del av sökvägen till tolken och rapporterar något i stil med /bin/bash^M: bad interpreter: No such file or directory. Windows-batchfiler har det spegelvända problemet: cmd.exe letar upp goto och call :label via byteposition, så en .bat med enbart LF kan hoppa till fel rad eller stanna halvvägs utan något felmeddelande alls.

Två av dem kan orsakas av det globala blocket i stället för att lösas av det, och det är därför den här generatorn håller utkik efter dem. Om du väljer tabbar utan att lägga till YAML-sektionen, eller väljer CRLF utan att lägga till skalsektionen, kommer filen som skrivs att förstöra just de filerna trots att de aldrig nämns i den. Generatorn säger till ovanför utdatan i stället för att låta dig upptäcka det via en pipeline som fallerar. Detsamma gäller teckenuppsättningarna utf-16: de gäller varje fil i projektet, och make, skaltolkar och Python kan inte läsa källkod som sparats så.

Språkkonventioner som generatorn skriver

Lägg märke till vad som inte står i den tabellen: radlängder. PEP 8 säger 79, Black säger 88, PSR-12 säger en mjuk gräns på 120 och rustfmt säger 100. Att skriva in någon av dem i en språksektion skulle i tysthet åsidosätta gränsen du valde för hela projektet, så generatorn lämnar max_line_length enbart i [*]-blocket och behåller de siffrorna här, där du kan tillämpa dem medvetet.

Stöder din editor det?

Inbyggt stöd: VS Code, JetBrains IntelliJ-familjen, Visual Studio, Sublime Text, Xcode och Notepad++. Vim, Emacs, Neovim och några till behöver ett litet plugin. Filen är vanlig INI, så linters och formaterare kan också läsa den, och det är så Prettier och vissa språkservrar håller sig i takt med den.