VPN نہیں، پیکیج کے scope کی بنیاد پر npm کو registry چننے دیں

VPN جوڑنے کا مطلب یہ نہیں ہونا چاہیے کہ دن میں دو بار npm کی registry سیٹنگ میں ترمیم کریں۔ پروجیکٹ سطح کی کنفیگریشن فائل میں ایک scope اندراج کمپنی کے پیکیجز کو ایک registry پر اور باقی سب کچھ عوامی registry پر بھیج سکتا ہے، بغیر سوئچ کیے اور بغیر ایسے override کے جو جمعہ کی دوپہر کے لیے رہ جائے۔ اصل مسئلہ یہ ہے کہ یہ صرف نام رکھنے کا حل ہے؛ روٹنگ، اسناد اور کنفیگریشن کی ترجیح تین الگ الگ چیزیں ہیں جو ہر ایک اپنے طریقے سے ناکام ہوتی ہے۔

دو نام، دو منزلیں

npm پیکیج کے نام میں یا scope ہوتا ہے یا نہیں۔ scope والا نام at نشان اور scope شناخت کنندہ سے شروع ہوتا ہے، اور کنفیگریشن اسی شناخت کنندہ کا نقشہ بنا سکتی ہے۔ نقشہ سازی کے لیے پیکیج کے بارے میں کوئی اور چیز اہم نہیں۔ registry کبھی ایسی درخواست نہیں دیکھتا جو اس بات پر مبنی ہو کہ پیکیج اندرونی ہے یا عوامی؛ وہ صرف ایک نام دیکھتا ہے۔

چنانچہ نیچے دی گئی فائل تین سطروں میں دو ارادے ظاہر کرتی ہے: عوامی پیکیجز عوامی registry پر جاتے ہیں، اور کمپنی کے scope کے تحت پیکیجز اس host کے لیے token کے ساتھ کمپنی کی registry پر جاتے ہیں۔

registry=https://registry.npmjs.org/
@acme:registry=https://packages.corp.example/
//packages.corp.example/:_authToken=${NPM_TOKEN}

scope، host اور متغیر کا نام اس چیز سے بدلیں جو تنظیم واقعی فراہم کرتی ہے۔ اہم چیز ساخت ہے، مثال کی قدریں نہیں۔ کنفیگریشن کی دو سطریں پوری پالیسی اٹھاتی ہیں، اسی لیے انہیں نقل کرنے کے بجائے سمجھنا قابل قدر ہے۔

نقشہ سازی اور نیٹ ورک کو ذہن میں الگ خانے رکھیں۔ ایک scope اندراج ناقابل رسائی host کو قابل رسائی نہیں بنا سکتا، اور کام کرنے والا tunnel npm کو یہ نہیں بتا سکتا کہ پیکیج کس registry کا ہے۔

فائل کو درست ترتیب میں لکھیں

npm کئی فائلیں پڑھتا ہے پھر بھی اپنی سوچ میں پروجیکٹ فائل کو پہلے رکھیں۔ پروجیکٹ ڈائریکٹری میں .npmrc وہی ہے جو آپ کے ساتھی repository کے ذریعے ورثے میں پاتے ہیں، اس لیے اسے مشترکہ پالیسی ظاہر کرنی چاہیے نہ کہ آپ کا ذاتی token۔ وہی فائل ایک جائزہ لینے والا بھی پڑھے گا۔ اسے اتنے چھوٹے رکھیں کہ ایک نظر میں جائزہ لیا جا سکے۔

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

scope سطر وائلڈ کارڈ نہیں ہے۔ scope سے باہر کا نام طے شدہ قدر استعمال کرتا رہتا ہے، اور یہی وہ رویہ ہے جو آپ ہر اس انحصار کے لیے چاہتے ہیں جو آپ نے خود نہیں لکھا۔

commit کرنے سے پہلے دیکھیں کہ فائل کیا حل کرتی ہے، اصل انسٹال کے بجائے ایک عارضی پیکیج نام استعمال کرتے ہوئے، تاکہ کوئی غلطی کچھ مہنگی نہ پڑے۔

اسناد کسی پروجیکٹ کی نہیں، کسی host کی ہوتی ہیں

