اترك npm يختار السجل حسب نطاق الحزمة، لا حسب VPN

لا ينبغي أن يعني الاتصال بـ VPN تحرير إعداد السجل في npm مرتين يوميًا. يمكن لإدخال نطاق في ملف إعداد على مستوى المشروع أن يرسل حزم الشركة إلى سجل واحد وكل ما عداه إلى السجل العام، دون تبديل ودون تجاوز يُترك خلفه مساء الجمعة. المشكلة أن هذا يحل التسمية فقط؛ فالتوجيه وبيانات الاعتماد وأولوية الإعداد ثلاثة أمور منفصلة يفشل كل منها بطريقته.

اسمان، وجهتان

اسم حزمة npm إما أن يكون له نطاق أو لا. يبدأ الاسم ذو النطاق بعلامة @ ومعرّف نطاق، وهذا المعرّف هو ما يمكن للإعداد تعيينه. ولا شيء آخر في الحزمة يهم التعيين. لا يرى السجل أبدًا طلبًا بناءً على كون الحزمة داخلية أو عامة؛ إنه يرى اسمًا فقط.

لذا يعبّر الملف أدناه عن نيّتين في ثلاثة أسطر: الحزم العامة تذهب إلى السجل العام، والحزم ضمن نطاق الشركة تذهب إلى سجل الشركة مع رمز مميز لذلك المضيف.

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

استبدل النطاق والمضيف واسم المتغير بما توفره المؤسسة فعليًا. البنية هي المهمة، لا القيم المثالية. سطران من الإعداد يحملان السياسة كاملة، ولهذا يستحقان الفهم بدل النسخ.

أبقِ التعيين والشبكة في حجرتين منفصلتين في ذهنك. لا يستطيع إدخال النطاق أن يجعل مضيفًا غير قابل للوصول قابلًا للوصول، ولا يستطيع نفق عامل أن يخبر npm بأي سجل تنتمي الحزمة.

اكتب الملف بالترتيب الصحيح

ضع ملف المشروع أولًا في تفكيرك حتى لو كان npm يقرأ عدة ملفات. ملف .npmrc في دليل المشروع هو الذي يرثه زملاؤك عبر المستودع، لذا ينبغي أن يعبّر عن السياسة المشتركة لا عن رمزك الشخصي. هذا الملف هو أيضًا ما سيقرأه المراجع. أبقِه صغيرًا بما يكفي لمراجعته بنظرة واحدة.

اترك سطر registry الافتراضي يشير إلى السجل العام ما لم تقرر المؤسسة خلاف ذلك. إزالته تجعل الجهاز يعتمد على ما يقوله ملف مستوى المستخدم، وهذا بالضبط نوع الاعتماد الضمني الذي ينتج نتائج مختلفة على حاسوبين.

سطر النطاق ليس حرف بدل. الاسم خارج النطاق يواصل استخدام الافتراضي، وهذا هو السلوك الذي تريده لكل تبعية لم تكتبها بنفسك.

تحقق مما يحل إليه الملف قبل أن تثبّته، باستخدام اسم حزمة مؤقت بدل تثبيت حقيقي، حتى لا يكلفك الخطأ شيئًا.

بيانات الاعتماد تخص المضيف، لا المشروع

إدخالات المصادقة مرتبطة بمضيف السجل، وبمسار حيث يحتاجه السجل. ولهذا يبدأ سطر الرمز المميز بالشرطة المائلة المزدوجة والمضيف بدل النطاق. بمجرد أن ترى المضيف في ذلك الموضع، يتوقف بقية السطر عن الظهور كترقيم عشوائي. إنه عنوان، والرمز المميز معلّق عليه.

استخدام متغير بيئة يبقي الرمز المميز الحرفي خارج الملف في المستودع. لكنه لا يجعل الرمز غير مرئي في كل مكان؛ فهو يظهر في بيئة العملية، وأمر يطبع الإعداد يمكن أن يكشفه.

وفّر المتغير عبر أي آلية محلية أو آلية لبيانات الاعتماد في CI تعتمدها المؤسسة، ولا تلصق أبدًا رمزًا حقيقيًا في مثال قد يُنسخ إلى الوثائق.

إذا كان هناك سجلان، فلكل واحد إدخاله الخاص. إعداد رمز واحد غير مؤهل يكون غامضًا في أفضل الأحوال ومرسلًا إلى المضيف الخطأ في أسوئها.

عندما يفوز السجل الخاطئ

الإعداد طبقات، والقيمة السارية ليست بالضرورة القيمة الموجودة في الملف الذي حررته للتو. إعدادات المشروع وإعدادات المستخدم والإعدادات العامة ومتغيرات البيئة كلها تشارك. هذه الطبقات هي سبب نجاح إصلاح على جهازك وفشله في حاوية زميل. وهي أيضًا سبب استحقاق القيمة الفعالة للطباعة قبل أن تجادل بشأنها.

متغير البيئة هو المتهم المعتاد في CI، حيث تضبط مهمة السجل مرة وترثه كل خطوة لاحقة. والثاني الأكثر شيوعًا هو ملف على مستوى المستخدم في جهاز مطوّر يتجاوز ما يقوله المستودع.

اطبع الإعداد الفعال والسجل المحلول لاسم واحد بنطاق واسم واحد بلا نطاق قبل تصحيح أي شيء آخر. إذا كانت هاتان الإجابتان ما تتوقعه، فالمشكلة في الشبكة؛ وإذا لم تكونا، فالمشكلة في الإعداد ولن يساعد أي قدر من عمل VPN.

قائمة تحقق قبل التثبيت

تأكد من أن اسم النطاق يطابق الحزم المنشورة فعليًا، وأن السجل الافتراضي صريح، وأن سطر الرمز يذكر المضيف الصحيح. خطأ مطبعي في النطاق ينتج أغرب فشل على الإطلاق، لأن الحزمة تُحل من السجل العام وتعيد وحدة شخص آخر بالاسم نفسه. تحقق من الاسم قبل أن تصحح الرمز.

تأكد من أن السجل الخاص قابل للوصول من الجهاز في السياق الذي يشغّل التثبيت، لا من متصفحك فقط. هذا التمييز مهم عندما يكون لوكيل أو حاوية توجيه مختلف عن طرفيتك.

ثم تأكد من السلوك على نسخة نظيفة بلا حزم مخزنة مؤقتًا. التثبيت الطازج هو الاختبار الوحيد الذي يظهر ما سيعيشه زميل جديد.