Збої проксі npm під час завантаження інсталяційних скриптів

Пакет npm може запускати окреме завантаження під час встановлення. Визначте цю програму та хост, замість того щоб вважати, що кожен запит використовує конфігурацію проксі реєстру npm.

Якщо встановлення npm проходить завантаження з реєстру й зупиняється в інсталяційному скрипті, визначте другий завантажувач. Пакет JavaScript може вже бути присутнім, тоді як його двійковий файл для конкретної платформи ще відсутній.

  1. Знайдіть власника запиту в журналі. Запишіть скрипт життєвого циклу, виконуваний файл або HTTP-бібліотеку, ім'я цільового хоста та першу помилку. Пакет може запускати іншу програму, завантаження якої відокремлене від передавання реєстру npm.
  2. Використовуйте інтерфейс проксі, який підтримує цей завантажувач. Для шляху resources.js у tfjs-node середовище проксі дочірнього процесу є одним конкретним прикладом. Перевірте задокументовані налаштування завантаження пакета та середовище процесу, що виконує запит. Стандартна змінна проксі допомагає лише тоді, коли цей споживач її читає; додавання змінних із подібними назвами не доводить підтримку.
  3. Дотримуйтеся фактичного маршруту артефакту. Сервери випусків, сховища об'єктів і цілі переспрямування можуть відрізнятися від реєстру. Порівняйте автентифікацію проксі, схвалені призначення та довіру TLS для запиту, що не вдався.

Зробіть це перед очищенням кешів: перехід у журналі від отримання пакета до виконання життєвого циклу вже звужує несправність. Успішний доступ до реєстру є корисним порівняльним доказом, але він не доводить, що вторинна програма підтримує той самий маршрут або може досягти свого хоста артефактів.

Вимкнення інсталяційних скриптів може пропустити завантаження й залишити пакет непридатним. Якщо пакет документує схвалений попередньо зібраний або офлайн-шлях встановлення, підготуйте цей артефакт навмисно та підтвердьте, що виконуваний файл доступний, перш ніж вважати встановлення завершеним.

Схожі статті