2016-12-06 3 views
0

Я разрабатываю веб-приложение Webpack, TypeScript и Angular 1.5.x, которое использует NPM для управления зависимостями. Приложение имеет около 3 дюжин зависимостей и аналогичное количество devDependencies, перечисленных в package.json. Многие из зависимостей являются внутренне разработанными пакетами NPM, размещенными на Artifactory.npm install имеет десятки версий одного и того же пакета в node_modules/.staging

npm install is very slow on Jenkins (иногда в течение 1 часа). Я заметил следующее:

Во время npm install a .staging каталог создан под node_modules. Здесь имеется около десятка различных версий одной и той же зависимой ссылки. Я предполагаю, что каждая из наших зависимостей указывает несколько разные версии этих зависимостей, а NPM загружает все из них для их разрешения. Например

$ ls -al node_modules/.staging/webpack-* 

webpack-02c2cd2d/ webpack-core-0e45f015/ webpack-dev-middleware-1b9e08da/  
# ...many more versions of webpack, wepack-core, webpack-dev-middleware 

Сам каталог .staging содержит тысячи каталогов:

$ ls -al node_modules/.staging/ | wc -l 
19406 

Мои вопросы заключаются в следующем:

  1. Что такое .staging каталог? Что с ней делает? Этот вопрос был asked as an issue on Github, но не отвечал должным образом.
  2. Почему npm install так медленно? Почему он загружает так много разных версий каждой зависимости?
  3. Что я могу сделать с медленностью и очевидными дублирующими загрузками? (Кроме предложенного решения по данному вопросу Github т.е. увеличение свопа)

ответ

0

Вот что происходит:

Наши внутренние пакеты были Shrinkwrapped. Файл npm-shrinkwrap.json для каждого пакета был сгенерирован с помощью флага --dev. Это означает, что зависимости развития также сокращаются.

Есть два возможных решения для этого:

  1. Не генерировать Shrinkwrap JSON с --dev флагом
  2. Run npm install --only=prod. Это должно пропустить установку devDependencies, за this answer
Смежные вопросы