Canlı ortamda bir JavaScript hatası çıktı. Tarayıcı konsolunu açtınız, kaynak koda baktınız — tek satır, yüzlerce değişken ardı ardına, hiçbir boşluk yok. Hata hangi satırda? Satır 1. Minify edilmiş kodda her şey satır 1'dedir.
İki soru birden geliyor akla: "Bu kodu tekrar okunabilir hale getirebilir miyim?" ve "Hatayı nasıl bulacağım?" İkisi farklı sorular, cevapları da farklı.
Minify sonrasında kodun yapısına ne olur
Minify işlemi temelde üç şey yapar: gereksiz boşlukları ve satır sonlarını kaldırır, yorumları siler, isteğe bağlı olarak değişken isimlerini kısaltır. Bu son adıma mangle denir. Üç adımın hepsi birbirinden bağımsız; her araç bunları farklı kombinasyonlarda uygulayabilir. Terser varsayılan yapılandırmasında mangle'ı açık bırakır; esbuild ise varsayılan olarak mangle uygulamaz.
500 satırlık bir JavaScript dosyası tek satıra sığar. Tarayıcı bu formatı orijinal kod kadar hızlı çalıştırır — zaten tarayıcı için syntax ne kadar sade olursa o kadar iyi. İnsan okuyucu için ise başka bir hikâye. Şuna benzeyen bir fonksiyon:
function hesapla(miktar, oran) {
// Yüzde hesabı
const sonuc = miktar * oran / 100;
return sonuc;
}Minify ve mangle sonrasında şöyle görünür:
function a(b,c){return b*c/100}Yorum gitti. Değişken adları gitti. Girintiler gitti. Fonksiyon adı bile değişti. Bu çıktıdan geri dönüş yoktur — bilgi kalıcı olarak kaybolmuştur.
CSS ve HTML için durum farklıdır. CSS minify'da mangle kavramı yoktur; sınıf adları ve özellik isimleri olduğu gibi kalır, yalnızca boşluklar ve yorumlar temizlenir. Dolayısıyla minify edilmiş bir CSS dosyasını beautify ettiğinizde çıktı, orijinal kaynağa çok yakındır. HTML için de benzer bir durum geçerlidir; semantik içerik kaybolmaz. Beautify sonrası en kolay okunan dosya türleri CSS ve HTML'dir — en zorlu olan ise mangle uygulanmış JavaScript.
Beautify nedir, ne yapar
Beautify — ya da pretty-print olarak da adlandırılır — minify edilmiş bir kodu yeniden biçimlendirerek insanın okuyabileceği hale getirir. Yaptığı şey: satır sonları ekler, girintiler koyar, blok yapılarını görünür kılar. Kayıp bilgiyi geri getirmez. Bu ayrım kritik.
Tarayıcı DevTools'un kaynak kod panelinde küme parantezi simgesi ({}) genellikle bunu tek tıkla yapar — Chrome, Firefox ve Edge bu özelliği destekler. Alternatif olarak editör eklentileri veya tarayıcıda çalışan araçlar kullanılabilir (bu ayrımın neden önemli olduğuna aşağıda değineceğiz).
Beautify sonrasında yukarıdaki fonksiyon şöyle görünür:
function a(b, c) {
return b * c / 100;
}Okunabilirlik arttı, yapı geri geldi. Ama a, b, c hâlâ orada. Beautify yalnızca biçimi düzeltir; kaybolmuş anlam bilgisini değil.
Beautify'ın geri getiremediği bilgiler
Mangle uygulanmışsa değişken ve fonksiyon isimleri kısaltılmıştır. Beautify bunları orijinal haline döndüremez — çünkü orijinal isimler minify çıktısında artık yoktur. Hiçbir yerde yoktur. userAuthentication yerine t görürsünüz; calculateTotalPrice yerine f. Beautify bu harfleri tekrar anlamlı hale getiremez.
Yorumlar da aynı şekilde. Minify sırasında silinen bir yorum, beautify ile geri gelmez. Kodu orijinal geliştiricinin mantığıyla anlamlandırmak için yorum satırlarına güveniyordunuz — bunlar artık yok.
Minify bir çeviri değil, bir damıtmadır (bu metaforu aklınızda tutun). Çıktıyı ham maddeye geri döndürmek mümkün değildir. Beautify ise o damıtılmış çıktının sunumunu düzeltir; damıtmadan önceki içeriği geri getirmez.
Tek istisna, mangle uygulanmamış dosyalardır. Eğer yalnızca boşluklar ve yorumlar kaldırılmışsa, beautify sonrasında orijinal değişken isimlerini görürsünüz. Minify aracında mangle seçeneğini kapalı bırakmak, debug gereksinimini göz önünde bulunduruyorsanız bilinçli bir tercih olabilir — ancak dosya boyutu daha az küçülür.
Peki ya Terser'ın if/else bloklarını ternary operatöre dönüştürmesi? Bu da beautify'ın geri getiremeyeceği bir dönüşümdür. Üç satırlık bir koşul, beautify sonrasında x ? y : z biçiminde tek satırda kalır; orijinal geliştirici niyeti — neden ayrı bir if bloğu tercih edildiği — kaybolmuştur. Closure Compiler gibi araçlar ise bunu çok daha ileri götürür: fonksiyon birleştirme, dead code elimination ve satır içi yapıştırma (inlining) sonrasında oluşan kod, kaynakla yapısal olarak benzeri kalmaz.
Debug için beautify ne zaman yeterlidir
Mangle uygulanmamış bir minify çıktısıyla karşı karşıyaysanız, beautify büyük ölçüde yeterlidir. Satır numaraları anlamlı hale gelir, blok yapıları görünür olur, değişken isimlerini takip edebilirsiniz. Bir sözdizimi hatası veya açık bir mantık hatası arıyorsanız bu genellikle yeterlidir.
Mangle uygulanmışsa tablo değişir. a(b, c)'nin ne yaptığını anlamak için kodu yavaşça çalıştırıp değerleri izlemeniz gerekir. Karmaşık bir iş mantığında bu ciddi zaman kaybına dönüşür — değişkenlerin adları anlamsızken, hangi hata mesajının hangi kod bloğundan geldiğini izlemek çok daha zordur.
Beautify'ın yetersiz kaldığı bir diğer durum: dinamik olarak üretilmiş kod veya çok sayıda modülün birleştirildiği bundle dosyaları. Birkaç farklı kütüphane tek çıktıya paketlenmişse, beautify sonrasında hangi fonksiyonun nereye ait olduğunu anlamak hâlâ karmaşık kalır.
Pratikte yaygın bir senaryo şudur: üçüncü taraf bir kütüphanenin minify edilmiş dosyasında beklenmedik bir davranış var. O kütüphanenin kaynak kodunu GitHub'da bulabilirsiniz; beautify'ın verdiği çıktıyla karşılaştırarak mantığı anlayabilirsiniz. Bu, beautify'ın gerçekten işe yaradığı durumlardan biridir. Kendi yazdığınız ve mangle uygulanmış kodunuzda ise kaynak dosyaya dönmek neredeyse her zaman daha hızlıdır.
Bir soruyu da sormak gerekir: production'daki bir hatayı debug ederken neden minify edilmiş kodla uğraşıyorsunuz? Cevap "başka çaremiz yok"sa, build sürecinizde source map eksikliği var demektir. Bu teknik bir borçtur; tek seferlik bir debug seansında ödeyebilirsiniz, ama sonraki hatada aynı sürtünmeyle karşılaşırsınız.
Online beautifier kullanıyorsanız, kodu sunucuya gönderdiğinizi unutmayın. Ticari veya gizli iş mantığı içeren kod için tarayıcıda yerel çalışan bir araç tercih edin; parse işlemi doğrudan tarayıcıda gerçekleşir, kod dışarı çıkmaz. Gizlilik kriteri, hızlı çözüm ararken en çok atlanan noktadır.
Source map — debug için doğru çözüm
Source map, minify edilmiş kodu orijinal kaynak koduna haritalayan bir dosyadır. Tarayıcı bu dosyayı okuyarak konsoldaki "satır 1, kolon 47382" yerine size orijinal dosyadaki "authentication.js, satır 23" bilgisini gösterir. Değişken isimleri, fonksiyon adları, dosya sınırları — hepsi korunur.
Source map tipik olarak .map uzantısıyla üretilir ve minify çıktısının sonuna şu yorum eklenir:
//# sourceMappingURL=app.min.js.mapWebpack, Vite, esbuild ve Terser bu dosyayı otomatik olarak üretebilir. Build yapılandırmanızda genellikle sourcemap: true veya devtool: 'source-map' gibi tek bir seçenek yeterlidir. Bunu bir kez kurmak, sonraki her debug sürecinde saatlerce tasarruf sağlar.
Production ortamında source map bırakmak hakkında sık sorulan bir soru var: kaynak kodunuzu ifşa eder mi? Evet, source map dosyası sunucuya yüklenirse kaynak koda ulaşmak kolaylaşır. Yaygın yaklaşım, map dosyalarını sunucuya yüklemeyip yalnızca Sentry gibi hata izleme servislerine özel bir konuma koymaktır. Tarayıcı map dosyasına ulaşamazsa hata ayıklama bilgisi dışarıya açılmaz; map dosyasını bilen bir ekip üyesi ise yerel ortamda tam debug yapabilir. Bu ikilinin doğru kurgulanması, hem güvenliği hem debuglama kapasitesini korur.
Source map dosyasının boyutu konusunda da gereksiz kaygıya gerek yoktur. Map dosyası yalnızca DevTools açıkken ve ilgili domain'den istendiğinde indirilir. Normal kullanıcılar bu dosyayı hiç indirmez; sayfa yükleme süresine etkisi sıfırdır.
Sayfanızın kaynak boyutunu ve render-blocking dosyalarını analiz ettiğinizde minify için hangi dosyaları önceliklendirmeniz gerektiği netleşir. Minify her dosya için zorunlu değildir: zaten küçük olan bir kaynak için pipeline bakım maliyeti yaratmak ve source map'i yönetmek, çoğu zaman anlamlı bir kazanım sağlamaz.
Beautify çıktıyı okunabilir kılar; mangle edilmiş bir dosyada kayıp olan anlam bilgisini ise hiçbir araç geri getiremez. Debug için gerçekten ihtiyaç duyulan şey, production yapılandırmalarından bağımsız olarak build sürecinde üretilen ve saklanan source map dosyasıdır. Beautify bu dosyanın yedeği değil, yokluğunda başvurulan geçici bir köprüdür.