Npm застрял на fetchMetadata → network

Ответ 1

Проверьте, есть ли проблемы с прокси-серверами, если вы используете какой-либо. Вы также можете попытаться установить конечную точку npm вручную:

npm config set registry="http://registry.npmjs.org"

Ответ 2

попробуйте yarn установщик вместо npm:

sudo npm install -g yarn
yarn install

Я нашел, что он намного более устойчив к таким проблемам.

Ответ 3

У меня была эта же проблема, с несколькими различными установками, зависающими на fetchMetaData, включая установку yarn, упомянутую выше. Я нахожусь на Mac и решил его, обновив npm следующим образом:

npm install [email protected] -g

Итак, если вы столкнулись с этой проблемой в Mac, попробуйте обновить и посмотреть, разрешает ли она вашу проблему.

Ответ 4

Для меня это были двойные временные каталоги в Windows.

Откройте командную строку и введите:

echo %TEMP%

Вы должны получить путь к одному каталогу. Если вы получаете несколько каталогов (я получил C:\Users\\AppData\Local\Temp; C:\xampp\php), это может быть проблемой. Вы можете исправить это, используя следующую команду:

SET TEMP="<correct path to temporary directory>"

где <correct path to temporary directory> может быть первым путем (до точки с запятой, что означает C:\Users\<user>\AppData\Local\Temp в моем случае).

Ответ 5

У меня такая же проблема. Прежде всего, попробуйте запустить npm install с флагом -verbose. Это поможет вам определить вашу проблему.

Эта команда сообщила мне, что у меня возникла проблема с туннельным сокетом:

Не удалось установить туннельный сокет

причина = написать EPROTO 101057795: ошибка: 140770FC: SSL-процедуры: SSL 23_GET_SERVER_HELLO: неизвестный протокол: openssl\ssl\s23_clnt.c: 794:

После этого я googled ошибка и нашел thread on github об этой проблеме. Проблема была в прокси: ранее я настроил переменную среды HTTP_PROXY и после удаления, после чего переменная окружения npm install выполнена без ошибок.

Ответ 6

Есть много разных вещей, которые могут вызвать эту проблему.

Я перепробовал много вещей, включая большинство ответов, опубликованных здесь, но не повезло.

По какой-то странной причине это была моя проблема с провайдером. Он работал нормально, когда я попробовал другой провайдер.

Ответ 7

Иметь такую ​​же проблему. Исправлено, переключившись на правильную версию node, необходимую для проекта.

Мне нужен проект node >=v4.3 and <=v5.

1) Проверьте версию node, используемую nvm ls

2) Используйте nvm use [version] или установите конкретную версию. если у вас его нет.

Ответ 8

Для большинства людей проблема может быть связана с настройками прокси и может быть решена с помощью вышеупомянутых решений.

Для меня проблема была в другом. У меня есть частные хранилища зависимостей, которые размещены в Bitbucket и разрешаются через "git + ssh://[email protected]/", который использует для SSH SSH для получения репозитория.

По умолчанию SSH предпочитает IPv6, если DNS получает запись AAAA и если она есть на хосте. Поскольку Bitbucket имеет запись AAAA, SSH выполняется через IPv6. Но мой провайдер не поддерживает IPv6 (Вы можете проверить, поддерживает ли ваш провайдер IPv6, пройдя тест на http://ipv6-test.com/).

Чтобы решить эту проблему, вы можете заставить клиента SSH использовать IPv4 вместо IPv6.

Установите AddressFamily inet в /etc/ssh/ssh_config и перезапустите клиент SSH.

В Ubuntu для перезапуска SSH-клиента используйте sudo service ssh restart