Tek bir dinamik ikon importu, 16 GB RAM'li bir Windows Subsystem for Linux 2 (WSL2) makinesinde geliştirme sunucusunu çökertti; vmmemWSL sürecinin mevcut tüm belleği sömürmesine ve tüm Linux penceresinin donmasına neden oldu. Çökme, Turbopack kullanan bir Next.js 16 projesi çalıştırılırken gerçekleşti ve VM'in RAM kullanımını sınırlandıran bir .wslconfig dosyasına rağmen yaşandı.

Neden küçücük bir import bir canavara dönüşebilir

Geliştirici, ikonları çalışma zamanında (runtime) dinamik bir giriş noktasıyla çözmeye çalıştı. Bu import, yaklaşık 9.000 modül içeren bir ikon paketini beraberinde getirdi. Next.js 16'nın geliştirme sunucusuna güç veren Rust tabanlı paketleyici (bundler) Turbopack, dokunduğu her paket için tam bir modül haritası oluşturur. Geliştirme modunda bu harita bellekte tutulur ve her dosya değişikliğinde güncellenir. Tüm ikon paketinin yüklenmesi, Turbopack'i büyük miktarda RAM ayırmaya zorladı ve bu da hızla .wslconfig dosyasında belirlenen katı sınıra ulaşmasına neden oldu. Sınıra ulaşıldığında WSL VM'i yanıt vermeyi kesti; Ctrl + C hiçbir işe yaramadı ve tek çözüm Windows ana makinesini (host) zorla kapatmaktı.

Aynı kodun üretim (production) derlemesi başarılı oldu çünkü paketleyici grafiği bir kez derler, varlıkları (assets) oluşturur ve çıkar. Ancak geliştirme sunucusu, hot-reloading özelliğini etkinleştirmek için grafiği bellekte tutmaya devam eder. Bu nedenle, başarılı bir derleme (green build), geliştirme ortamının aynı import desenine dayanabileceğini garanti etmez.

Daha geniş kapsamlı riskler

Windows içinde Linux tabanlı araç zincirleri (toolchains) üzerinde çalışan geliştiriciler, kaynak kullanımını izole etmek için WSL2'ye güvenirler. Tek bir import VM'in belleğini tükettiğinde, tüm ana makine yavaşlayabilir veya yanıt vermeyebilir; bu da aynı makinedeki diğer konteynerleri veya uygulamaları etkileyebilir. Bu olay aynı zamanda tipik Node.js bellek ayarlama bayrakları (flags) ile Turbopack'in mimarisi arasındaki uyumsuzluğu da vurguluyor: Turbopack V8'de değil, Rust'ta çalışır; bu nedenle Node --max-old-space-size bayrağını artırmak RAM tüketimini dizginlemek için hiçbir işe yaramaz.

Aslında ne yanlış gitti

  • Dinamik giriş noktası: Import ifadesi, paketleyiciden tüm ikon paketini tek bir, tembel yüklenen (lazily-loaded) modül olarak ele almasını istedi. Turbopack, modül haritasını oluşturmak için her dosyayı hevesle (eagerly) ayrıştırarak yanıt verdi.
  • Geliştirme sunucusu grafiği: Tek seferlik bir üretim derlemesinin aksine, geliştirme sunucusu dosya değişikliklerinde anında geri bildirim sağlamak için tam bağımlılık grafiğini RAM'de tutar.
  • Bellek sınırı: .wslconfig dosyası VM'i ana makinenin RAM'inin küçük bir kısmıyla sınırladı. Turbopack'in talebi bu sınırı aştığında VM dondu.

Belleği yarı yarıya düşüren çözümler

Geliştirici, RAM kullanımını 3,6 GB'tan 1,87 GB'a düşüren ve kararlılığı geri getiren üç pratik değişiklik uyguladı:

  1. Küçük varlıklar için dinamik giriş noktaları kullanmayı bırakın – Sadece ihtiyacınız olan ikonları içe aktarın, örneğin: import { SearchIcon } from 'icon-pack/search'. Eğer sadece birkaç tane lazımsa, satır içi (inline) SVG'ler daha da hafiftir.
  2. next.config.ts içinde optimizePackageImports seçeneğini etkinleştirin – Bu seçenek, Turbopack'e importları paket kökü yerine doğrudan dosya yollarına çözmesini söyleyerek tüm paket ağacını yüklemesini engeller.
  3. Node heap bayraklarına güvenmeyin – Turbopack'in bellek kullanımı Rust çalışma zamanı tarafından yönetildiğinden, --max-old-space-size sorunun üzerinde bir etkiye sahip değildir.

.wslconfig sınırlarını korumak hala tavsiye edilir. Katı bir sınır, Windows ana makinesini çökertmek yerine VM'in duraklamasına neden olarak her şey durmadan önce müdahale etme şansı verebilir.

Kendi iş akışınızda nelere dikkat etmelisiniz

  • Bellek izleme panelleri: WSL içindeki htop veya Windows Görev Yöneticisi gibi araçlar, vmmemWSL'in ne zaman yükseldiğini gösterebilir. Kullanım yapılandırılmış sınıra yaklaştığında uyarılar ayarlayın.
  • Paket boyutu denetimleri: Bir kütüphane eklemeden önce kaç modül içerdiğini kontrol edin. Büyük ikon paketleri, yardımcı araç koleksiyonları veya bileşen kütüphaneleri geliştirme grafiğini sessizce şişirebilir.
  • Seçici importlar: Özellikle paketleyicinin her şeyi bellekte tuttuğu bir geliştirme ortamında, joker karakterli (wildcard) veya dinamik importlar yerine isimlendirilmiş (named) importları veya doğrudan dosya yollarını tercih edin.
  • Üretim ve geliştirme ortamı paralelliği: Başarılı bir üretim derlemesini ayrı bir doğrulama adımı olarak değerlendirin. Sadece hot-reloading sırasında ortaya çıkan sorunları yakalamak için geliştirme sunucusunu bir bellek izleyici ile çalıştırın.

Özet

Tek bir, dinamik olarak içe aktarılan ikon paketi, ana makinenin kaynakları kasten sınırlandırılmış olsa bile, bir WSL2 tabanlı Next.js geliştirme sunucusunu felç edebilecek kadar RAM tüketebilir. Geniş kapsamlı dinamik importlardan kaçınarak, paket düzeyinde import optimizasyonunu etkinleştirerek ve bellek kullanımını izleyerek, geliştiriciler Linux-içinde-Windows ortamlarını duyarlı tutabilir ve zorla kapatmalardan kaçınabilirler.