У меня связывание зависимостей занимает 200+ секунд с этим https://github.com/macdja38/pvpsite/blob/master/package.json в Windows 10, с SSD с приличным i7.

Похоже, что проблема с производительностью может быть вызвана Защитником Windows, отключив его, хотя, возможно, и нецелесообразно, уменьшил 200 секунд до примерно 50.

Я думаю, что должно быть лучшее решение, чем снижение безопасности.

Некоторые другие пользователи подтвердили, что отключение его только в корневом каталоге вашего проекта работает, но я не могу подтвердить, поскольку Защитник Windows немного сломался, когда я попытался это сделать.

У меня то же самое с проблемой с репозиторием git примерно с 30 зависимостями.
Windows 10
узел v5.5.0
пряжа 0.16.1

Отключение Защитника Windows значительно сократило время связывания

Наверное, надо этим пиаром «решить»?

Да, к сожалению, здесь мы мало что можем сделать: (Сканеры вирусов сканируют все файлы, а в экосистеме npm много мелких файлов. Маленькие файлы обычно имеют немного больше накладных расходов на NTFS по сравнению с другими файловыми системами, такими как EXT4 или ZFS, но это усугубляется антивирусными сканерами.

При этом Yarn по-прежнему должен быть быстрее, чем npm, просто он не будет таким быстрым, как на Linux или Mac.

Я работаю на Mac без установленных антивирусных сканеров. Но я все еще вижу ту же проблему: связывание занимает много времени даже с простым приложением angular-js.

У меня тоже есть эта проблема. На Ubuntu потребовалось 174 секунды.

У меня возникла эта проблема только после того, как я обновился с 0.17.8 до 0.17.19 . Mac без антивируса.

Странно и то, что мне нужно запускать процесс связывания каждый раз, когда я удаляю пакет. Npm делает это быстрее. А связывание действительно занимает много времени.

Это можно воспроизвести с помощью этого package.json (на Heroku):

{
  "name": "yarn-link-slowness",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "axios": "^0.15.3",
    "lodash": "^4.17.2",
    "react": "^15.4.1",
    "react-dom": "^15.4.1",
    "react-player": "^0.12.1",
    "react-redux": "^4.4.6",
    "react-router": "^3.0.0",
    "react-router-redux": "^4.0.7",
    "react-scripts": "^0.8.4",
    "redux": "^3.6.0",
    "redux-auth-wrapper": "^0.9.0",
    "redux-logger": "^2.7.4",
    "redux-promise-middleware": "^4.2.0",
    "redux-thunk": "^2.1.0"
  },
  "engines": {
    "node": "7.2.1",
    "yarn": "0.17.8"
  }
}

Для пряжи 0.17.8 установка занимает 37 секунд. Для пряжи 0.17.10 установка занимает 97 секунд. Никаких других изменений (каждый раз новые приложения Heroku).

✨ Совершено за 45.10 сек.

    "autoprefixer": "6.3.6",
    "babel-core": "6.7.6",
    "babel-jest": "13.0.0",
    "babel-loader": "6.2.4",
    "babel-plugin-transform-class-properties": "6.9.1",
    "babel-plugin-transform-object-rest-spread": "6.8.0",
    "babel-preset-es2015": "6.6.0",
    "babel-preset-react": "6.5.0",
    "bluebird": "3.3.5",
    "cardmask": "github:aj0strow/cardmask#v1.0.0",
    "chai": "3.5.0",
    "classnames": "2.2.5",
    "copy-webpack-plugin": "2.1.3",
    "core-js": "2.4.1",
    "css-loader": "0.23.1",
    "enzyme": "2.3.0",
    "file-loader": "0.8.5",
    "force-case-sensitivity-webpack-plugin": "0.1.1",
    "jest": "13.0.0",
    "jest-cli": "13.0.0",
    "json-loader": "0.5.4",
    "lodash": "4.11.1",
    "moment": "2.13.0",
    "ms": "0.7.1",
    "node-sass": "3.4.2",
    "postcss-loader": "0.9.1",
    "raw-loader": "0.5.1",
    "react": "15.2.0",
    "react-addons-css-transition-group": "15.2.0",
    "react-addons-test-utils": "15.2.0",
    "react-css-transition-replace": "2.0.1",
    "react-dom": "15.0.1",
    "react-redux": "4.4.5",
    "react-router": "2.3.0",
    "react-textarea-autosize": "4.0.3",
    "recompose": "0.20.2",
    "redux": "3.5.1",
    "redux-actions": "0.10.0",
    "redux-thunk": "2.0.1",
    "reselect": "2.5.3",
    "sass-loader": "3.2.0",
    "sinon": "1.17.4",
    "style-loader": "0.13.1",
    "webpack": "1.13.0",
    "webpack-dev-server": "1.14.1",
    "whatwg-fetch": "1.0.0",
    "zxcvbn": "4.3.0"

