ایک ہی ڈائنامک آئیکن امپورٹ نے 16 GB Windows Subsystem for Linux 2 (WSL2) مشین پر ڈویلپمنٹ سرور کو مکمل طور پر تباہ کر دیا، جس کی وجہ سے vmmemWSL پروسیس نے تمام دستیاب میموری استعمال کر لی اور پورے Linux ونڈو کو فریز کر دیا۔ یہ کریش Next.js 16 پروجیکٹ چلاتے وقت ہوا جو Turbopack استعمال کرتا ہے، اور یہ اس کے باوجود ہوا جب کہ .wslconfig فائل کے ذریعے VM کے RAM استعمال کو محدود کیا گیا تھا۔

ایک چھوٹا سا امپورٹ ایک عفریت کیوں بن سکتا ہے

ڈویلپر نے ڈائنامک انٹری پوائنٹ کے ذریعے رن ٹائم پر آئیکنز کو ریزولیو (resolve) کرنے کی کوشش کی۔ اس امپورٹ نے ایک ایسا آئیکن پیکیج لوڈ کیا جس میں تقریباً 9,000 ماڈیولز شامل تھے۔ Turbopack، جو کہ Rust پر مبنی بنڈلر ہے اور Next.js 16 کے ڈویلپمنٹ سرور کو طاقت فراہم کرتا ہے، ہر اس پیکیج کے لیے ایک مکمل ماڈیول میپ (module map) بناتا ہے جسے وہ چھوتا ہے۔ ڈویلپمنٹ موڈ میں یہ میپ میموری میں رہتا ہے اور ہر فائل کی تبدیلی پر اپ ڈیٹ ہوتا ہے۔ پورے آئیکن پیکیج کو لوڈ کرنے سے Turbopack پر بہت زیادہ RAM مختص کرنے کا دباؤ پڑا، جس سے .wslconfig فائل میں مقرر کردہ حد (hard ceiling) تیزی سے ختم ہو گئی۔ جیسے ہی حد ختم ہوئی، WSL VM نے جواب دینا بند کر دیا؛ Ctrl + C نے کوئی کام نہیں کیا اور واحد راستہ ونڈوز ہوسٹ کو زبردستی بند (forced shutdown) کرنا تھا۔

اسی کوڈ کی پروڈکشن بلڈ (production build) کامیاب رہی کیونکہ بنڈلر گراف کو ایک بار کمپائل کرتا ہے، اثاثے (assets) جاری کرتا ہے، اور ختم ہو جاتا ہے۔ تاہم، ڈویلپمنٹ سرور ہاٹ ری لوڈنگ (hot-reloading) کو ممکن بنانے کے لیے گراف کو میموری میں برقرار رکھتا ہے۔ اس لیے ایک کامیاب پروڈکشن بلڈ اس بات کی ضمانت نہیں دیتا کہ ڈویلپمنٹ ماحول اسی امپورٹ پیٹرن کو برداشت کر سکے گا۔

وسیع تر اثرات

ونڈوز کے اندر Linux پر مبنی ٹول چینز پر کام کرنے والے ڈویلپرز وسائل کے استعمال کو الگ کرنے کے لیے WSL2 پر بھروسہ کرتے ہیں۔ جب ایک ہی امپورٹ VM کی میموری کو ختم کر دیتا ہے، تو پورا ہوسٹ سست یا غیر فعال ہو سکتا ہے، جس سے اسی مشین پر موجود دیگر کنٹینرز یا ایپلی کیشنز متاثر ہو سکتی ہیں۔ یہ واقعہ عام Node.js میموری ٹیوننگ فلیگز اور Turbopack کے آرکیٹیکچر کے درمیان عدم مطابقت کو بھی اجاگر کرتا ہے: Turbopack Rust میں چلتا ہے، V8 میں نہیں، اس لیے Node --max-old-space-size فلیگ کو بڑھانے سے اس کے RAM کے استعمال کو روکنے میں کوئی مدد نہیں ملتی۔

اصل میں کیا غلط ہوا

  • ڈائنامک انٹری پوائنٹ: امپورٹ اسٹیٹمنٹ نے بنڈلر سے کہا کہ وہ پورے آئیکن پیکیج کو ایک ہی، lazily-loaded ماڈیول کے طور پر سمجھے۔ Turbopack نے ماڈیول میپ بنانے کے لیے ہر فائل کو تیزی سے (eagerly) پارس کر کے جواب دیا۔
  • ڈویلپمنٹ سرور گراف: ایک بار کے پروڈکشن کمپائل کے برعکس، ڈویلپمنٹ سرور فائل کی تبدیلیوں پر فوری فیڈ بیک فراہم کرنے کے لیے مکمل ڈیپینڈینسی گراف کو RAM میں برقرار رکھتا ہے۔
  • میموری کی حد (Memory cap): .wslconfig فائل نے VM کو ہوسٹ کی RAM کے ایک چھوٹے سے حصے تک محدود کر دیا تھا۔ جب Turbopack کی طلب اس حد سے تجاوز کر گئی، تو VM فریز ہو گیا۔

