Front-end entropisi gerçektir. Bir kod tabanı bir gecede çökmez. Birikir. Bir Salı günü bir tarih formatlama kütüphanesi eklersiniz. Altı ay sonra biri, ilkini bulamadığı için bir başkasını ekler. Artık desteklemediğiniz tarayıcılar için polyfill'ler birikir. Derleme araçları (build tools) üst üste biner. Sonunda, node_modules klasörü, korkmadan hiçbir şeyin atılamayacağı dijital bir hurda çekmecesine dönüşür. Güncellemeyi bırakırsınız. Sonra bakmayı da bırakırsınız. İşte o zaman her küçük değişiklik bir kumara dönüşür.

Eski bir projede Material UI sürümünü yükseltmeye çalışırken bu duvara çarptım. package.json dosyasını açtım ve girişlerin yarısını zar zor tanıdım. Onlarca kütüphane orada duruyordu; bazılarının tarihi yıllar öncesine dayanıyordu, bazılarının ise kimin neden eklediğini bulmak için git blame kontrol etmem gerekecek kadar belirsizdi. Yeni Material UI sürümü için yükleme (install) komutunu çalıştırdım ve terminal peer dependency uyarılarıyla aydınlandı. Güncellemek istediğim paket sorunsuzdu. Ancak etrafındaki ekosistem öyle değildi. Bir yükseltme yapmadığımı, bir harabeyi kazıdığımı fark ettim.

Bu Karmaşanın Maliyeti Neden Gururdan Daha Fazladır

Bağımlılıkları görmezden gelmek kozmetik bir sorun değildir. Gerçek ve maliyetli sorunlar yaratır.

Güvenlik riskleri bariz bir tehdittir. Terk edilmiş paketler, tarama araçlarının haftalık olarak işaretlediği ifşa edilmiş güvenlik açıkları taşır. Daha da kötüsü, doğrudan yüklediğiniz kütüphaneler sorunsuz olabilirken, onların beraberinde getirdiği transitive (dolaylı) bağımlılıklar olmayabilir. Bilmeden başkasının teknik borcunu devralırsınız.

Maliyet, zaman geçtikçe katlanır. Ne kadar beklerseniz, sürüm farkı o kadar açılır. Bir ana React sürümü atlamak bir iştir. Üç sürüm atlamak ise haftalarınızı alabilecek bir migrasyon projesidir. Hata düzeltmeleri, performans iyileştirmeleri ve modern araçlarla uyumluluk almayı bırakırsınız. Ekip, sonunda artık var olmayan kısıtlamaların etrafında çözüm üretmek zorunda kalır.

Kütüphaneler ölür. Aktif sürdürücüsü olmayan bir paket, varsayılan olarak sizin özel fork'unuz haline gelir. Bozulduğunda, gece yarısı onun minified kaynak kodunu okuyan kişi siz olursunuz. Topluluk daha iyi çözümlere geçmiştir ve sizin ekibiniz bir hayaletin bakımını yapmakla çakılıp kalmıştır.

Hız çöker. Yeni geliştiriciler, ilk günlerini web standartları veya ana akım alternatifler tarafından yerini alan araçların kendine has API'lerini öğrenerek geçirirler. Özellik (feature) yayınlamak yerine, kıdemli mühendisleriniz bu projenin neden hâlâ 2015'ten kalma bir task runner kullandığını açıklayan birer tarihçiye dönüşür.

Tek Bir Sürümü Bile Değiştirmeden Önce Denetleyin

En büyük hata, genel bir güncelleme (blanket update) çalıştırıp testlerin geçmesini ummaktır. Bir denetimle (audit) başlayın. package.json dosyasını elinize alın ve her bir girişi sorgulayın.

Dört soru sorun:

  • Bu hangi sorunu çözüyor?
  • Tam olarak nerede kullanıyoruz?
  • Hâlâ gerekli mi?
  • Şu an daha iyi bir alternatif var mı?

Gereksiz tekrarlar bulacaksınız. Belki de iki geliştirici aynı sorunu farklı zamanlarda çözdüğü için listede hem moment hem de date-fns yer alıyor. Belki de analizleriniz eski tarayıcılardan sıfır trafik gösterse bile bir Internet Explorer polyfill'i hâlâ gönderiliyor. Belki de modern tarayıcılar uç durumları (edge cases) yerel olarak yönettiği için fetch etrafındaki özel bir wrapper silinebilir.

Bazen değiştirmek, güncellemekten daha iyidir. Terk edilmiş bir grafik kütüphanesini üç yıllık kırılgan değişiklikler (breaking changes) içinde sürüklemek, kararlı bir alternatifle değiştirmek ve birkaç bileşeni yeniden inşa etmekten daha uzun sürebilir. Çıkarmaya (subtract) istekli olun.

Gizli Katman: Transitive Bağımlılıklar ve Semver

Doğrudan bağımlılıklar buzdağının sadece görünen kısmıdır. Asıl kütle, paketlerinizin ihtiyaç duyduğu paketler olan transitive bağımlılıkların altında yatar. Onları siz seçmediniz ama derleme (build) sürecinizde çalışırlar. Paket boyutunuzu şişirirler, saldırı yüzeyini genişletirler ve bazen birbirleriyle anlaşılmaz derleme hatalarına yol açacak şekilde çakışırlar.

Semantik versiyonlamayı (semantic versioning), olmasını umduğunuz anlamda değil, gerçekte ne anlama geldiği şeklinde okumanız gerekir.

  • Major updates: Bunlar migrasyonlardır. Aksine kanıtlanana kadar bunları breaking change olarak kabul edin. Değişim günlüğünü (changelog) okuyun, zaman ayırın ve kapsamlı bir şekilde test edin.
  • Minor updates: Bunlar özellik ekler. Davranışı ince yollarla değiştirebilirler de. Bunların bedava olduğunu varsaymayın.
  • Patch updates: Bunlar hataları düzeltir. Genellikle güvenlidirler, ancak kodunuz bir hataya güveniyorsa veya yama (patch), sizin monkey-patch yaptığınız dahili bir yapıyı değiştiriyorsa yine de sorun yaşayabilirsiniz.

Kuralları bilmek, herhangi bir şeye dokunmadan önce riski kategorize etmenize yardımcı olur.

Araçlarınızı Bir Zanaatkâr Gibi Kullanın

Eğer Yarn kullanıyorsanız, birkaç yerleşik komut tahmin yürütmeyi bir sürece dönüştürür.

Önce yarn outdated komutunu çalıştırın. Bu size neyin saptığına (drift) dair bir anlık görüntü sunar