Нехай npm обирає registry за scope пакета, а не за VPN

Підключення VPN не повинно означати редагування налаштування registry у npm двічі на день. Запис scope у файлі конфігурації на рівні проєкту може надіслати пакети компанії до одного registry, а все інше — до публічного, без перемикання й без override, що залишається на п’ятницю по обіді. Проблема в тому, що це вирішує лише найменування; маршрутизація, облікові дані та пріоритет конфігурації — це три окремі речі, кожна з яких збоює по-своєму.

Два імені, два призначення

Ім’я пакета npm має scope або не має. Ім’я з scope починається зі знака at і ідентифікатора scope, і саме цей ідентифікатор конфігурація може зіставити. Ніщо інше про пакет не має значення для зіставлення. Registry ніколи не бачить запиту, заснованого на тому, чи пакет внутрішній чи публічний; він бачить лише ім’я.

Тож файл нижче виражає два наміри в трьох рядках: публічні пакети йдуть до публічного registry, а пакети під scope компанії — до registry компанії з token для цього host.

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, а не проєкту

Записи автентифікації прив’язані до host registry і, де registry цього потребує, до шляху. Тому рядок token починається з подвійного слеша та host, а не з scope. Коли ви побачите host на цій позиції, решта рядка перестане виглядати як довільна пунктуація. Це адреса, і token прикріплений до неї.

Використання змінної середовища тримає буквальний token поза файлом у repository. Це не робить token невидимим усюди; він усе ще з’являється в середовищі процесу, і команда, що друкує конфігурацію, може його розкрити.

Забезпечте змінну через будь-який локальний або CI механізм облікових даних, який схвалює організація, і ніколи не вставляйте справжній token у приклад, який може бути скопійований у документацію.

Якщо задіяні два registry, кожен отримує власний запис. Єдине некваліфіковане налаштування token у кращому разі неоднозначне, а в гіршому надіслане не тому host.

Коли перемагає неправильний registry

Конфігурація багатошарова, і чинне значення не обов’язково є значенням у файлі, який ви щойно редагували. Налаштування проєкту, користувача, глобальні налаштування та змінні середовища — усі беруть участь. Через це нашарування виправлення працює на вашій машині, але не в контейнері колеги. Також тому чинне значення варто надрукувати, перш ніж сперечатися про нього.

Звичний винуватець у CI — змінна середовища, де завдання один раз задає registry, і кожен наступний крок його успадковує. Другий за поширеністю — файл на рівні користувача на машині розробника, який перекриває те, що каже repository.

Надрукуйте чинну конфігурацію та розв’язаний registry для одного імені з scope і одного без нього, перш ніж налагоджувати будь-що інше. Якщо ці дві відповіді саме такі, як ви очікуєте, проблема в мережі; якщо ні, проблема в конфігурації, і жодна робота з VPN не допоможе.

Контрольний список перед commit

Підтвердьте, що назва scope збігається з фактично опублікованими пакетами, що типовий registry вказано явно і що рядок token називає правильний host. Друкарська помилка в scope дає найдивнішу відмову з усіх, бо пакет розв’язується з публічного registry і повертає чужий module з такою самою назвою. Перевірте назву, перш ніж налагоджувати token.

Підтвердьте, що приватний registry доступний з машини в контексті, який запускає встановлення, а не лише з вашого браузера. Ця різниця важлива, коли proxy або контейнер має іншу маршрутизацію, ніж ваш shell.

Потім підтвердьте поведінку на чистому checkout без кешованих пакетів. Свіже встановлення — єдиний тест, що показує, що відчує новий колега.