بگذارید 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 کمکی نخواهد کرد.

فهرست بررسی پیش از ثبت

تأیید کنید که نام دامنه با بسته‌هایی که واقعاً منتشر شده‌اند مطابقت دارد، رجیستری پیش‌فرض صریح است و خط نشانه میزبان درست را نام می‌برد. یک غلط تایپی در دامنه عجیب‌ترین شکست را ایجاد می‌کند، چون بسته از رجیستری عمومی حل می‌شود و ماژول کس دیگری با همان نام را برمی‌گرداند. پیش از اشکال‌زدایی نشانه، نام را بررسی کنید.

تأیید کنید که رجیستری خصوصی از دستگاه در همان زمینه‌ای که نصب را اجرا می‌کند قابل دسترسی است، نه فقط از مرورگر شما. این تفاوت وقتی مهم است که یک پروکسی یا کانتینر مسیریابی متفاوتی از پوسته شما دارد.

سپس رفتار را روی یک checkout تمیز بدون بسته‌های کش‌شده تأیید کنید. نصب تازه تنها آزمونی است که نشان می‌دهد یک همکار جدید چه تجربه‌ای خواهد داشت.