Satu import ikon dinamik telah menyebabkan pelayan pembangunan (dev server) tergendala pada mesin Windows Subsystem for Linux 2 (WSL2) 16 GB, memaksa proses vmmemWSL menggunakan semua memori yang tersedia dan membekukan keseluruhan tetingkap Linux. Kerosakan ini berlaku semasa menjalankan projek Next.js 16 yang menggunakan Turbopack, dan ia berlaku walaupun terdapat fail .wslconfig yang mengehadkan penggunaan RAM VM.

Mengapa import kecil boleh menjadi raksasa

Pembangun cuba menyelesaikan ikon pada waktu larian (runtime) dengan titik masuk dinamik (dynamic entry point). Import tersebut menarik masuk pakej ikon yang mengandungi kira-kira 9,000 modul. Turbopack, pembundel (bundler) berasaskan Rust yang menggerakkan pelayan pembangunan Next.js 16, membina peta modul penuh bagi setiap pakej yang disentuhnya. Dalam mod pembangunan, peta tersebut disimpan dalam memori dan dikemas kini pada setiap perubahan fail. Memuatkan keseluruhan pakej ikon memaksa Turbopack memperuntukkan sejumlah besar RAM, dengan cepat mencapai had siling yang ditetapkan oleh fail .wslconfig. Sebaik sahaja had tersebut dicapai, VM WSL berhenti bertindak balas; Ctrl + C tidak berfungsi dan satu-satunya jalan keluar adalah dengan menutup paksa hos Windows.

Binaan pengeluaran (production build) bagi kod yang sama berjaya kerana pembundel tersebut menyusun graf sekali gus, mengeluarkan aset, dan keluar. Walau bagaimanapun, pelayan pembangunan mengekalkan graf tersebut dalam memori untuk membolehkan pemuatan semula panas (hot-reloading). Oleh itu, binaan yang berjaya (green build) tidak menjamin bahawa persekitaran pembangunan dapat bertahan dengan corak import yang sama.

Implikasi yang lebih luas

Pembangun yang bekerja dengan rangkaian alatan (toolchains) berasaskan Linux di dalam Windows bergantung kepada WSL2 untuk mengasingkan penggunaan sumber. Apabila satu import menghabiskan memori VM, keseluruhan hos boleh menjadi lembap atau tidak responsif, menjejaskan mana-mana kontena atau aplikasi lain pada mesin yang sama. Insiden ini juga menonjolkan ketidakpadanan antara bendera penalaan memori Node.js tipikal dengan seni bina Turbopack: Turbopack berjalan dalam Rust, bukan V8, jadi meningkatkan bendera Node --max-old-space-size tidak membantu mengurangkan penggunaan RAM-nya.

Apa yang sebenarnya berlaku

  • Titik masuk dinamik: Kenyataan import meminta pembundel untuk melayan keseluruhan pakej ikon sebagai satu modul yang dimuatkan secara malas (lazily-loaded). Turbopack bertindak balas dengan menganalisis (parsing) setiap fail secara agresif (eagerly) untuk membina peta modul.
  • Graf pelayan pembangunan: Tidak seperti kompilasi pengeluaran sekali guna, pelayan pembangunan menyimpan graf kebergantungan penuh dalam RAM untuk memberikan maklum balas segera pada perubahan fail.
  • Had memori: Fail .wslconfig mengehadkan VM kepada sebahagian kecil daripada RAM hos. Apabila permintaan Turbopack melebihi had tersebut, VM membeku.

Penyelesaian yang mengurangkan memori separuh

Pembangun telah melaksanakan tiga perubahan praktikal yang mengurangkan penggunaan RAM daripada 3.6 GB kepada 1.87 GB dan memulihkan kestabilan:

  1. Berhenti menggunakan titik masuk dinamik untuk aset kecil – Import hanya ikon yang anda perlukan, contohnya import { SearchIcon } from 'icon-pack/search'. Jika anda hanya memerlukan segelintir, SVG dalam talian (inline SVGs) adalah lebih ringan.
  2. Aktifkan optimizePackageImports dalam next.config.ts – Pilihan ini memberitahu Turbopack untuk menyelesaikan import ke laluan fail konkritnya dan bukannya ke akar pakej, sekali gus menghalangnya daripada memuatkan keseluruhan pokok pakej.
  3. Jangan bergantung pada bendera heap Node – Memandangkan penggunaan memori Turbopack dikawal oleh masa larian Rust-nya, --max-old-space-size tidak memberi kesan kepada masalah ini.

Mengekalkan had .wslconfig masih disyorkan. Had keras (hard cap) mungkin menyebabkan VM berhenti seketika berbanding menyebabkan hos Windows tergendala, memberikan anda peluang untuk campur tangan sebelum semuanya terhenti.

Apa yang perlu diperhatikan dalam aliran kerja anda

  • Papan pemuka memori: Alatan seperti htop di dalam WSL atau Windows Task Manager boleh mendedahkan bila vmmemWSL melonjak. Tetapkan amaran jika penggunaan menghampiri had yang telah dikonfigurasikan.
  • Audit saiz pakej: Sebelum menambah perpustakaan (library), semak berapa banyak modul yang disertakan. Pakej ikon yang besar, koleksi utiliti, atau perpustakaan komponen boleh membengkakkan graf pembangunan secara senyap.
  • Import terpilih: Utamakan import bernama (named imports) atau laluan fail terus berbanding import wildcard atau dinamik, terutamanya dalam persekitaran pembangunan di mana pembundel mengekalkan semuanya dalam memori.
  • Pariti pengeluaran vs pembangunan: Anggap binaan pengeluaran yang berjaya sebagai langkah pengesahan yang berasingan. Jalankan pelayan pembangunan dengan pemantau memori untuk mengesan isu yang hanya muncul semasa pemuatan semula panas (hot-reloading).

Kesimpulan

Satu pakej ikon yang diimport secara dinamik boleh menggunakan RAM yang cukup untuk melumpuhkan pelayan pembangunan Next.js berasaskan WSL2, walaupun sumber hos dihadkan dengan sengaja. Dengan mengelakkan import dinamik yang luas, mengaktifkan pengoptimuman import pada peringkat pakej, dan memantau penggunaan memori, pembangun dapat mengekalkan persekitaran Linux-di-dalam-Windows mereka agar tetap responsif dan mengelakkan penutupan paksa.