TypeScript ٹیم نے 6.0 ریلیز میں ایک نیا کمپائل器 فلیگ متعارف کرایا ہے – --noPropertyAccessFromIndexSignature۔ جب اسے فعال کیا جاتا ہے، تو کمپائلر ان پراپرٹیز کے لیے ڈاٹ نوٹیشن (dot-notation) کے ذریعے رسائی سے انکار کر دیتا ہے جو انڈیکس سگنیچر (index signature) سے آتی ہیں، جس سے ڈویلپرز کو بریکٹ نوٹیشن (bracket notation) استعمال کرنے پر مجبور کیا جاتا ہے اور ممکنہ undefined ویلیوز کو پروڈکشن کے بجائے کمپائل ٹائم پر ہی سامنے لایا جاتا ہے۔

یہ فلیگ کیوں اہم ہے

JavaScript میں، آبجیکٹس اکثر ڈکشنریز کے طور پر کام کرتے ہیں، اور TypeScript آپ کو انڈیکس سگنیچر، مثلاً Record<string, T> کے ذریعے ایسی ساختوں کو ٹائپ کرنے کی اجازت دیتا ہے۔ زبان obj.key اور obj["key"] کو ایک دوسرے کے متبادل کے طور پر دیکھتی ہے، اس لیے کمپائلر یہ فرض کر لیتا ہے کہ پراپرٹی موجود ہے، چاہے کی (key) صرف رن ٹائم پر ہی معلوم ہو۔ یہ خاموش مفروضہ بہت سے کریشز (crashes) کا باعث بنتا ہے: وہ کوڈ جو obj.missingProp تک رسائی حاصل کرتا ہے، کمپائل تو ٹھیک ہو جاتا ہے، چلتا بھی ہے، اور پھر کریش ہو جاتا ہے کیونکہ ویلیو undefined ہوتی ہے۔

ڈاٹ نوٹیشن ایک ضمنی ضمانت (implicit guarantee) فراہم کرتی ہے – یہ قارئین اور ٹائپ چیکر کو بتاتی ہے کہ پراپرٹی یقینی طور پر موجود ہے۔ اس کے برعکس، بریکٹ نوٹیشن غیر یقینی صورتحال کا اشارہ دیتی ہے – کی (key) غائب ہو سکتی ہے، اور نتیجہ undefined ہو سکتا ہے۔ --noPropertyAccessFromIndexSignature اس بصری اور مفہومی فرق کو نافذ کرتا ہے، جس سے رن ٹائم کی غلطیوں کے ایک پورے طبقے کو کمپائل ٹائم تشخیص (diagnostics) میں تبدیل کر دیا جاتا ہے۔

یہ فلیگ کیسے کام کرتا ہے

جب فلیگ آن کیا جاتا ہے، تو کوئی بھی ایکسپریشن جو ڈاٹ نوٹیشن کے ذریعے انڈیکس سگنیچر تک رسائی حاصل کرتا ہے، اسے ایرر (error) کے طور پر نشان زد کر دیا جاتا ہے۔ کوڈ کو بریکٹس استعمال کرنے کے لیے دوبارہ لکھنا ہوگا۔

// Before
const name = userData.name;          // OK even if "name" is not in the index

// After enabling the flag
const name = userData["name"];       // Error unless brackets are used

کمپائلر پھر وہی undefined-ہینڈلنگ رولز لاگو کرتا ہے جو وہ پہلے سے بریکٹ ایکسیس کے لیے استعمال کرتا ہے۔ اگر --noUncheckedIndexedAccess بھی فعال ہے، تو userData["name"] کی ٹائپ T | undefined ہو جاتی ہے، جس سے ڈویلپر کو غائب ہونے والے کیس کو چیک کرنے پر مجبور کیا جاتا ہے۔