حل جس نے میموری کو نصف کر دیا

ڈویلپر نے تین عملی تبدیلیاں کیں جنہوں نے RAM کے استعمال کو 3.6 GB سے کم کر کے 1.87 GB کر دیا اور استحکام بحال کر دیا:

  1. چھوٹے اثاثوں (assets) کے لیے ڈائنامک انٹری پوائنٹس کا استعمال بند کریں – صرف وہی آئیکنز امپورٹ کریں جن کی آپ کو ضرورت ہے، مثلاً import { SearchIcon } from 'icon-pack/search'۔ اگر آپ کو صرف چند آئیکنز چاہیے ہوں، تو ان لائن (inline) SVGs اس سے بھی ہلکے ہوتے ہیں۔
  2. next.config.ts میں optimizePackageImports کو فعال کریں – یہ آپشن Turbopack کو بتاتا ہے کہ امپورٹس کو پیکیج روٹ کے بجائے ان کے مخصوص فائل پاتھ (file paths) پر ریزولیو کرے، جس سے اسے پورا پیکیج ٹری لوڈ کرنے سے روکا جا سکتا ہے۔
  3. Node heap فلیگز پر بھروسہ نہ کریں – چونکہ Turbopack کا میموری استعمال اس کے Rust runtime کے ذریعے کنٹرول ہوتا ہے، اس لیے --max-old-space-size کا اس مسئلے پر کوئی اثر نہیں پڑتا۔

.wslconfig کی حدود کو برقرار رکھنا اب بھی مشورہ دیا جاتا ہے۔ ایک سخت حد (hard cap) کی وجہ سے ونڈوز ہوسٹ کے کریش ہونے کے بجائے VM رک سکتا ہے، جس سے آپ کو سب کچھ رکنے سے پہلے مداخلت کرنے کا موقع ملتا ہے۔

اپنے ورک فلو میں کن چیزوں پر نظر رکھیں

  • میموری ڈیش بورڈز: WSL کے اندر htop جیسے ٹولز یا Windows Task Manager یہ بتا سکتے ہیں کہ کب vmmemWSL میں اچانک اضافہ ہوتا ہے۔ اگر استعمال آپ کی مقرر کردہ حد کے قریب پہنچ جائے تو الرٹس سیٹ کریں۔
  • پیکیج سائز کا آڈٹ: کوئی بھی لائبریری شامل کرنے سے پہلے چیک کریں کہ اس میں کتنے ماڈیولز شامل ہیں۔ بڑے آئیکن پیکس، یوٹیلیٹی کلیکشنز، یا کمپوننٹ لائبریریز خاموشی سے ڈویلپمنٹ گراف کو بڑھا سکتی ہیں۔
  • منتخب امپورٹس (Selective imports): وائلڈ کارڈ (wildcard) یا ڈائنامک امپورٹس کے بجائے نامزد امپورٹس (named imports) یا براہ راست فائل پاتھ کو ترجیح دیں، خاص طور پر ڈویلپمنٹ ماحول میں جہاں بنڈلر ہر چیز کو میموری میں رکھتا ہے۔
  • پروڈکشن بمقابلہ ڈویلپمنٹ برابری: ایک کامیاب پروڈکشن بلڈ کو علیحدہ ویلیڈیشن مرحلے کے طور پر لیں۔ ہاٹ ری لوڈنگ کے دوران ظاہر ہونے والے مسائل کو پکڑنے کے لیے میموری مانیٹر کے ساتھ ڈویلپمنٹ سرور چلائیں۔

خلاصہ

ایک ہی ڈائنامک امپورٹ شدہ آئیکن پیکیج اتنی زیادہ RAM استعمال کر سکتا ہے کہ وہ WSL2 پر مبنی Next.js ڈویلپمنٹ سرور کو مفلوج کر دے، چاہے ہوسٹ کے وسائل جان بوجھ کر محدود ہی کیوں نہ کیے گئے ہوں۔ وسیع ڈائنامک امپورٹس سے بچ کر، پیکیج لیول امپورٹ آپٹیمائزیشن کو فعال کر کے، اور میموری کے استعمال کی نگرانی کر کے، ڈویلپرز اپنے ونڈوز کے اندر چلنے والے Linux ماحول کو مستحکم رکھ سکتے ہیں اور زبردستی بند ہونے (forced shutdowns) سے بچ سکتے ہیں۔