Generator EditorConfig

Fungsi file .editorconfig

File bernama .editorconfig di akar sebuah proyek mendeklarasikan konvensi format. Editor yang mendukung EditorConfig (semua IDE utama dan sebagian besar editor teks modern) menerapkan aturan tersebut saat sebuah file dibuka. Pencariannya menelusuri pohon direktori ke atas dari file yang sedang diedit dan berhenti pada file pertama yang berisi root = true.

Contoh keluaran

Dengan pengaturan bawaan (spasi, ukuran indentasi 4, LF, utf-8) dan dua bagian yang sudah dicentang untuk Anda, generator menghasilkan:

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

Centang Python, Go, atau YAML dan bagian yang sesuai akan muncul di bawahnya, sudah membawa konvensi yang dipaksakan oleh formatter ekosistem tersebut.

Direktif utama

Tiga aturan yang merusak build, bukan sekadar panduan gaya

Sebagian besar isi .editorconfig hanyalah preferensi. Tiga hal berikut bukan preferensi, dan justru inilah alasan bagian per bahasa layak dimiliki:

• YAML melarang karakter tab untuk indentasi. Itu kesalahan parsing, bukan peringatan lint. Kalau proyek Anda memakai indentasi tab dan Anda punya workflow GitHub Actions, file Docker Compose, atau manifest Kubernetes, bagian YAML harus memaksa spasi kembali aktif.
• make menuntut tab literal di awal setiap baris resep. Spasi akan menghasilkan missing separator. Stop. dan build berhenti. Itulah sebabnya [{Makefile,makefile,GNUmakefile,*.mk}] mencantumkan beberapa ejaan: EditorConfig mencocokkan nama file secara case sensitive, dan repositori bisa memuat Makefile maupun makefile.
• Skrip shell yang disimpan dengan CRLF tidak bisa dijalankan. Kernel membaca carriage return sebagai bagian dari path interpreter lalu melaporkan sesuatu seperti /bin/bash^M: bad interpreter: No such file or directory. File batch Windows punya masalah kebalikannya: cmd.exe mencari goto dan call :label berdasarkan offset byte, jadi file .bat yang hanya memakai LF bisa melompat ke baris yang salah atau berhenti di tengah jalan tanpa pesan error sama sekali.

Dua di antaranya justru bisa disebabkan oleh blok global, bukan diperbaiki olehnya, dan karena itulah generator ini mengawasinya. Kalau Anda memilih tab tanpa menambahkan bagian YAML, atau memilih CRLF tanpa menambahkan bagian shell, file yang ditulisnya akan merusak file-file itu meski namanya tidak pernah disebut di dalamnya. Generator memberitahukannya di atas keluaran, alih-alih membiarkan Anda mengetahuinya dari pipeline yang gagal. Hal yang sama berlaku untuk charset utf-16: charset itu berlaku untuk semua file di proyek, dan make, interpreter shell, serta Python tidak bisa membaca kode sumber yang disimpan seperti itu.

Konvensi bahasa yang ditulis generator ini

Perhatikan apa yang tidak ada di tabel itu: panjang baris. PEP 8 menyebut 79, Black 88, PSR-12 menyarankan 120 yang tidak kaku, dan rustfmt 100. Menuliskan salah satunya ke dalam bagian bahasa akan diam-diam menimpa batas yang Anda pilih untuk seluruh proyek, jadi generator hanya menaruh max_line_length di blok [*] dan menyimpan angka-angka itu di sini, tempat Anda bisa menerapkannya secara sadar.

Apakah editor Anda mendukungnya?

Dukungan bawaan: VS Code, keluarga JetBrains IntelliJ, Visual Studio, Sublime Text, Xcode, dan Notepad++. Vim, Emacs, Neovim, dan beberapa editor lain butuh plugin kecil. File ini berformat INI biasa, jadi linter dan formatter juga bisa membacanya, dan begitulah Prettier serta sebagian language server tetap selaras dengannya.