عملی مائیگریشن اقدامات

  1. فلیگ کو فعال کریں tsconfig.json میں:

    {
  "compilerOptions": {
    "noPropertyAccessFromIndexSignature": true
  }
}

  2. ٹائپ چیکر چلائیں۔ انڈیکس-سگنیچر کیز تک تمام ڈاٹ نوٹیشن ایکسیس ایررز کے طور پر ظاہر ہوں گے۔

  3. ڈاٹس کو بریکٹس سے بدلیں۔ یہ تبدیلی میکانکی ہے؛ اس کا رن ٹائم پرفارمنس پر کوئی اثر نہیں پڑتا۔

  4. نتیجے میں بننے والی undefined ٹائپس کو حل کریں۔ جہاں ضرورت ہو وہاں nullish coalescing، optional chaining، یا واضح چیک (explicit checks) شامل کریں۔

  5. مضبوط ترین حفاظتی جال (safety net) کے لیے اسے --noUncheckedIndexedAccess کے ساتھ جوڑنے پر غور کریں۔ یہ دونوں مل کر اس بات کو یقینی بناتے ہیں کہ ڈکشنری اسٹائل کی کسی بھی رسائی کو ممکنہ طور پر غیر موجود سمجھا جائے۔

واضح پراپرٹیز (Explicit Properties) کب رکھیں

اگر کوئی فیلڈ ایک مستحکم API کنٹریکٹ کا حصہ ہے، تو انڈیکس سگنیچر پر انحصار کرنے کے بجائے اسے ایک واضح پراپرٹی کے طور پر ڈکلیئر کریں۔ واضح پراپرٹیز ڈاٹ نوٹیشن کی اجازت دیتی رہتی ہیں، اور اس ضمانت کو برقرار رکھتی ہیں کہ فیلڈ ہمیشہ موجود ہوگی (جہاں تک ٹائپ سسٹم کی تصدیق ہے)۔ انڈیکس سگنیچرز کو صرف حقیقی طور پر ڈائنامک ڈیٹا کے لیے مخصوص رکھیں جہاں کیز پہلے سے معلوم نہ ہوں۔

ایک دوسرا پہلو: اضافت (Verbosity)

کچھ ٹیموں کو اضافی بریکٹس کا استعمال شور (noisy) محسوس ہو سکتا ہے، خاص طور پر ان کوڈ بیسز میں جو لچکدار آبجیکٹس کا کثرت سے استعمال کرتے ہیں۔ یہ فلیگ ایک سخت نظم و ضبط کا مطالبہ کرتا ہے جس کے لیے پرانے (legacy) پروجیکٹس میں بڑے پیمانے پر ریفیکٹرنگ (refactor) کی ضرورت پڑ سکتی ہے۔ ایسے کیسز میں، فلیگ کو بتدریج متعارف کرایا جا سکتا ہے، شاید صرف نئے ماڈیولز تک محدود رکھا جائے، جبکہ وسیع تر کوڈ بیس وقت کے ساتھ اس پیٹرن کو اپنا لے۔

آگے کیا نظر آئے گا

یہ فلیگ TypeScript 6.0 میں ٹائپ سیفٹی (type safety) کو مزید سخت بنانے کی ایک وسیع کوشش کا حصہ ہے۔ مستقبل کی ریلیزز میں آبجیکٹ اسپریڈ (object spread)، آپشنل چیننگ، یا انفرڈ any کے استعمال کے گرد مزید چیک متعارف کرائے جا سکتے ہیں۔ TypeScript روڈ میپ پر نظر رکھنا ٹیموں کو یہ فیصلہ کرنے میں مدد دے گا کہ ڈیلیوری شیڈول کو متاثر کیے بغیر سیفٹی فیچرز کا اگلا سیٹ کب اپنایا جائے۔

خلاصہ: --noPropertyAccessFromIndexSignature کو فعال کرنے سے کوڈ میں "یہ پراپرٹی یقینی ہے" اور "یہ پراپرٹی غائب ہو سکتی ہے" کے درمیان فرق واضح ہو جاتا ہے، جس سے بگ (bug) کا ایک پورا طبقہ پروڈکشن تک پہنچنے سے پہلے ہی پکڑا جاتا ہے۔ ایک خاموش رن ٹائم فیل्यर کو کمپائل ٹائم ایرر میں تبدیل کرنا ایک چھوٹا سا بدلاؤ ہے جس کا بھروسہ مندی (reliability) پر غیر متناسب اثر پڑتا ہے۔