Пожалуйста, кто-нибудь может объяснить, что именно делает yarn на этапе «Связывание зависимостей»?
Поскольку максимальное количество на этом шаге варьируется от ~ 1000 до ~ 65000 для одного и того же проекта на разных машинах. Что означает это число?

Имея и эту проблему. Добавление зависимости с помощью yarn add похоже, запускает «Связывание зависимостей», и это занимает вечность. Пришлось пока вернуться к npm.

узел: 6.9.2
ОС: Windows 10

узел: 7.3.0
ОС: Windows 10 64
Мне то же

Тоже самое. Ссылки 23420 ... что-то, а в хороший день занимает около полутора минут.

Пряжа 0.19.1
NodeJS 7.3.0
Windows 10

yarn add moment занимает 105 секунд. Никаких зависимостей. : /

РЕДАКТИРОВАТЬ: отключение Защитника Windows сокращает время до ~ 30-50 секунд. Я попытался исключить каталог, в котором работаю, но это не помогло.

Просто запустил новую копию create-react-app, и это заняло 876,37 с. Я понимаю, что у вас нет особого / какого-либо контроля над работой антивируса, но мой опыт работы с NPM и CRA был намного быстрее в Windows.

В Windows 10 просто используйте оболочку Ubuntu bash в качестве общего совета.

В Windows 10 просто используйте оболочку Ubuntu bash в качестве общего совета.

Дисковый ввод-вывод в подсистеме Windows для Linux очень медленный, на данный момент это известное ограничение.

но мой опыт работы с NPM и CRA был намного быстрее в Windows.

@JeffBaumgardt - Интересно ... Yarn работает медленнее в Windows, но все равно должен быть быстрее, чем npm!

@ Daniel15, наверное, и должно быть, но это не так. Установка и удаление узлов были для меня меньше. Поэтому я бы сделал npm add <packages> --save-dev , удалил yarn.lock и запустил yarn, и это было бы быстрее, чем запускать yarn add <packages> -D за один раз. Теперь, когда все в курсе, я, конечно же, не хочу удалять блокировку и заставлять всех обновлять свой пакет. Вместо этого было замечательно следующее:

cc @echobnet

Для всех на windows 10 + windows defender

1. Настройки первого клика

   

2. Прокрутите вниз до исключений

   

3. Запустите yarn cache dir чтобы получить местоположение вашей папки кеша

   • Добавьте эту папку кеша в список исключений
   • Добавьте папку вашего проекта node_modules в список исключений

4. Ускорение для проекта React x 3-10

@SleeplessByte или вы можете просто добавить yarn и node в исключенные процессы.

Проблема не только в окнах. Я видел ужасное время соединения на моем Mac Pro.

ОС: OS X 10.11.6 (El Capitan)
Узел: 7.6.0
Пряжа: 0.20.3

Я могу подтвердить, что и на Mac 10.12.3 он очень медленно работает. Не относится к окнам.

И похоже, что моя настройка _way_ медленнее, чем у других в этом потоке. yarn иногда пытается связать около 600 000 файлов в небольших проектах. Это может занять более 30 минут. Сейчас пробую с чистым кешем и ночным (v0.22.0-20170226.1626). Я использую официальный реестр, а также индивидуальный частный реестр для определенных пакетов с ограниченной областью действия. Однако мои коллеги не страдают от этой проблемы, поэтому я не думаю, что проблема заключается в настраиваемом частном реестре (и получение пакетов в любом случае уже завершено). У нас также есть несколько относительных файлов с протоколом path: в нашем package.json .

У меня много проблем с установкой https://github.com/google/material-design-icons, в котором _ много маленьких файлов_, которые, похоже, тоже доставляют хлопот другим людям (https://github.com/google/ материалы-дизайн-иконки / вопросы / 518). Я не знаю, сломано ли мое оборудование при обработке большого количества небольших файлов или что-то в этом роде, или это вообще связано. Опять же, у моих коллег не так много проблем с установкой https://github.com/google/material-design-icons, как у меня.

Обновить