تصدیق کے اندراجات registry host سے منسلک ہوتے ہیں اور، جہاں registry کو ضرورت ہو، کسی راستے سے بھی۔ اسی لیے token کی سطر scope کے بجائے دوہرے slash اور host سے شروع ہوتی ہے۔ جب آپ اس مقام پر host دیکھ لیں تو سطر کا باقی حصہ بے ترتیب رموزِ اوقاف جیسا نہیں لگتا۔ یہ ایک پتہ ہے، اور token اسی سے منسلک ہے۔

ماحولیاتی متغیر استعمال کرنا حقیقی token کو repository کی فائل سے باہر رکھتا ہے۔ یہ token کو ہر جگہ پوشیدہ نہیں کرتا؛ یہ پھر بھی عمل کے ماحول میں ظاہر ہوتا ہے، اور کنفیگریشن چھاپنے والا کوئی حکم اسے ظاہر کر سکتا ہے۔

متغیر کو کسی بھی مقامی یا CI اسناد کے طریقے سے فراہم کریں جسے تنظیم منظور کرتی ہو، اور کبھی کوئی حقیقی token ایسی مثال میں نہ چسپاں کریں جو دستاویزات میں نقل ہو سکے۔

اگر دو registry زیرِ عمل ہوں تو ہر ایک کو اپنا اندراج ملتا ہے۔ واحد غیر موزوں token سیٹنگ بہترین صورت میں مبہم ہے اور بدترین صورت میں غلط host کو بھیجی جاتی ہے۔

جب غلط registry جیت جائے

کنفیگریشن تہوں پر مشتمل ہے، اور نافذ قدر ضروری نہیں کہ اسی فائل کی قدر ہو جسے آپ نے ابھی تبدیل کیا۔ پروجیکٹ سیٹنگز، صارف سیٹنگز، عالمی سیٹنگز اور ماحولیاتی متغیرات سب شریک ہوتے ہیں۔ اسی تہہ بندی کی وجہ سے کوئی اصلاح آپ کی مشین پر کام کرتی ہے اور ساتھی کے container میں نہیں۔ اسی لیے اس پر بحث کرنے سے پہلے نافذ قدر چھاپنا قابل قدر ہے۔

CI میں عام مجرم ماحولیاتی متغیر ہے، جہاں ایک job ایک بار registry مقرر کرتا ہے اور ہر بعد کا مرحلہ اسے ورثے میں پاتا ہے۔ دوسرا سب سے عام سبب ڈویلپر کی مشین پر صارف سطح کی فائل ہے جو repository کی بات کو منسوخ کرتی ہے۔

کسی اور چیز کو ڈی بگ کرنے سے پہلے ایک scope والے نام اور ایک بغیر scope والے نام کے لیے نافذ کنفیگریشن اور حل شدہ registry چھاپیں۔ اگر وہ دونوں جواب وہی ہیں جن کی آپ توقع کرتے ہیں تو مسئلہ نیٹ ورک ہے؛ اگر نہیں تو مسئلہ کنفیگریشن ہے اور VPN پر کتنا بھی کام کرنے سے مدد نہیں ملے گی۔

commit سے پہلے چیک لسٹ

تصدیق کریں کہ scope کا نام واقعی شائع شدہ پیکیجز سے میل کھاتا ہے، طے شدہ registry واضح ہے، اور token کی سطر درست host بتاتی ہے۔ scope میں ایک ٹائپو سب سے عجیب ناکامی پیدا کرتا ہے، کیونکہ پیکیج عوامی registry سے حل ہوتا ہے اور اسی نام کے ساتھ کسی اور کا module واپس کرتا ہے۔ token ڈی بگ کرنے سے پہلے نام جانچیں۔

تصدیق کریں کہ نجی registry مشین سے اس سیاق میں قابل رسائی ہے جو انسٹال چلاتا ہے، نہ کہ صرف آپ کے براؤزر سے۔ یہ فرق اس وقت اہم ہے جب proxy یا container کی روٹنگ آپ کے shell سے مختلف ہو۔

پھر بغیر کیش شدہ پیکیجز کے صاف checkout پر رویہ تصدیق کریں۔ تازہ انسٹال واحد آزمائش ہے جو دکھاتی ہے کہ نیا ساتھی کیا تجربہ کرے گا۔