Чаму npm па-ранейшаму мае проксі пасля выдалення
npm чытае некалькі крыніц канфігурацыі. Выдаленне запісу з аднаго файла або пераўсталяванне Node можа пакінуць іншую крыніцу дзейнай.
Вы выдаляеце проксі npm, запытваеце яго зноў, а значэнне ўсё яшчэ там. Перш чым паўтарыць каманду з большымі прывілеямі, праверце, якую канфігурацыю вы выдалілі.
Праектны .npmrc, карыстальніцкі файл, глабальная канфігурацыя, параметры каманды і налады асяроддзя — усё гэта можа мець значэнне. Выдаленне значэння з аднаго месца можа выявіць іншае значэнне пад ім.
Знайдзіце значэнне перад змяненнем
Агледзьце фактычную канфігурацыю npm і файлы, датычныя гэтага выкліку. Звярніце ўвагу, ці аперацыя лакальная для праекта ці глабальная. Праектная налада не з'яўляецца доказам пра глабальную ўстаноўку.
Назвы параметраў проксі таксама маюць значэнне. Уласны ключ, падобны да http_proxy, не з'яўляецца аўтаматычна дакументаваным параметрам proxy. Напісанне зменных асяроддзя і напісанне ключоў канфігурацыі npm — гэта асобныя інтэрфейсы.
Пераўсталяванне выканальнага файла ні да чаго не датычыць
Каталог устаноўкі Node не абавязкова той, дзе жыве ваша карыстальніцкая канфігурацыя. Замена выканальнага файла можа пакінуць карыстальніцкі файл і асяроддзе працэсу нязменнымі. Таму чыстая ўстаноўка праграмы можа адразу паказаць старую сеткавую канчатковую кропку.
Калі вы знойдзеце крыніцу, выдаліце састарэлы запіс на гэтым узроўні. Затым зноў запытайце фактычнае значэнне з таго ж працоўнага каталога і ўліковага запісу, якія выклікалі збой. Пазбягайце задання адвольнага пустога або падобнага да null радка, калі ўсталяваны npm не дакументуе гэта значэнне.
Трымайце наладу registry асобна. Лакальны URL registry можа выглядаць як адрас проксі, але яго выдаленне змяняе месца запыту метаданых пакетаў. Не выдаляйце неабходны ўнутраны registry толькі дзеля выдалення непажаданага проксі-перасылальніка.