Калі ўсталяванне npm праходзіць спампоўванне з рэестра і спыняецца ў скрыпце ўсталявання, вызначце другі спампоўшчык. Пакет JavaScript можа ўжо прысутнічаць, а яго бінарны файл для пэўнай платформы яшчэ адсутнічае.

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

Зрабіце гэта перад ачысткай кэша: пераход у журнале ад атрымання пакета да выканання жыццёвага цыкла ўжо звужвае кола няспраўнасці. Паспяховы доступ да рэестра карыснае параўнальнае сведчанне, але ён не даказвае, што другасная праграма падтрымлівае той жа маршрут або можа дасягнуць свайго хоста артэфактаў.

Адключэнне скрыптоў усталявання можа прапусціць спампоўванне і пакінуць пакет непрыдатным. Калі пакет дакументуе зацверджаны шлях усталявання з папярэдне сабранымі файламі або афлайн, падрыхтуйце гэты артэфакт свядома і пераканайцеся, што выканальны файл даступны, перш чым лічыць усталяванне завершаным.

Падобныя артыкулы