Нека 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 няма да помогне.

Контролен списък преди ангажиране

Потвърдете, че името на обхвата съвпада с действително публикуваните пакети, че регистърът по подразбиране е изричен и че редът за токена посочва правилния хост. Печатна грешка в обхвата дава най-странния провал от всички, защото пакетът се разрешава от публичния регистър и връща чужд модул със същото име. Проверете името, преди да отстранявате проблема с токена.

Потвърдете, че частният регистър е достъпен от машината в контекста, който изпълнява инсталацията, а не само от браузъра ви. Това разграничение е важно, когато прокси или контейнер има различно маршрутизиране от вашата обвивка.

След това потвърдете поведението при чисто изтегляне без кеширани пакети. Прясната инсталация е единственият тест, който показва какво ще изживее нов колега.