Я не уверен ... это похоже на установку пакета с file: помещает в кеш модуль, содержащий node_modules/ и прочее. Это действительно _ проблема, если у вас есть несколько примеров, каждый из которых содержит свои собственные node_modules/ . Кажется, что .npmignore и т. Д. Игнорируются для установок file: . Это, вероятно, сводится к https://github.com/yarnpkg/yarn/issues/2165 , если решение состоит в том, чтобы _не_ кешировать файлы с локальным разрешением вообще. Если я открою свой кеш ( $ yarn cache dir ) и ищу модули, почему они устанавливаются с file: и они содержат каталог node_modules или другие большие каталоги, я могу ускорить linking phase , удалив эти каталоги вручную. Теперь вроде все устанавливается с хорошей скоростью.

[3/4] Linking dependencies...
Done in 947.71s. 

Пришлось подождать это количество времени, добавляя новый пакет с yarn add ...
Win7 / w Пряжа v0.21.3
В моем приложении есть пакет material-design-icons .
Я думаю, что это связано https://github.com/yarnpkg/yarn/issues/990

@kuncevich с моей

@kuncevic , возможно, вы https://github.com/yarnpkg/yarn/pull/2958

По сути, yarn всегда может копировать каждый файл в node_modules для каждой операции.

@asolopovas в моем случае это node.exe как 10-26 % :

Мой AV не является проблемой, даже если я просто отключил его полностью, я не вижу никаких улучшений скорости пряжи.

узел -v 6.9.2

@kuncevic обновите свой узел до 7 и проверьте, ускоряет ли это @vbfox указывает в правильном направлении.

По сути, yarn всегда может копировать каждый файл в node_modules для каждой операции.

@vbfox, не могли бы вы объяснить, почему? Я смотрю на подробный вывод пряжи и обнаруживаю, что почти все время тратится на создание каталогов и копирование файлов, поскольку он, кажется, делает каждый из них индивидуально, а не, скажем, создает каталог для каждого _package_ и затем копирует весь пакет, который должен быть немного быстрее, или даже просто символическая ссылка на все пакеты, которые снова могут быть быстрее. Это небезопасно?

@danpalmer фаза компоновки

1. Найдите все файлы, которые должны быть в node_modules
2. Сравните этот список с тем, что уже есть, и найдите, что нужно скопировать из кеша в node_modules
3. Сделайте копию

Из-за ошибки libuv / nodejs ( utime используется yarn, и ошибка заключается в том, что он устанавливает миллисекунды равными нулю) файлы, скопированные yarn в предыдущем запуске, всегда оказываются разными (версия в кеше имеет нормальное время изменения, но все файлы в node_modules имеют версию с нулевым значением для миллисекунд), поэтому на этапе 2 всегда сообщается, что все изменилось.

Поскольку ошибка исправлена ​​в узле 7.1, ее довольно легко исправить, если вы не ограничены LTS (первая операция пряжи в репо будет медленной, поскольку файлы были созданы с ошибкой utime но все последующие будут намного быстрее). Мой PR по сути исправляет это, игнорируя миллисекунды времени файлов в окнах при их сравнении.

