Tree Shaking Nedir?
Kısa tanım
Tree shaking, bir paketleyicinin (bundler) JavaScript modüllerinde dışa aktarılan ama hiçbir yerde kullanılmayan kodu tespit edip son pakete dahil etmemesidir; ölü kod elemenin (dead code elimination) modüller arası bir biçimidir. ES modüllerinin statik import ve export yapısına dayanır. Terim Rollup ile yaygınlaştı; bugün webpack, esbuild ve Turbopack gibi araçlar da üretim derlemelerinde bu optimizasyonu uygular.
Diğer adları: ağaç sallama, dead code elimination, ölü kod eleme, kullanılmayan kodu temizleme
Neden ES modülleri gerekir?
Tree shaking'in çalışabilmesi için paketleyicinin, kod çalışmadan önce hangi modülün hangi parçasının kullanıldığını bilmesi gerekir. ES modüllerinde import ve export ifadeleri dosyanın en üst seviyesinde, statik olarak yazılır; bu yüzden derleme anında analiz edilebilir. CommonJS'in require() çağrısı ise sıradan bir fonksiyondur: koşullu çağrılabilir, adı çalışma anında hesaplanabilir. Bu belirsizlik nedeniyle CommonJS modülleri güvenle budanamaz.
// format.js
export function tarih(d) { /* ... */ }
export function para(n) { /* ... */ }
export function yuzde(n) { /* ... */ }
// app.js
import { para } from "./format.js";
console.log(para(1250));
// Üretim paketinde yalnızca para() yer alırYan etkiler ve sideEffects alanı
Bir modülün hiçbir dışa aktarımı kullanılmıyor olsa bile, içe aktarıldığı anda bir şey yapıyor olabilir: bir polyfill yüklemek, global bir nesneyi değiştirmek veya bir CSS dosyasını sayfaya eklemek. Paketleyici bunu kesin bilemediği için varsayılan olarak temkinli davranır ve modülü tutar. Paket yazarları package.json içindeki sideEffects alanıyla bu belirsizliği kaldırabilir:
{
"name": "ornek-ui",
"sideEffects": ["**/*.css", "./src/polyfill.js"]
}"sideEffects": false tüm paketin yan etkisiz olduğunu söyler. Bu iddia yanlışsa sonuç sessiz bir hatadır: en tipik örnekte içe aktarılan CSS dosyaları paketten düşer ve stiller kaybolur. Tek bir fonksiyon çağrısının yan etkisiz olduğunu belirtmek için /*#__PURE__*/ açıklaması kullanılır.
Tree shaking'i bozan alışkanlıklar
- Kodu CommonJS'e dönüştürmek: Babel gibi bir aracın modülleri
require()'a çevirmesi analizi imkânsız kılar. Dönüştürücü, ES modül sözdizimini paketleyiciye olduğu gibi bırakmalıdır. - Yalnızca CommonJS sürümü olan kütüphaneler: Bir yardımcı fonksiyon için tüm kütüphane pakete girebilir. Bir bağımlılık seçerken ES modül sürümü olup olmadığına bakmak bu yüzden önemlidir.
- Her şeyi yeniden dışa aktaran "barrel" dosyalar: Yüzlerce modülü tek bir
index.js'ten dışa aktaran ikon veya yardımcı kütüphaneler, yan etki bilgisi eksikse analizi zorlaştırır. Next.js bu tür paketler içinoptimizePackageImportsayarını sunar. - Yalnızca geliştirme modunda test etmek: Tree shaking ve küçültme ağırlıklı olarak üretim derlemesinde devreye girer; paket boyutu üretim çıktısı üzerinden değerlendirilmelidir.
Minification ve code splitting'den farkı
| Teknik | Ne yapar? |
|---|---|
| Tree shaking | Modüller arasında kullanılmayan dışa aktarımları pakete hiç almaz |
| Minification | Kalan kodu kısaltır; boşlukları, yorumları ve dosya içindeki erişilemez kodu atar |
| Code splitting | Kodu silmez; ayrı parçalara taşıyarak ne zaman yükleneceğini değiştirir |
Üçü birbirini tamamlar ve modern paketleyicilerde genellikle birlikte çalışır.
Sonucu doğrulamak
Tree shaking'in gerçekten çalıştığını görmenin en güvenilir yolu üretim paketini analiz etmektir: tek bir fonksiyonunu kullandığınız bir kütüphane analiz ekranında tüm boyutuyla görünüyorsa bir şeyler budamayı engelliyordur. Paket boyutunu CI'da bir performans bütçesine bağlamak, yeni eklenen bir bağımlılığın sessizce yüzlerce kilobayt eklemesini erkenden yakalar. Ayrıntılı yapılandırma örnekleri webpack'in tree shaking rehberinde bulunur.