ESLint Prettier konfigürasyon seçerken nelere dikkat edilmeli

ESLint ve Prettier: İki Farklı Araçın Rolünü Anlamak

Bir JavaScript projesine başlarken, kod kalitesi ve formatlaması konusunda karar vermek gereken geliştiriciler sık sık ESLint ve Prettier arasında kafa karışıklığı yaşarlar. Oysa bu iki araç tamamen farklı sorunları çözmek için tasarlanmıştır. ESLint, kod hatalarını ve kötü uygulamaları tespit eden bir linter iken Prettier, kodun görünüşünü düzenleyen bir formatterdir. Doğru konfigürasyon seçimi, takım verimliliğini ve kod bakım maliyetini direkt olarak etkiler. Karar verirken her aracın gücünü ve sınırlamalarını yan yana değerlendirmek gerekir.

Konfigürasyon Seçiminde İlk Kriter: Takım Büyüklüğü ve Yapısı

Tek kişilik bir proje ile çok kişili bir kurumsal takım arasında ideal konfigürasyon önemli ölçüde değişir. Küçük bir takımda, standart ESLint kuralları ve Prettier'ın varsayılan ayarları yeterli olabilir. Ancak 5+ geliştirici çalıştığında, tutarlılığı zorunlu kılmak için daha katı kurallar gerekir.

• Tek geliştirici veya küçük takım (1-3 kişi): Esnek konfigürasyon, az sayıda ESLint kuralı, Prettier'ın temel ayarları
• Orta ölçekli takım (4-10 kişi): Standart kural setleri (örneğin Airbnb, Google), Prettier ile zorunlu formatlaşma
• Büyük kurumsal yapı (10+ kişi): Özelleştirilmiş kural setleri, pre-commit hook'ları, CI/CD entegrasyonu

Takım büyüdükçe, her geliştiriciyi aynı standarda tabi tutmak için otomasyonun rolü artar. Bunu sağlamayan bir konfigürasyon, code review sürelerini uzatır ve merging çatışmalarına neden olur.

Kural Katılığı vs. Geliştirici Özgürlüğü: Denge Noktasını Bulmak

ESLint konfigürasyonunda en sık yapılan hata, çok katı kurallar uygulamaktır. Yeni bir projeye başlayan takımlar, tüm kuralları "error" seviyesinde etkinleştirerek, geliştirici deneyimini cezalandırır hale gelir. İdeal bir konfigürasyon, gerçek sorunları yakalar ama manevra alanı bırakır.

• Kesinlikle hata olarak işaretlenecek kurallar: `no-unused-vars`, `no-undef`, `semi` (eğer kullanılıyorsa)
• Uyarı olarak işaretlenecek kurallar: `complexity`, `max-depth`, stil ile ilgili tercihler
• Devre dışı bırakılabilecek kurallar: `prefer-const` (geliştirici tercihine bağlı), `no-console` (geliştirme aşamasında)

Prettier seçeneğinde ise, en yaygın tartışma noktası satır uzunluğu (line length) ve tab vs. space tercihi olur. 80 karakter sınırı eski standarttan kalma bir alışkanlıktır; modern monitörlerde 100-120 karakter daha yaygın ve okunabilir bir seçimdir.

Proje Türüne Göre Konfigürasyon Profilleri

Her proje türü, farklı başlangıç noktalarını gerektiren benzersiz zorluklar sunar:

TypeScript kullanan bir projedeyse, ESLint yapılandırması normal JavaScript kurallarından farklı olmalıdır. `@typescript-eslint` paketini kullanmamak, tip güvenliği ile ilgili hataları atlatacak demektir.

Otomasyon ve Zorlama Mekanizmaları

Bir konfigürasyon seçtikten sonra, onu takıma uygulama şekli onun başarısını belirler. Elle uygulanmayan kurallar, geliştirici tarafından görmezden gelinir.

• Pre-commit Hook'lar (Husky + lint-staged): Commit işleminden önce ESLint ve Prettier çalıştırır; hatalı kod depolanmasını engeller
• CI/CD Entegrasyonu: Pull request'lerde otomatik lint kontrolü yapar; başarısız check'ler merge'i bloklar
• Editor Eklentileri: Geliştirici yazarken gerçek zamanlı geri bildirim sağlar (VS Code: ESLint + Prettier eklentileri)
• IDE Ayarları: Format on save özelliğini açmak, Prettier'ın otomatik çalışmasını sağlar

Hazırlanmış bir konfigürasyon, hiçbir otomasyon olmadan ise pratik değer taşımaz. En az bir seviyede CI/CD entegrasyonu olması, uzun vadede disiplini korur.

Ortak Yanlışlar ve Çözümleri

Çatışan Kurallar: ESLint ve Prettier arasında tutarsız ayarlar varsa, birinin kuralı diğerinin formatlaşmasıyla çelişir. Örneğin, ESLint `max-line-length` kontrol ederse ve Prettier onu kırarsa, durum kilitlenir. Çözüm: Prettier'ın otomatik formatlaşmasına izin verin, ESLint'i sadece mantıksal hatalar için kullanın.

Yapılandırma Dosyası Karmaşıklığı: `.eslintrc.json` veya `.prettierrc` dosyalarındaki aşırı kurallar, yeni geliştirici katılımında öğrenme eğrisini sterilleştirir. Başlangıçta temel profil kullanıp, gerekçe ile kurallar eklemek daha iyidir.

Eski Kurallara Bağlılık: Bir kuralın neden var olduğunu bilmeden uygulamak, teknik borcun başlangıcıdır. Her kural, projeye gerçek değer katmalıdır.

Sonuç: Kademeli Bir Yaklaşım

ESLint Prettier konfigürasyonunda doğru seçim, takım dinamiğini, proje türünü ve uzun vadeli bakım hedeflerini göz önüne alır. Başlangıçta standart bir profil seçerek başlamak, zamanla proje ihtiyaçlarına göre özelleştirmek en mantıklı yoldur. Konfigürasyon ne kadar iyi olursa, takımın buna uyması o kadar zor hale gelir; denge kritiktir. Otomasyon araçlarıyla desteklenmeyen konfigürasyonlar ise sadece dokümantasyon kalır. Doğru seçimi yaparken, bugünün ihtiyaçları kadar gelecekteki ölçeklenebilirliği de düşünmek gerekir.