Что касается копирования всего пакета, это не операция, которая существует в текущих файловых системах. AFAIK все они работают на уровне файлов.
Лучшие окна предоставляют API FileCopy (у меня есть PR использовать его в yarn: https://github.com/yarnpkg/yarn/pull/2960), но он немного быстрее, чем использование собственного API потока nodejs.

Что касается символической ссылки, я не знаю, почему это не сделано, я недостаточно разбираюсь в менеджерах пакетов javascript (в файлы пакета внесены некоторые изменения, такие как удаление тестовых папок, но символическая ссылка на отдельные файлы не изменит этого) но так как это не относится и к linux / macos (где это намного чаще, чем в Windows), может быть веская причина.

Мой эксперимент с обновлением до Node 7.8.0 : https://github.com/yarnpkg/yarn/issues/990#issuecomment -290288375

1. Find every file that need to be in node_modules
2. Check this list versus what is already there and find what need to be copied around from cache to node_modules
3. Do the copy

Учитывая, что большую часть времени люди повторно связывают несколько библиотек при переключении между ветвями - может быть, есть лучший способ сделать это?

Не могли бы вы создать уникальный идентификатор для каждой сборки node_modules а затем создать символьную ссылку на весь каталог из кеша? Таким образом, переключение ветвей вперед и назад на самом деле просто символизирует разные node_modules

Конечно, вы будете много писать на диск, так как теперь вы кешируете каждую версию node_modules , с которой сталкиваетесь, но можно ли там оптимизировать символьную ссылку на каталоги, чтобы вы действительно только хранить дерево символьных ссылок?

Простите меня за наивность, я не самый образованный, когда дело доходит до файловых систем unix и тем более Windows, но я был бы счастлив покопаться в этом в качестве учебного упражнения и попытаться предоставить доказательство концепции этой идеи, если она не имеет явных недостатков.

pnpm и СВА использовать некоторые из методов , которые Вы упоминаете , я думаю, не совсем уверен, пытались их некоторое время назад , но они вызваны либо вопросы Windows , или не быстро , как нить.

У меня тоже было очень много времени на создание приложения-реакции с пряжей
Windows Server 2012
узел 7.9.0
пряжа 0,22
Совершено 554.08.

Но в других случаях это намного быстрее, если не включены установки React.

В последнее время я не наблюдаю долгих ссылок. Бег
Пряжа - v0.23.2
узел - 6.10.2 или 7.9.10 (для переключения используется nvm)

Пробовал это на Mac и Archlinux (Manjaro)

Я могу подтвердить, что добавление узла и пряжи в исключения Защитника Windows сократило время связывания примерно на 60% на моем компьютере с Windows.

+1

[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 180.22s.

Переход на узел 7.9.0 меня не ускорил. Добавление yarn, node и npm в защитник Windows (с расширениями .exe и без них, не знаю, что требуется) ускорило его в 3 раза, но все же на 50% дольше, чем npm install.

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

Добавление моего опыта - добавление node.exe / yarn.exe в список исключений защитника Windows сократило время установки пряжи вдвое (с 60 до 30 секунд).

Я тоже это вижу, потому что быстрые итерации при разработке пакета утомительны, потому что обновление одного пакета занимает так много времени.

yarn install v0.24.5
[1/4] Resolving packages...
[2/4] Fetching packages...
warning [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
Done in 338.20s.

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:    14.04
Codename:   trusty

  "dependencies": {
    "autoprefixer": "^6.7.7",
    "axios": "^0.16.1",
    "babel-core": "^6.24.1",
    "babel-loader": "7.x",
    "babel-preset-env": "^1.4.0",
    "coffee-loader": "^0.7.3",
    "coffee-script": "^1.12.5",
    "compression-webpack-plugin": "^0.4.0",
    "css-loader": "^0.28.0",
    "element-ui": "^1.3.3",
    "extract-text-webpack-plugin": "^2.1.0",
    "file-loader": "^0.11.1",
    "glob": "^7.1.1",
    "js-yaml": "^3.8.3",
    "node-sass": "^4.5.2",
    "path-complete-extname": "^0.1.0",
    "postcss-loader": "^1.3.3",
    "postcss-smart-import": "^0.6.12",
    "precss": "^1.4.0",
    "rails-erb-loader": "^5.0.0",
    "rails-ujs": "^5.1.0",
    "sass-loader": "^6.0.3",
    "style-loader": "^0.16.1",
    "turbolinks": "^5.0.3",
    "vue": "^2.3.0",
    "vue-loader": "^12.0.2",
    "vue-router": "^2.5.3",
    "vue-template-compiler": "^2.3.0",
    "webpack": "^2.4.1",
    "webpack-manifest-plugin": "^1.1.0",
    "webpack-merge": "^4.1.0"
  },
  "devDependencies": {
    "element-theme": "*",
    "element-theme-default": "^1.3.3",
    "eslint": "^3.19.0",
    "eslint-config-airbnb": "^14.1.0",
    "eslint-plugin-import": "^2.2.0",
    "eslint-plugin-jsx-a11y": "^4.0.0",
    "eslint-plugin-react": "^6.9.0",
    "nodemon": "^1.11.0",
    "webpack-dev-server": "^2.4.5"
  }

:(

Добавление в мой +1 на MacBook Pro середины лета 2010 года (Sierra 10.12.4) с использованием пряжи 0.24.5, узла 7.10.0 и npm 4.2.0:

λ пряжа добавить bootstrap-sass
пряжа добавить v0.24.5
[1/4] 🔍 Решение проблем ...
[2/4] 🚚 Получение пакетов ...
[3/4] 🔗 Связывание зависимостей ...
[4/4] 📃 Создание новых пакетов ...
успех Сохраненный файл блокировки.
успех Сохранена 1 новая зависимость.
└─ [email protected]
✨ Совершено в 123.52с.

"dependencies": {
    "@angular/animations": "^4.1.3",
    "@angular/common": "^4.0.0",
    "@angular/compiler": "^4.0.0",
    "@angular/core": "^4.0.0",
    "@angular/forms": "^4.0.0",
    "@angular/http": "^4.0.0",
    "@angular/material": "^2.0.0-beta.5",
    "@angular/platform-browser": "^4.0.0",
    "@angular/platform-browser-dynamic": "^4.0.0",
    "@angular/router": "^4.0.0",
    "bootstrap-sass": "^3.3.7",
    "core-js": "^2.4.1",
    "font-awesome": "^4.7.0",
    "material-design-icons": "^3.0.1",
    "materialize-css": "^0.98.2",
    "rxjs": "^5.1.0",
    "zone.js": "^0.8.4"
},
"devDependencies": {
    "@angular/cli": "1.0.1",
    "@angular/compiler-cli": "^4.0.0",
    "@types/jasmine": "2.5.38",
    "@types/node": "~6.0.60",
    "codelyzer": "~2.0.0",
    "jasmine-core": "~2.5.2",
    "jasmine-spec-reporter": "~3.2.0",
    "karma": "~1.4.1",
    "karma-chrome-launcher": "~2.0.0",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "^0.2.0",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.1.0",
    "ts-node": "~2.0.0",
    "tslint": "~4.5.0",
    "typescript": "~2.2.0"
}

Переключение обратно на npm install исправило это для меня .. Я получал - u'stream ': u' [3/4] Связывание зависимостей в yarn и отсутствие ошибок в NPM ..

Возможно, что-то пошло не так с последней сборкой

Запускаем это через Docker.

@iwarner npm 5.0 - хороший выбор.

Я запускаю пряжу в Vagrant (Ubuntu Xenial) и Jenkins. Есть два подпроекта с package.json.
нпм -v 3.10.10
узел -v 6.10.1
пряжа установить v0.21.3

Некоторое время назад мы перешли с npm на yarn, потому что у нас была проблема с тайм-аутом (4 часа было недостаточно) для установки npm.

Пряжа работает примерно 30% времени, но в 70% случаев в какой-то момент мы получаем 4-часовой тайм-аут. Это может быть первая установка пряжи или вторая, или время ожидания при запуске модульных тестов (шутка).

Это дубликат https://github.com/yarnpkg/yarn/issues/990 , есть сравнительная таблица, и похоже, что последние версии Yarn добились в этом хорошего прогресса.
Если проблема не исчезла, сообщите о новой проблеме с инструкциями по воспроизведению и сравнением с последней версией npm.

success Saved lockfile.
Done in 1737.79s.

Ubuntu 16.04
i5, 8 ГБ оперативной памяти

:(

Windows 10 v 1709 + SSD + PowerShell + Node 6.12.2:
Установка пряжи была быстрой, пока последний пакет не застрял на команде предустановки.
Следуя приведенным здесь инструкциям, добавлял исключения для защитника Windows, но также мой источник был извлечен из источника% USERPROFILE%, что резко замедлило его работу. Проверил в c: шустрее было до кучи.

Любое решение для платформы Ubuntu? Я буквально должен дважды подумать, прежде чем добавлять пакет.

Ubuntu для меня очень быстрая, никакой медлительности.

Пт, 23 февраля 2018 г., 11:13 Басант Бесра, [email protected] написал:

Любое решение для платформы Ubuntu? Мне буквально нужно дважды подумать, прежде чем
добавление пакета.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/1496#issuecomment-367897260 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAcMheTtAYOsXcrnej_f2F8bY5D3nDT2ks5tXizngaJpZM4Kh3OZ
.

Это очень раздражает. Я буквально изменил одну строчку в модуле, переиздал ее под новую версию, и yarn add module заняло более 5 минут.

Было бы быстрее просто обновить мои пакеты вручную с помощью текстового редактора

Я также испытываю эту проблему:

success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ @material-ui/[email protected]
info All dependencies
└─ @material-ui/[email protected]
Done in 93.43s.

Моя система Linux manjaro 4.14.31-1-MANJARO #1 SMP PREEMPT Wed Mar 28 21:42:49 UTC 2018 x86_64 GNU/Linux

NodeJS: v9.9.0
Пряжа: v1.5.1

Также очень медленно для меня Done in 254.32s.

узел v8.10.0
нпм 5.6.0

OSX 10.11.6 (15G19009)

Я снова переключился на [email protected] , все работает отлично.

Мы используем функцию автономного кеширования, чтобы избежать этой проблемы в большинстве случаев, но как только файл package.json или yarn-lock изменится, мы вернемся к этой проблеме. Связывание занимает 10 минут на нашей Linux-машине. Я не думаю, что это специфично для Windows.

Это определенно проблема не только Windows (что должно быть очевидно из всех сообщений от людей, работающих не на Windows)!

Я использую macOS High Sierra 10.13.4, использую узел 10.1.0 (npm 5.6.0) и пряжу 1.6.0. Используя yarn, установка зависимости заняла ~ 40 секунд. Я переключился на npm, и это заняло около 10 секунд. Я пока буду придерживаться npm.

То же самое и с нашей коробкой centos 7. Есть обновления по этому поводу?
пряжа: v1.7.0
npm: v5.7.1

это происходит со мной на 1.9.2 на Mac на узле 10

Для меня в macOS HighSierra проблема была вызвана Avast FileShield. Я добавил исполняемый файл пряжи как исключенный путь, используя which yarn . Сейчас вроде нормально, дам обновление, если вернется.

это происходит со мной на 1.9.2 на Mac на узле 10

Тоже самое. Пряжа 1.9.2, узел 10.6.0 на High Sierra.

@bestander, это не проблема Windows. Я могу воспроизводить изображения на своем Mac с помощью Yarn 1.9.4. Этот вопрос следует открыть повторно.

@davidgoli , лучше открыть новую проблему, это новая проблема, и ее нужно проверять отдельно

Пряжа довольно медленная для любой среды, в которой я ее запускал. Debian, Mac, Windows. Новый выпуск был открыт? или RFC, который избавляется от node_modules, решит это?

У меня такая же проблема, я уже переключился на npm, но все еще есть ошибка

У меня такая же проблема с пряжей. Решение найдено?

Это дубликат # 990, есть сравнительная таблица, и похоже, что последние версии Yarn добились в этом хорошего прогресса.
Если проблема не исчезла, сообщите о новой проблеме с инструкциями по воспроизведению и сравнением с последней версией npm.

Это не дубликат, это проблема не только Windows. Открытие нового выпуска приведет к потере контекста.

У меня такая же проблема!

yarn install
yarn install v1.16.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[###############################################---------------------------------------------------------------------------------------------] 22778/67399

Done in 179.59s.

MacOS / Докер

Бродяга 2.2.4
Гость: Ubuntu 18.10 (GNU/Linux 4.18.0-25-generic x86_64)
Хост: MacOS 10.14.5 Mojave

пряжа 1.16.0
npm 6.9.0

MacBook Pro (Retina, 13 дюймов, начало 2015 г.)
Процессор Intel Core i5 с тактовой частотой 2,7 ГГц
Память 16 ГБ 1867 МГц DDR3

yarn install v1.16.0
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 1552.45s.

На самом деле я не могу запустить yarn install без потери 25+ минут продуктивности. Это абсурдно. Я не верю, что это проблема Windows. Мне кажется очень вероятным, что при работе в виртуализированной среде возникает какая-то проблема. Может быть, дело в синхронизированных папках / проверке состояния файлов на гостевой ОС?

пряжа v1.17.3
узел v10.16.3
нпм 6.9.0

Windows

Я попытался разместить папку проекта приложения в том же разделе диска, что и yarn cache dir .
каталог кеша пряжи -> C: ПользователиAppDataLocalYarnCachev4

Результат:
старое местоположение -> D: myApp Done in 747.17s.
новое местоположение -> C: myApp Done in 488.97s.

C и D - это один и тот же физический диск.

Mac

Однако Mac быстрее, чем Windows Done in 121.37s

Я думаю, что узким местом является скорость чтения / записи диска?

OS X 10.15
пряжа v1.22.4
узел v12.13.0
npm v6.12.0

Я все еще испытываю это. Проект находится в смонтированном зашифрованном образе диска. Установка одного пакета занимает несколько минут с относительно небольшим package.json . Не тестировал его, но npm кажется намного быстрее.

Изменить: оказалось, что изменение папки кеша по умолчанию пряжи на тот же зашифрованный том исправило это для меня.

Просто меня это тоже ударило, и я бегу:

ОС: Ubuntu 18.04.2
Пряжа: 1.22.4
Узел: 14.7.0
NPM: 6.14.7