Грешки на npm прокси при преземање на скрипти за инсталација

Ако инсталацијата на npm го помине преземањето од регистарот и застане во скрипта за инсталација, идентификувајте го вториот преземач. JavaScript пакетот може веќе да постои, додека неговата бинарна датотека специфична за платформата сè уште недостасува.

1. Најдете го сопственикот на барањето во дневникот. Забележете ја скриптата на животниот циклус, извршната датотека или HTTP библиотеката, името на целниот домаќин и првата грешка. Пакетот може да стартува друга програма чие преземање е одделно од преносот на npm регистарот.
2. Користете го прокси интерфејсот што го поддржува тој преземач. За патеката resources.js на tfjs-node, прокси околината на детскиот процес е еден конкретен пример. Проверете ги документираните поставки за преземање на пакетот и околината на процесот што го прави барањето. Стандардната прокси променлива помага само ако тој потрошувач ја чита; додавањето променливи со слично име не докажува поддршка.
3. Следете ја вистинската патека на артефактот. Серверите за изданија, складиштата за објекти и целите за пренасочување може да се разликуваат од регистарот. Споредете ја прокси автентикацијата, одобрените цели и TLS довербата за барањето што не успеа.

Направете го ова пред да ги исчистите кешовите: преминот во дневникот од добивање на пакетот кон извршување на животниот циклус веќе го стеснува дефектот. Успешниот пристап до регистарот е корисен споредбен доказ, но не докажува дека секундарната програма ја поддржува истата патека или може да го достигне својот домаќин на артефакти.

Оневозможувањето на скриптите за инсталација може да го прескокне преземањето и да го остави пакетот неупотреблив. Ако пакетот документира одобрена однапред изградена или офлајн патека за инсталација, намерно подгответе го тој артефакт и потврдете дека извршната датотека е достапна пред инсталацијата да се смета за завршена.