Yarn: Собственные пакеты пересобираются каждый раз

Не можете воспроизвести это в Mac OSX (10.11.6), так что это может быть специфическая проблема Ubuntu?

Я мог воспроизвести в Windows 10, но только один раз. Во второй раз, когда я запустил «yarn», он не перестраивал собственные библиотеки. Странный.

Я поигрался с этим еще и придумал еще несколько деталей:

1. Если я запустил yarn add leveldown bcrypt , leveldown будет скомпилирован как первый элемент в списке, а хеш в node_modules/.yarn-integrity будет равен 595306... по завершении (вырезать для краткости; я предполагаю, что это контрольная сумма, которая определяет, нужно ли что-то делать). Теперь, если я снова запущу только yarn , оба пакета будут перестроены, и bcrypt будет скомпилирован как первый в списке (порядок другой). Полученная контрольная сумма будет равна cbe480... . Последующий вызов yarn не приведет к перекомпоновке пакетов, и контрольная сумма останется прежней. Это противоречит моему первоначальному отчету (я, вероятно, где-то ошибся), но согласуется с тем, что видел @ Daniel15 .
2. Когда я изменяю порядок пакетов с самого начала ( yarn add bcrypt leveldown ), bcrypt будет первым в списке, а результирующая контрольная сумма сразу же будет равна cbe480... . Последующий вызов yarn не приведет к перекомпоновке пакетов.
3. Пакет bcrypt всегда будет завершен первым (как и ожидалось, поскольку компилировать просто не так уж и много), независимо от позиции в списке.

Я совсем не знаком с внутренним устройством, но мне кажется, что порядок, в котором пакеты компилируются, имеет значение, и они просто не сортируются при первой установке (и они _are_ сортируются при последующем вызове yarn ) что каким-то образом влияет на контрольную сумму.

Спасибо за расследование! Звучит как хорошая зацепка. Хеш записан здесь: https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581 -L583. Возможно, стоит отладить этот код и посмотреть, что изменилось в файле блокировки, поскольку хеш в .yarn-integrity основан на файле блокировки.

Возможно, стоит отладить этот код и посмотреть, что изменилось в файле блокировки, поскольку хеш в .yarn-целостности основан на файле блокировки.

Я подозревал это, но меня сбило с толку то, что файл блокировки не меняется, он всегда один и тот же. Меняется просто хеш в .yarn-целостности.

$ yarn add leveldown bcrypt
$ cat node_modules/.yarn-integrity
59530680cc0a4ee12feb373980b5abf2edf2fe2aefa16d556bfb531af8299e71
$ cp yarn.lock leveldown_bcrypt_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock leveldown_bcrypt_afterwards.lock
$ diff -s leveldown_bcrypt_initial.lock leveldown_bcrypt_afterwards.lock
Files leveldown_bcrypt_initial.lock and leveldown_bcrypt_afterwards.lock are identical

$ yarn add bcrypt leveldown
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_afterwards.lock
$ diff -s bcrypt_leveldown_initial.lock bcrypt_leveldown_afterwards.lock
Files bcrypt_leveldown_initial.lock and bcrypt_leveldown_afterwards.lock are identical

$ diff -s leveldown_bcrypt_initial.lock bcrypt_leveldown_initial.lock
Files leveldown_bcrypt_initial.lock and bcrypt_leveldown_initial.lock are identical

У меня такая же проблема: я тоже использую bcrypt. Каждый раз, когда я устанавливаю новые модули или обновляю существующие, мне приходится запускать npm rebuild чтобы мое приложение работало.

macOS 10.12 && узел v7.0.0 && пряжа v0.16.1

Я больше не могу воспроизвести исходный выпуск. Вроде исправили: +1 :. @ Daniel15 Вы можете подтвердить?

@hustcer Я не думаю, что это та же проблема. Вы можете протестировать последнюю версию и сообщить о новой ошибке, если она по-прежнему не работает.

@jiripospisil Спасибо, теперь все в порядке после обновления до yarn v0.17.4.

Я все еще вижу это или что-то подобное в версии 0.18.1. Между прочим, это также уровень, который постоянно перестраивается. При использовании leftpad в качестве пакета без зависимостей (и от которого leveldown не зависит) в демонстрационных целях шаги воспроизведения следующие:

mkdir test && cd test
echo '{ "name": "test", "version": "1.0.0" }' > package.json
yarn add leveldown 
yarn add leftpad
yarn remove leftpad

Мой результат, когда я запускаю это, следует. Обратите внимание, что удаление левой панели занимает почти 40 секунд, большая часть из которых восстанавливается до уровня. Это происходит постоянно, с и без leveldown или leftpad в кэше Yarn, но только во время remove и никогда не add .

$ mkdir test && cd test
$ echo '{ "name": "test", "version": "1.0.0" }' > package.json
$ yarn add leveldown 
yarn add v0.18.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 145 new dependencies.
<... package list omitted for brevity ...>
✨  Done in 49.93s.
$ yarn add leftpad
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
✨  Done in 2.18s.
$ yarn remove leftpad
yarn remove v0.18.1
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
success Uninstalled packages.
✨  Done in 38.76s.
$ yarn why leftpad
<... just to confirm that leftpad and leveldown are entirely unrelated ...>
yarn why v0.18.1
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.30s.

Версии:

Узел v7.3.0
Пряжа 0.18.1
OS X El Capitan (10.11.6)

Пожалуйста, откройте снова, поскольку это все еще происходит.
Только что сделал yarn add redux и он перестроил bcrypt , node-sass и несколько других.

Узел v6.9.4
Пряжа v0.20.3
Windows 10

@seansfkelley Я выполнил ваши шаги с последней версией, и она сработала. Не могли бы вы попробовать еще раз?

/tmp/tp-20170222100611/test ∴ echo '{ "name": "test", "version": "1.0.0" }' > package.json
/tmp/tp-20170222100611/test ∴ yarn add leveldown
yarn add v0.20.3
info No lockfile found.
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 54 new dependencies.
<cut>
warning [email protected]: No license field
✨  Done in 1.64s.
/tmp/tp-20170222100611/test ∴ yarn add leftpad
yarn add v0.20.3
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
warning [email protected]: No license field
✨  Done in 0.69s.
/tmp/tp-20170222100611/test ∴ yarn remove leftpad
yarn remove v0.20.3
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
warning [email protected]: No license field
success Uninstalled packages.
✨  Done in 0.66s.
/tmp/tp-20170222100611/test ∴ yarn why leftpad
yarn why v0.20.3
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.20s.

@Nexxado Не могли бы вы добавить несколько шагов воспроизведения? Я попробовал несколько комбинаций, но это сработало.

Узел 7.3.0
Пряжа 0.20.3
MacOS 10.12.3

@jiripospisil У меня нет шагов по воспроизведению, просто установка дополнительного пакета заставляет пряжу связывать и перестраивать все.

Вот результат добавления одного пакета (файл блокировки уже существует):

Связывание зависимостей:

Восстановление:

@jiripospisil Я все еще вижу это, но во время репро я споткнулся, потому что похоже, что leveldown (или его зависимость), возможно, начал поставлять двоичный файл, совместимый с OS X, поэтому время установки подозрительно упало с 50 до 3 секунд. Если вы используете OS X и специально используете yarn add [email protected] а не просто yarn add leveldown , вы должны увидеть то же поведение, что и раньше.

У меня есть косвенная зависимость от ttf2woff2 , которая также каждый раз перестраивается.

Однако он перестраивается только каждый раз, когда изменяется значение yarn.lock . То есть yarn с новым yarn.lock , yarn upgrade , yarn upgrade-interactive . В случае yarn upgrade-interactive , если обновлялись и devdeps, и обычные deps, ttf2woff2 перестраивается дважды (!).

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

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

пряжа добавить со
``

затем снова строит уровень вниз.

Кажется, не имеет значения, какой пакет я добавляю, он всегда перестраивает leveldown.

Я использую Yarn v0.21.3, Windows 10 и Node v7.7.1

Я тоже это вижу. Я использую BuckleScript (bs-platform) ....

Я тоже сталкиваюсь с этой проблемой с sharp . Каждый раз, когда я запускаю yarn add или yarn remove , sharp будет перестраиваться, даже с неродными пакетами.

Протестировано в yarn v0.21.3, Node 7.0.0, под Windows 10 и Ubuntu Linux 16.04.

Вот package.json зависимости, если это поможет:

{
  "devDependencies": {
    "auto-reload-brunch": "^2.7.1",
    "babel-brunch": "^6.1.1",
    "babel-preset-env": "^1.2.1",
    "brunch": "^2.10.8",
    "chai": "^3.5.0",
    "clean-css-brunch": "^2.10.0",
    "css-brunch": "^2.10.0",
    "express-mysql-session": "^1.2.0",
    "javascript-brunch": "^2.10.0",
    "jquery": "^3.1.1",
    "less-brunch": "^2.10.0",
    "mocha": "^3.2.0",
    "nodemon": "^1.11.0",
    "npm-run-all": "^4.0.2",
    "postcss-brunch": "^2.0.5",
    "postcss-cssnext": "^2.9.0",
    "postcss-font-magician": "^1.6.1",
    "uglify-js-brunch": "^2.10.0"
  },
  "dependencies": {
    "body-parser": "^1.17.1",
    "connect-redis": "^3.2.0",
    "cookie-parser": "^1.4.3",
    "debug": "^2.6.1",
    "express": "^4.15.2",
    "express-session": "^1.15.1",
    "jstransformer-marked": "^1.0.2",
    "md5": "^2.2.1",
    "morgan": "^1.8.1",
    "multer": "^1.3.0",
    "node-mysql": "^0.4.2",
    "passport": "^0.3.2",
    "passport-local": "^1.0.0",
    "pug": "^2.0.0-beta11",
    "serve-favicon": "^2.4.1",
    "sharp": "^0.17.2"
  }
}

также вижу это с помощью bs-platform

Также наблюдается это с ttf2woff2 каждый вызов yarn add перестраивает ttf2woff2 даже если он не публиковался более года.

У меня это тоже с кушеткой

изменить: кажется, исправлено в 0.23.2

Это все еще происходит со мной в версии 0.23.2 ( argon2 и node-sass перестраиваются каждый раз, когда я добавляю / удаляю какой-либо несвязанный пакет, например moment который не имеет зависимостей)

ОС: Windows 10
Узел: 7.9.0
Пряжа: 0,23,2

Чтобы добавить немного цвета, мое восприятие того, что происходит на yarn add <some-package> было намного больше, чем реальность, так как многие случаи для меня фактически были вызваны комбинацией с yarn remove <unrelated-package> непосредственно перед этим из-за force: true в этой строке .

Конечно, удобно повторно использовать логику установки в remove для генерации файла блокировки, но было бы неплохо, если бы в ней не было всего багажа принудительной установки :)

Для меня это начало происходить снова, когда я обновился до 0.23.x. Я вернулся к 0.21.3, и он больше не строится каждый раз. Также это привело к этой проблеме, когда мой IP-адрес был заблокирован unicode.org после обновления нескольких пакетов подряд https://github.com/dodo/node-unicodetable/issues/16

Хотя 0.21.3 не перестраивает все пакеты при добавлении нового пакета, он перестраивает все пакеты при удалении. И, похоже, пряжа не считает неудачей, если восстановление не удастся.

Для меня понижение до 0.21.3 не помогло. bs-platform перестраивается при каждом добавлении / удалении.

Это можно увидеть на macOS с Yarn 0.23.4. Перестраивает sqlite3 каждый раз, когда я запускаю yarn add .

$ yarn add gulp-rename gulp-notify gulp-sass -D                                                                                         1 ↵
yarn add v0.23.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning [email protected]: The platform "darwin" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
warning [email protected]: The platform "darwin" 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.
success Saved 42 new dependencies.
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
└─ [email protected]
$ install-app-deps
Rebuilding native production dependencies for darwin:x64
Rebuilding native dependency sqlite3
✨  Done in 56.61s.

Увидев эту проблему с Ubuntu 16.04LTS, с последней пряжей v0.24.6, с узлом 8.1.2

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

Я тоже это вижу, это очень раздражает на Raspberry Pi Zero W, где сборка пакетов (например, bleno) может занять несколько минут.

Это все еще наблюдается с Yarn v0.27.5 и uws . Каждый раз, когда что-то меняется в моих пакетах, uws перестраивается.

Единственная интересная вещь, которую я могу увидеть в uws - это то, что у него нет поля зависимостей в package.json .

Это становится для меня большим разочарованием в последние несколько дней. У меня был windows-build-tools установленный глобально на одном этапе (на самом деле нужно построить себя только один раз, чтобы настроить среду разработки Windows для собственных пакетов), которая продолжала перестраиваться каждый раз, когда я добавлял пакет. Как вы понимаете, это заняло некоторое время, и в конце концов я понял, что мне больше не нужно устанавливать его, и удалил его.

Теперь кажется, что node-sass продолжает хотеть перестроить на другой проекции при добавлении пакетов.

Это происходит для меня как yarn add и yarn remove . Конечно, для этих шагов не требуется перекомпоновка, поскольку собственные пакеты создаются только один раз в соответствии с версией Node?

Изменить: использование Node v8.2.1 и Yarn v0.27.5 в Windows 10.

Я не могу сосчитать, сколько раз uws перестраивалось для меня :) Обратите внимание, что uws
имеет нулевые зависимости и даже отсутствует поле в package.json

В пн, 31 июля 2017 г., 22:50 Пол Майбург [email protected]
написал:

Это становится для меня большим разочарованием в последние несколько дней. я имел
Windows-build-tools, установленные глобально на одном этапе (действительно нужно только
собрать себя один раз, чтобы настроить среду разработки Windows для нативной
packages), который перестраивался каждый раз, когда я добавлял пакет. В виде
Вы можете себе представить, что это заняло некоторое время, и в конце концов я понял, что не
нужно больше установить и удалил его.

Теперь кажется, что node-sass все еще хочет перестроить на другой проектируемой
при добавлении пакетов.

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

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

Я использую 0.27.5 и продолжаю наблюдать такое поведение с bs-platform .

Довольно разочаровывает это, то же самое здесь с bs-platform .

Хорошее чувство собственного достоинства… Как насчет пиара, Тим?

Вторник, 22 августа 2017 г., 10:44 Тим Шнайдер [email protected]
написал:

FFS, можно это исправить, пожалуйста.
По крайней мере, предоставьте параметр командной строки или параметр env, чтобы отключить его.

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

Кажется, до сих пор об этом не упоминалось, но я также могу воспроизвести эту ошибку с помощью yarn global list .

Действия по воспроизведению:

1. Используйте новый глобальный env:: warning: запускайте это, только если знаете, что делаете

   rm -rf ~/.config/yarn/
   

2. Добавьте проблемный пакет (_i.e._ zeppelin-solidity ):

   → yarn global add node-gyp zeppelin-solidity
   yarn global v0.27.5
   [1/4] Resolving packages...
   warning zeppelin-solidity > truffle-hdwallet-provider > web3-provider-engine > ethereumjs-block > merkle-patricia-tree > level-ws > xtend > [email protected]:
   [2/4] Fetching packages...
   [3/4] Linking dependencies...
   [4/4] Building fresh packages...
   success Installed "[email protected]" with binaries:
         - node-gyp
   warning "[email protected]" has no binaries
   Done in 20.53s.
   

3. Запустите yarn global list и увидите, что некоторые собственные пакеты перекомпилируются.

4. Повторяйте столько, сколько хотите, yarn global list всегда будет перекомпилировать эти собственные пакеты
5. 😭

Надеюсь, это поможет.

ℹ️ MacOS 10.12.6 с Yarn 0.27.5, установленной через Homebrew.

В праве нет необходимости, но я могу понять разочарование. Это отнимает у многих людей много времени (длительные переустановки со временем накапливаются и прерывают поток). Конечно, вы можете сказать «сделайте запрос на перенос» - и это справедливо. Но это был бы процесс обучения на вершине потенциально возможного изменения всего нескольких строк кода ... Мы надеемся, что люди, которые знают все тонкости этого проекта, могут уделить приоритетное внимание этой проблеме в следующем выпуске, поскольку она действительно кажется довольно серьезным (и потенциально легким решением? Возможно, предотвратите переустановку двоичных файлов, если версия Node не изменилась).

Прошёл почти год с момента первого сообщения.

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

РЕДАКТИРОВАТЬ: только что сделал yarn remove для случайного пакета, и он попытался и (на этот раз) не смог восстановить мои двоичные файлы. Побочным эффектом является то, что мои двоичные файлы теперь полностью отсутствуют, и кажется, что единственный способ исправить это - использовать npm rebuild . Таким образом, кажется, что эта проблема не только вызывает ненужные перестройки, но и, если этот процесс не удается, кажется, что вам нужно вернуться к npm чтобы исправить это снова.

Я наблюдаю то же поведение, что и @zhangjyr и @lostpebble. Запуск yarn add работает нормально, но yarn remove вызывает перекомпоновку собственных пакетов.

Mac Sierra 10.12.6
Пряжа 0,27,5

Я постараюсь посмотреть, что я могу с этим поделать, поскольку это тоже влияет на меня. Тем не менее, Yarn не так уж сложно внести свой вклад, поэтому, если кто-то хочет отправить PR, пожалуйста, попробуйте, и мы постараемся поддержать вас, насколько это возможно.

Я не смогу работать над этим несколько недель.

Я тоже это вижу.
Работаем над сайтом build на gatsby. ЛЮБАЯ операция с пряжей вызывает восстановление.
Попробуйте создать сайт с помощью gatsby и поругаться с ним. Надеюсь это поможет

Увидев это в проекте с использованием gatsby:
пряжа 1.0.2
узел 7.10.1
убунту 16.04

Сейчас этот вопрос становится достаточно серьезным. Не только мои двоичные файлы всегда перестраиваются. Но часто случается, что мои двоичные файлы полностью удаляются после yarn add или yarn install (после изменения номеров версий пакета в package.json для обновления / отката модуля). И сколько бы я ни запускал yarn install или yarn install --check-files после этого, эти двоичные файлы просто теряются, исчезают и никогда не возвращаются. Единственный способ получить их - использовать npm rebuild .

Кажется, что yarn вообще ничего не знает о состоянии нативных пакетов. Независимо от того, установлены ли они / построены или не установлены / построены должным образом.

Возможно, в этом есть какой-то прогресс?

Я думаю, что недавнее добавление поля artifacts к файлу целостности пряжи от @arcanis поможет решить эту проблему. Пока нет прогресса, но открыт для PR :)

У меня аналогичная проблема с bs-платформой при установке пакетов в моем проекте reasonml

То же самое ... буквально каждый yarn add будет пересобирать проект gyp.

Здесь тоже бывает.
(пряжа 1.2.1)

Я вижу это с помощью node-sass .

Бывает, например, с Cypress.

узел -v
v8.8.1
пряжа -v
1.2.1

✋ Вместо того, чтобы писать «Я тоже» без дополнительной информации, используйте функцию +1 в Github в верхнем посте . Каждый раз, когда вы пишете комментарий «я тоже», без надобности уведомляются 35 подписчиков.

+1

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

@BYK , пожалуйста, заблокируйте тему и сделайте ее доступной только для владельцев.

В настоящее время я изучаю эту проблему и пытаюсь свести ее к минимально воспроизводимому тесту. «Отличным» пакетом для демонстрации этой проблемы является htmlstrip-native - компиляция занимает несколько минут, поэтому вы не сможете его пропустить.

Я бы хотел, чтобы кто-нибудь еще попробовал этот package.json в пустой папке:

{
  "name": "yarn-test",
  "version": "1.0.0",
  "dependencies": {
    "htmlstrip-native": "^0.1.3",
    "left-pad": "1.1.3"
  }
}

Попробуйте выполнить эти команды:

yarn
yarn upgrade [email protected]

На моей машине с последней версией пряжи 1.2.1 команда upgrade приводит к перестройке htmlstrip-native которая занимает вечность. Yarn не следует перестраивать это, поскольку обновление left-pad не влияет на htmlstrip-native или его зависимости.

Теперь попробуйте npm :

rm -rf node_modules
npm install
npm install [email protected]

На моей машине вторая команда (правильно) не приводит к новой перестройке htmlstrip-native .

РЕДАКТИРОВАТЬ : перечитав все сообщения выше, похоже, что этот случай никого не удивит - большинство людей, в том числе и я, обнаруживают, что простой запрос yarn сделать что-нибудь приводит к перестройке. Я предполагаю, что это не большая проблема для сообщества, потому что большинство людей не используют собственные пакеты, сборка которых занимает много времени - так что у них либо нет шага перестройки, либо он завершается так быстро, что кого это волнует.

Итак, после долгой отладки выяснилось, что такое поведение является преднамеренным. Если проследить код, то, например, похоже, что yarn upgrade [email protected] приводит к следующим шагам:

1) upgrade модуль new Add() для left-pad .
2) Add.init() вызывает свой суперкласс, Install.init()
3) Install.init() ставит в очередь rebuildingPackages шаг
4) В PackageInstallScripts.init() он просто собирает _все_ пакеты и добавляет их в workQueue для перестройки.
5) PackageInstallScripts затем обнаруживает, что есть команда установки для htmlstrip-native и просто запускает ее - это сверхмедленная собственная перестройка, которую мы все наблюдаем.

Из всего, что я видел до сих пор, похоже, нет никакой логики, которая намеревалась бы отфильтровать пакеты, которые не «нужно» перестраивать. Он просто перестраивает все, как указано в выводе консоли.

Мне бы хотелось, чтобы здесь вмешался кто-нибудь из команды Yarn - если такое поведение действительно намеренно, я бы рекомендовал закрыть эту проблему!

Лично для моей ситуации я просто заменю свою зависимость htmlstrip-native поскольку нет причин, по которым ее сборка должна занимать минуты (это как пара крошечных файлов .c ). Остальные мои родные депы растут быстро, так что не беда, если это происходит все время.

Это звучит как непреднамеренный побочный эффект дизайна, но, возможно, кто-то из @ yarnpkg / core прокомментирует это. Я не думаю, что он предназначен для пересборки пакетов, которые не нужно перестраивать.

Это не намеренно, наверное, проще реализовать так.
Выше есть комментарий от BYK, в котором говорится, что эта проблема требует PR:
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

Конечно, нативные тяжелые пакеты недостаточно распространены, чтобы иметь высший приоритет для Yarn, однако Yarn имеет возможность не перестраивать пакеты при каждой установке.
Это похоже на ошибку, которую нужно сразу исправить, отправьте PR.
Могут быть оговорки, потому что Yarn не может точно знать, мог ли собранный пакет быть поврежден, поэтому сейчас он с нетерпением перезапускает сценарии установки.

Существует форк Yarn, который используется командой Reason https://github.com/esy-ocaml/esy-install, которая помогает решить множество проблем с собственной компиляцией, поскольку зависимости Reason / Ocaml требуют тяжелой компиляции.
Я надеюсь, что по мере того, как этот подход станет более зрелым, можно будет объединить изменения вверх по течению.

По сути, собственные пакеты перестраиваются, потому что либо:

1) Установлен флаг force=true , или
2) Пакет помечен как fresh=true .

Похоже, что с некоторыми командами (такими как upgrade и remove ) флаг force установлен в значение true «на всякий случай». Этот флаг обещает «перестроить все пакеты независимо от того, были ли они изменены», поэтому нет смысла добавлять какой-либо код обнаружения изменений, потому что это нарушит это обещание.

Итак, чтобы исправить это, похоже, нам нужно будет оспорить допущения в различных местах кода, которые устанавливают force=true .

Первое, что я обнаружил, происходит при запуске yarn upgrade whatever . Он был представлен в этом коммите как часть # 2780 @juanca. В примечаниях к фиксации говорится:

"Ensure force flag is enabled when using `yarn upgrade` Otherwise exotic packages are not updated."

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

@nfarina, спасибо, это вносит ясность. Для обновлений, возможно, мы действительно хотим принудительно создавать собственные пакеты (если они обновляются). Но для установки (добавление пряжи) я бы сказал, что нам законно нужно оспорить, как вы сказали, предположение, которое заставляет уже установленные собственные пакеты перестраивать, когда что-то еще установлено.

Я полагаю, что установлен флаг force чтобы преобразователь Yarn не пропустил существующую зависимость, потому что старая версия находится в yarn.lock.

Я думаю, что это было быстрое решение сделать обновление работоспособным.
Правильный способ - передать другой флаг, который влияет только на разрешение указанных пакетов и не будет таким ядерным, как force .
Отправить пиар :)

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

Правильно, я работал только с API Add - он ничего не делает (делал?) При добавлении существующего пакета.

Я также рекомендую использовать лучшую технику управления процедурным потоком.

Я использую пряжу на моем raspberry pi zero в проекте, который зависит от node-opencv. Каждый раз, когда я добавляю / удаляю / обновляю несвязанный пакет, мне приходится ждать 35 минут для восстановления.

@ Torsten85 , я тоже использую его на пи, да, ненужные пересборки - это то, чем мы должны заняться.
Можете ли вы предоставить сценарий воспроизведения для ваших перестроек?

то же самое здесь, на lubuntu 17.10, когда я использую пряжу, развивающуюся с https://github.com/mui-org/material-ui

каждая yarn add/remove (-D) <pkg> перекомпоновка всего, как и новая установка, занимает более 1 минуты

Это то, как npm тоже с этим справляется? Если нет, возможно ли временное решение проблемы?

происходит также здесь

• узел 9.2.0
• пряжа 1.4.0

каждый раз, когда я добавляю зависимость, модули, такие как bcrypt или couchbase, каждый раз перестраиваются

Всем привет, я работаю над небольшим хаком https://github.com/yarnpkg/yarn/pull/5314.
Идея состоит в том, чтобы кэшировать встроенный пакет в автономное зеркало, чтобы избежать постоянного запуска сценариев установки.

Итак, если вы используете offline-mirror и запускаете yarn add node-sass :

1. yarn будет собирать и устанавливать node-sass как обычно,
2. после запуска сценариев установки он сгенерирует node-sass-v4.7.2-darwin-x64-57.tgz из измененной папки node_modules/node-sass
3. В следующий раз, когда вы запустите yarn install на той же платформе, он просто распакует node-sass-v4.7.2-darwin-x64-57.tgz вместо исходного и не будет запускать сценарии установки

Это не сработает для всех случаев, но это может быть решением для автономных систем CI, в которых вы не хотите, чтобы пакеты доходили до нас в Интернете и запускали одни и те же сценарии установки каждый раз.

Я пытаюсь установить typescript как глобальный пакет, а yarn все время тратит время на перестройку, вместо того, чтобы устанавливать то, что мне действительно нужно сейчас.

Я перешел на пряжу, думая, что это быстрее и лучше. Я удалил все следы npm (кроме того, что идет при установке узла); и переустановил все глобальные пакеты в yarn.

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

Окружающая обстановка:

• Узел: 9.4.0
• Пряжа (глобальная): 1.3.2
• macOS Sierra: 10.12.6
• Macbook pro 15 дюймов
  
  
  
  • Оперативная память: 16 ГБ
  
  
  • Процессор: 2 ГГц - Intel Core i7
  
  
  • Хранение: пурпурный (много свободного места)
  
  
  • Приложения, работающие во время установки: Firefox (6 вкладок), Mail.app и iTerm (с 2 вкладками)
  
  

Журналы

Получение пакетов занимает много времени

Машинопись пряжи глобального обновления
пряжа global v1.3.2
[1/4] 🔍 Решение проблем ...
[2/4] 🚚 Получение пакетов ...
[############################################## ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

Связывание зависимостей зависло без какого-либо прогресса на несколько минут

Машинопись пряжи глобального обновления
пряжа global v1.3.2
[1/4] 🔍 Решение проблем ...
[2/4] 🚚 Получение пакетов ...
[3/4] 🔗 Связывание зависимостей ...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

Пересборка всех пакетов - занимает много времени

Машинопись пряжи глобального обновления
пряжа global v1.3.2
[1/4] 🔍 Решение проблем ...
[2/4] 🚚 Получение пакетов ...
[3/4] 🔗 Связывание зависимостей ...
[4/4] 📃 Пересборка всех пакетов ...
[17/12] ⠐ веб-сокет
[2/17] ⠐ expresso: проверка опции gcc для принятия ISO C99 ...
[17/8] ⠐ последовательный порт: с использованием [email protected] | Дарвин | x64
[6/17] ⠐ сейчас:> Исходный код можно найти на странице https://github.com/zeit/now-cli.

Машинопись пряжи глобального обновления
пряжа global v1.3.2
[1/4] 🔍 Решение проблем ...
[2/4] 🚚 Получение пакетов ...
[3/4] 🔗 Связывание зависимостей ...
[13/17] ⠈ без сервера
[13/17] ⠂ без сервера
[14/17] ⠠ сольграф
[14/17] ⠁ сольграф
[14/17] ⡀ сольграф
[- / 17] ⠈ жду ...
[- / 17] ⠄ жду ...
[- / 17] ⠠ жду ...
[- / 17] ⠈ жду ...
[- / 17] ⠄ жду ...
[- / 17] ⢀ жду ...
[- / 17] ⠈ жду ...

Я все жду :-)

Другой побочный эффект заключается в том, что библиотеки, которые загружают и кешируют прекомпиляторы, также стираются и должны быть загружены снова: а именно nwjs-builder-phoenix кеш целевых SDK для сборки

1. Собственный пакет всегда перестраивается при обновлении версии пакета, который не является родным.

Кеширует ли yarn двоичный файл в глобальном, например npm?

Меня начинает немного расстраивать необходимость перестраивать nwjs при каждой простой установке. Без разницы

Я тоже это вижу. uws перестраивается каждый раз, когда я выполняю операцию добавления / удаления. пряжа v1.3.2

Привет @bestander. Мы пробовали # 5314 на монорепозитории нашей компании, однако он не повлиял на остановку перестроения некоторых зависимостей для нас. Мы включили yarn-offline-mirror и pack-built-packages в .yarnrc, как показано в добавленных тестах.

Суть в том, что запуск yarn всегда занимает у нас около 40-50 секунд, даже если команда, которую мы запускали непосредственно перед этим, тоже была yarn .

@ bazyli-brzoska, я поменял флаг на более явный и забыл обновить описание.
Можете ли вы попробовать установить флаг experimental-pack-script-packages-in-mirror как "true"?

Есть ли в этом прогресс? Я вижу, что запрос на перенос уже объединен и что он находится в последней версии 1.5.1. Я на 1.5.1 и у меня ничего не изменилось. Тем не менее, я рассматриваю возможность вернуться к npm, потому что жду 322.70s или 282.69s или даже 683.41s (это действительно мои последние три yarn add s) на установка небольшого накопительного плагина, lodash или чего угодно, просто безумие.

Было бы здорово, если бы такие важные предостережения были на вашем README.md. Пользователи устанавливают пряжу, потому что она якобы «быстрее», и переход от npm к пряжи - непростой шаг, поэтому было бы неплохо, если бы для разработчиков было какое-либо предварительное предупреждение, чтобы они могли подумать об этом еще раз, прежде чем преобразовывать их сценарии, загрязняя их глобалы и изучая пряжу cli.

Я думал, что это проблема моей старой 32-битной машины, но, увидев это в 237-й раз, я погуглил, и, о, пряжа просто не быстрее. Отлично.

Извините за то, что, вероятно, был груб, но я думаю, вы разочаровались.

Мы принимаем взносы.

При этом следует помнить о пакетах, которые перестраиваются, когда им "не нужно": шаги сборки выполняются после установки зависимостей. Это означает, что сценариям сборки разрешено использовать эти зависимости. Это означает, что если эти зависимости изменяются по какой-либо причине (что может происходить «случайным образом», например, если мы оптимизировали две совместимые версии пакета в одну), то нам действительно нужно повторно запустить шаги сборки, даже если эти зависимости на самом деле не используется во время сборки (потому что как мы могли знать?).

Так что это не совсем простая проблема. По крайней мере, часть проблемы связана с самим дизайном package.json. Расскажи мне о разочаровании 🙂

@arcanis Я не понимаю этой части:

даже если эти зависимости фактически не используются во время сборки (потому что как мы могли узнать?).

Я думал, что дизайн YARN должен сохранять статические зависимости + версия (yarn-lock), и поэтому случайных «обновлений» не будет.
Несмотря на то, что пакет json дает полное дерево, почему вы говорите «откуда мы можем знать»? После того, как дерево разрешено, действительно легко сказать, изменилась ли какая-либо из зависимостей (даже на глубоком уровне) для построения X или нет.

Скажем, у меня есть зависимость foo которая зависит от babel-core и left-pad@^1.0.0 , и что эта зависимость foo имеет сценарий сборки, который запускает babel в своем индексном файле .

После запуска yarn add foo в моей папке проекта я получаю [email protected] в node_modules, верно? Теперь предположим, что выпущена новая версия для левой панели ( 1.1.0 ), и я хочу использовать ее в своем проекте. Я запустил yarn add left-pad , который затем преобразуется в latest , то есть 1.1.0 .

Теперь может случиться так, что Yarn "увидит" две копии левой панели в дереве, а также увидит, что их можно оптимизировать: в конце концов, foo зависит от left-pad@^1.0.0 , поэтому 1.1.0 совместим. Таким образом, он удалит предыдущую версию и будет использовать только 1.1.0 . Поскольку зависимость изменилась, нам нужно снова запустить скрипт сборки, потому что Yarn не имеет возможности узнать, что left-pad - это зависимость времени выполнения, а не зависимость времени сборки .

Теперь вы можете спросить: «А почему бы просто не пропустить перестройку, когда изменились переходные зависимости?». Ответ заключается в том, что некоторые пакеты (в частности, собственные пакеты) имеют зависимости, которые радикально влияют на то, как они создаются. Когда это происходит, мы действительно, очень хотим пересобрать эти пакеты, иначе мы получим несовместимые артефакты.

@arcanis , я думаю, вы неправильно поняли проблему. проблема здесь в том, что эти собственные пакеты перестраиваются _every_ раз, даже когда yarn запускается дважды (или более) в быстрой последовательности. он не _не имеет_ ничего общего с обновлением зависимостей - он _ всегда_ перестраивается.

@Spongman Я согласен с вашим последним комментарием. Но, как правильно заметил @Spongman , восстановление происходит каждый раз . Даже если вы сделаете всего лишь yarn && yarn - вы получите два полных перестроения , несмотря на то, что в структуре зависимостей ничего не изменилось.

Я пробовал запустить yarn add leveldown bcrypt && yarn && yarn как в OP, и получил только одну сборку: / У вас есть команда, которую я могу использовать для воспроизведения этого поведения?

Вы можете попробовать, например:

mkdir foobar
cd foobar
yarn init
....
yarn add socket.io
      (5 native packages build)
yarn add react
      (5 native packages build again)
yarn remove react
      (5 native packages build again)

(это под Ubuntu 14 LTS)

foobar billli$ yarn -v
1.3.2
foobar billli$ node -v
v8.9.1

yarn & yarn 

Не вызывает две перестройки, но пример с socket.io, добавление реакции, удаление реакции вызывает две перестройки

Я попробовал пример socket.io с yarn v1.5.1 и не получил перестроений при использовании новой функции для кеширования собственных сборок. Для этого вам нужно использовать автономный кеш. В моем ~/.yarnrc меня есть:

experimental-pack-script-packages-in-mirror true
pack-built-packages true                                         
yarn-offline-mirror "/home/skomorokh/yarn-offline-cache"

Когда я пытаюсь от имени другого пользователя без этой конфигурации, он все еще перестраивается.

Да, теперь при добавлении этих опций перестройки нет.
Но если только experimental-pack-script-packages-in-mirror true , он все равно перестраивается.
Почему бы не установить yarn-offline-mirror на путь по умолчанию, например "~ / .yarn / cache".

Все еще экспериментальное, но интересное предложение (cc @bestander). Думаю, проблема в том, что мне лично не нравится идея включать что-то без явного согласия пользователя. Это также имеет другие последствия: что бы означало, если yarn-offline-mirror установлен на false , а experimental-pack-script-packages-in-mirror на true ? Следует ли experimental-pack-script-packages-in-mirror перезаписать настройки yarn-offline-mirror ? Немного сбивает с толку imo.

При этом ошибка перестройки uws при добавлении left-pad действительно раздражает, а настройки experimental-pack-script-packages-in-mirror - это только обходной путь. Я не уверен, что у меня будет пропускная способность, чтобы посмотреть на это на следующей неделе или около того, но если кто-то заинтересован в исправлении, это будет весьма эффективно.

@arcanis Спасибо за любезный ответ. Разочарование вызвано тем, как представлена ​​пряжа. На данный момент это просто не «быстро», определенно не быстрее, чем npm, и его нельзя использовать в реальных проектах. Имхо, в вашем файле README.md должна быть информация об этом или даже обходном пути @skomorokh, пока это не будет исправлено. Или просто уберите слово «пост» из своего описания.

Я бы испытал такое же разочарование, если бы в readme репозитория angularjs было сказано, что это облегченная структура. Это просто не так.

Всегда повторяется загрузка двоичного файла после yarn-offline-mirror config.

cd \tmp\t
yarn init
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node

Попробую сегодня немного отладить это. Я думаю, что на самом деле это может быть так же просто, как PackageInstallScripts не проверять pkg.fresh только для пересборки только что установленных пакетов. Вместо этого похоже, что он просто зацикливается на них всех.

После некоторой возни я начинаю думать, что мы все время перестраиваем вещи, если кто-то rm -rf node_modules или модуль будет удален оттуда.

У нас есть список обнаруженных артефактов сборки в файле .yarn-integrity , поэтому я думаю, что перестройка должна происходить, только если fresh package || module destination dir does not exist || any file in integrity artifacts does not exist || --force flag was passed

Так что это немного сложнее, чем я думал.

У меня только yarn add ed moment , пакет с нулевой зависимостью, для моего современного приложения для реагирования потребовалось 377.97s .

Сделал это снова сразу после этого, потребовалось 389.63s и снова пересобирались двоичные файлы.

Для сравнения я удалил node_modules и ввел npm install :
added 1751 packages and updated 124 packages in 360.595s

Вернулся к npm сейчас.

Хорошо, еще немного информации для всех, кто видит эту проблему ... Я возился с этой штукой уже полтора дня и наконец понял несколько вещей.

Во-первых, большинство из этих проблем с перестройкой исправлено. В PackageInstallScripts уже есть код, который повторно запускает сценарии установки только для пакета, помеченного как «свежий» :

    if (!ref.fresh && !this.force) {
      // this package hasn't been touched
      return false;
    }

Так, например, если вы используете node-sass :

yarn add node-sass <-- builds sass because first install
yarn add left-pad <-- does NOT rebuild node-sass

Также последовательные yarn install s не восстанавливаются.

yarn add uws <-- builds because first install
rm -rf node_modules
yarn install <-- builds uws because dir was deleted
yarn install <-- does NOT rebuild uws

... но, конечно, есть пара исключений ...

На yarn remove установлен флаг force (я предполагаю, чтобы исправить другую ошибку, но так было уже> 2 лет), поэтому перестройки происходят всегда.

Однако это, пожалуй, «правильно», потому что это то, что делает и npm:

~/Projects/yarn-test 🐒   npm uninstall left-pad

> [email protected] install /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/install.js

Cached binary found at /Users/me/.npm/node-sass/4.7.2/darwin-x64-57_binding.node

> [email protected] postinstall /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/build.js

Binary found at /Users/me/Projects/yarn-test/node_modules/node-sass/vendor/darwin-x64-57/binding.node
Testing binary
Binary is fine
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

added 180 packages, removed 1 package and updated 7 packages in 4.03s

Вы можете видеть, что на uninstall из left-pad npm запустил сценарии install и postinstall для node-sass .

Пакет uws (который используется довольно многими другими пакетами, такими как socket.io , browser-sync и т. Д.

что-то в процессе установки изменяет один из файлов (размер и временная метка разные).

~/Projects/yarn-test 🐒   ls -l /Users/me/Library/Caches/Yarn/v1/npm-uws-9.14.0-fac8386befc33a7a3705cbd58dc47b430ca4dd95/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  383636 Nov 21 00:43 uws_darwin_57.node

~/Projects/yarn-test 🐒   ls -l node_modules/uws/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  378672 Mar  4 11:18 uws_darwin_57.node

yarn видит файл, который "изменился" по сравнению с кешем, поэтому помечает пакет "новым" для повторной установки

Затем запускается указанная выше логика, которая повторно запускает сценарии установки, поскольку они «свежие». Yarn пытается помочь и «исправить» неправильные файлы, но, конечно, не знает, что файл изменился из-за сценария установки. Возможно, нам придется изучить какой-то способ исправить это, но также говорится об изменении способа сравнения этих файлов (прекратить запуск статистики для каждого файла), чтобы эта переделка могла решить эту проблему.

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

Спасибо, что нырнули поглубже, @ rally25rs.

1. Re: использование force в команде удаления.
   Это явно было быстрое исправление ошибки, которая достигла правильности с помощью ядерного подхода IIRC https://github.com/yarnpkg/yarn/pull/323.
   Нетрудно удалить force и обойти проблему.

2. node_modules/uws/uws_darwin_57.node : этот файл должен находиться в поле artifacts .yarn-integrity и тогда uws не должны быть помечены как устаревшие во время связывания.
   Что-то здесь наверное не так

@bestander ах хороший замечание по поводу 2. Я попробую посмотреть, есть ли разумный способ проработать это до проверки.

@stereokai В моем комментарии выше я отмечаю, что npm также перестраивает пакеты при удалении / удалении, так что этот случай, возможно, «правильный», если вы считаете поведение npm стандартным.

@ rally25rs Спасибо, что указали на это :)

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

@stereokai Я частично согласен, поэтому я использовал фразу «возможно, правильно» 😆
Ваша ОС также не меняет место установки других приложений, когда вы удаляете несвязанное.

Предположим, у вас есть какое-то дерево зависимостей, например:

myProj
  |- depA v1
  |    |-depB v2
  |- depB v1

Если вы установите его, он сформирует ту же структуру каталогов в node_modules , потому что он не может поднять depB в корень.

myProj
  |- node_modules
       |- depA v1
       |   |- node_modules
       |        |-depB v2
       |- depB v1

Но из вас, yarn remove depB тогда новая структура dep:

myProj
  |- depA v1
       |-depB v2

myProj
  |- node_modules
       |- depA v1
       |- depB v2

поэтому фактический каталог, в котором установлен depB v2, может изменяться при добавлении или удалении пакета. Эти каталоги не просто копируются из одного места в другое. Старый удаляется, а новый копируется из кеша в новое место назначения, что означает, что артефакты сборки, которые были в node_modules/depA/node_modules/depB больше не будут существовать, и их нужно будет перестроить в node_modules/depB .

Точно так же yarn add [email protected] изменит путь, по которому установлен depB v2 (на самом деле я должен проверить, что мой PR, чтобы не восстанавливать его на yarn add действительно работает в этом случае)

Подозреваю, поэтому каждый раз эти пакеты пересобираются.

Фактическое изменение произошло в этом коммите: https://github.com/yarnpkg/yarn/commit/5300b482c851e2578ac1f3aa4908be4d0289dca8
еще в 2016 году. В то время файл назывался uninstall.js , но force: true был добавлен к флагам, переданным в install . Похоже, что в комментарии к фиксации нет ничего конкретного, чтобы указать _why_.

Было бы здорово, если бы был способ избежать перестроек хотя бы в _ некоторых_ случаях.

Любой желающий может работать над пиаром. 😸 Как я указывал выше, перестроения уже не происходят на yarn install и yarn add (в большинстве случаев). У меня открыт # 5470, который должен устранить ненужные перестройки для yarn add когда у вас есть uws в ваших зависимостях (или других пакетах, которые изменяют собственные файлы во время установки). Единственный оставшийся случай, о котором я знаю, - это yarn remove .

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

У меня есть несколько собственных пакетов, которые перестраиваются каждый раз, когда я использую yarn add для любого другого (несвязанного) модуля. Это занимает около 20 минут при очень высокой загрузке процессоров моего ноутбука. Я просто не могу так работать.

Судя по этой теме, это проблема уже 19 месяцев.

Это ошибка? Над этим работают? Есть ли обходной путь? Должен ли я вернуться на npm?

Должен ли я вернуться на npm?

да, пока не будет выпущен # 5470.

@vibl

Судя по этой теме, это проблема уже 19 месяцев.

На самом деле это было исправлено (в основном) очень давно. Этот поток остается открытым для одного крайнего случая, который я обнаружил несколько недель назад, когда yarn будет перестраивать пакет, если этот пакет изменил какой-либо из своих файлов (он считает, что файл неправильный по сравнению с тем, что было в исходной загрузке, поэтому хочет исправить Это). И для некоторой открытой дискуссии о том, должны ли remove и upgrade выполнять перестройку (это происходит в npm, но, возможно, не должно)

Это ошибка?

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

Над этим работают?

Конкретный случай, о котором я упоминал выше, исправлен в # 5470.

Есть ли обходной путь?

Если добавляемый вами пакет не имеет сценариев установки, вы можете использовать --ignore-scripts

Или вы можете проверить ветку из приведенного выше PR и использовать это.

Это займет около 20 минут

Вау. Мне любопытно, что это за пакет.

Спасибо за ответы.

Пакеты noise-search , level-rocksdb и jq перекомпилируются каждый раз, когда я добавляю какой-либо несвязанный пакет с yarn add . Мой ноутбук немного староват, поэтому на их одновременную компиляцию уходит очень много времени.

Я использовал Yarn 1.5.1 и node 9.8.0.

@vibl yeesh, noise-search определенно является виновником длинных сборок ...

~/Projects/yarn-test 🐒   yarn add noise-search
yarn add v1.5.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 73 new dependencies.
✨  Done in 426.15s.

более 7 минут на MacbookPro 😢

В любом случае, я установил noise-search затем запустил yarn add left-pad с кодом из # 5470, и это _не_ вызвало перестройку, так что я думаю, вам должно быть хорошо, когда мы получим это слияние 👍

Благодаря :-)

Должен ли я проверить Yarn через несколько дней, несколько недель или несколько месяцев?

Я только что обнаружил, что эта ошибка с тем же самым проектом на том же ноутбуке (двойная загрузка) не возникает в Windows 10. Но она присутствует в последних трех версиях Debian: Ubuntu, Arch Linux и Fedora. Странно. Еще не пробовал MacOS, но, похоже, у некоторых тоже есть проблемы.

@vibl Я не уверен, когда будет наш следующий релиз (я не участвовал в этом планировании)

@nnmrts да, я обнаружил, что это особенность ОС. Из моих комментариев в № 5470:

в linux с узлом 8, когда файлы копируются из кеша в node_modules, метки времени обновляются. yarn решает, что файлы разные, и отмечает новую ссылку.
Однако это происходит только на Linux node 8.
это потому, что Node v8.5 представил fs.copyFile, который делал копии намного быстрее. IIRC, который подключается к собственной копии файловой системы, поэтому это объясняет, почему она работает по-разному в разных ОС и только в узле 8.

@ rally25rs @nnmrts Это определенно не специфическая вещь для MacOS. Также происходит на моем ПК с Win10

@stereokai Ну, в этом вопросе нет ничего конкретного. Иногда пакеты необходимо перекомпилировать, а люди все еще думают, что это ошибка, и размещают ее здесь. Без надежного воспроизводимого репо для каждой ОС мы ничего не можем знать.

Может помочь локальное кеширование встроенных модулей (из # 5314) ?:

Добавьте в проект .yarnrc со следующим:

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

После первой установки готовые модули будут жить в ./<your-offline-mirror-path>/prebuilt . yarn.lock также обновляется с предварительно созданными вариантами

Вытащил последнюю 66a0143a753cd4ade1a0fffee2174890d564c129, и вроде работает нормально😎

ВСЕ ЕЩЕ повторно загружать двоичный файл.

• узел v6.13.1
• пряжа v1.6.0-20180327.1507
• ОС: Ubuntu 17.10 Linux 4.13.7-041307-generic
• ~ / .yarnrc:

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

yarn add node-sass
yarn remove node-sass
yarn add node-sass

В четверг, 29 марта 2018 г., в 2:30, Эндрю Лейн [email protected]
написал:

Локальное кэширование встроенных модулей (из # 5314
https://github.com/yarnpkg/yarn/pull/5314 ) может помочь ?:

Добавьте .yarnrc в свой проект со следующим:

пряжа-офлайн-зеркало "./"
экспериментальный пакет сценария пакеты в зеркале правда

После первой установки готовые модули будут жить в
.// сборный. yarn.lock также обновлен
с готовыми вариантами

Вытащил последнюю 66а0143
https://github.com/yarnpkg/yarn/commit/66a0143a753cd4ade1a0fffee2174890d564c129 ,
и вроде работает нормально😎

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

@snowyu вы удалили yarn.lock, node_modules и yarn cache clean ? Заполняется ли ./yarn-offline-mirror/prebuilt после установки?

Это новый проект в темп. Да, я вижу файл node-sass-4.8.3.tgz в папке кеша.
Теперь я запускаю yarn cache clean . НО ВСЕГДА загружайте двоичный файл повторно * .

Баш

пряжа init -y
пряжа добавить node-sass
пряжа добавить v1.6.0-20180327.1507
info Файл блокировки не найден.
[1/4] Обработка пакетов ...
[2/4] Получение пакетов ...
[3/4] Связывание зависимостей ...
[4/4] Сборка новых пакетов ... Загрузка двоичного файла с
успех Сохраненный файл блокировки.
успех Сохранено 152 новых зависимости.
Совершено 11.98с.

пряжа добавить node-sass
пряжа добавить v1.6.0-20180327.1507
[1/4] Обработка пакетов ...
[2/4] Получение пакетов ...
[3/4] Связывание зависимостей ...
[4/4] Сборка новых пакетов ... Загрузка двоичного файла с
успех Сохраненный файл блокировки.
успех Сохранена 1 новая зависимость.
info Прямые зависимости
└─ [email protected]
info Все зависимости
└─ [email protected]
Совершено в 13.45с.
``

Хорошо, я сделал простое репозиторий git, чтобы воспроизвести эту ошибку.

https://github.com/vlmonk/yarn-bug-test

yarn выполняет ненужную перестройку ttf2woff2 когда я пытаюсь добавить нулевую зависимость left-pad

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
yarn
[ ... building binary package here ... ]
yarn add left-pad
[ ... rebuilding binary packages here ... ]

Я могу воспроизвести это как в системе OSX хоста, так и в контейнере докеров с последним изображением node

NPM корректно работает в этом случае:

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
npm i 
[ ... building binary package here ... ]
npm i left-pad
[ ... don't rebuild binary packages here ... ]

Моя версия пряжи 1.5.1

@vlmonk это все еще происходит, если вы клонируете https://github.com/rally25rs/yarn из @ rally25rs и используете код из # 5470 (ветка fix-linking-rebuilding-uws-932 )?

@karlhorky да, пряжа все еще восстанавливает ttf2woff2 после добавления left-pad

# which yarn
yarn: aliased to node /Users/monk/work/yarn/lib/cli/index.js
# yarn --version
1.6.0-0

Пакет ttf2woff2 поставляется с файлами, которые изменяются на этапе сборки. При следующем запуске yarn видит, что эти файлы были изменены, и переустанавливает пакет.

Yarn должен лучше справиться с этой ситуацией: он должен видеть, что эти файлы были изменены на этапе сборки, и он должен принимать эти измененные файлы как «правильные» файлы, а не рассматривать их как причину для переустановки.

Я проверил это с помощью дополнительного журнала (https://github.com/sth/yarn/tree/trace-rebuild). При первой установке он показывает:

build artifacts for ttf2woff2
  modified file: build
  modified file: build/Makefile
  modified file: build/Release
  modified file: build/Release/.deps
  modified file: build/Release/.deps/Release
  modified file: build/Release/.deps/Release/addon.node.d
  modified file: build/Release/.deps/Release/obj.target
  modified file: build/Release/.deps/Release/obj.target/addon
  modified file: build/Release/.deps/Release/obj.target/addon/csrc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/addon.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/backward_references.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/block_splitter.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode_parallel.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/entropy_encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/histogram.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/literal_cost.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/metablock.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/streams.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/font.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/glyph.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/normalize.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/table_tags.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/transform.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/variable_length.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_common.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_enc.o.d
  modified file: build/Release/.deps/Release/obj.target/addon.node.d
  modified file: build/Release/addon.node
  modified file: build/Release/obj.target
  modified file: build/Release/obj.target/addon
  modified file: build/Release/obj.target/addon/csrc
  modified file: build/Release/obj.target/addon/csrc/addon.o
  modified file: build/Release/obj.target/addon/csrc/enc
  modified file: build/Release/obj.target/addon/csrc/enc/backward_references.o
  modified file: build/Release/obj.target/addon/csrc/enc/block_splitter.o
  modified file: build/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode_parallel.o
  modified file: build/Release/obj.target/addon/csrc/enc/entropy_encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/histogram.o
  modified file: build/Release/obj.target/addon/csrc/enc/literal_cost.o
  modified file: build/Release/obj.target/addon/csrc/enc/metablock.o
  modified file: build/Release/obj.target/addon/csrc/enc/streams.o
  modified file: build/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/obj.target/addon/csrc/woff2/font.o
  modified file: build/Release/obj.target/addon/csrc/woff2/glyph.o
  modified file: build/Release/obj.target/addon/csrc/woff2/normalize.o
  modified file: build/Release/obj.target/addon/csrc/woff2/table_tags.o
  modified file: build/Release/obj.target/addon/csrc/woff2/transform.o
  modified file: build/Release/obj.target/addon/csrc/woff2/variable_length.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_common.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_enc.o
  modified file: build/Release/obj.target/addon.node

Файл пакета https://registry.npmjs.org/ttf2woff2/-/ttf2woff2-2.0.3.tgz действительно содержит эти файлы.

Мы видим это и в OS X, добавление любого пакета с yarn add запускает перекомпиляцию любых зависимых пакетов. У нас есть пакет node-gyp с собственным кодом, он занимает более 1 минуты каждый раз, когда добавляется новый пакет, а в собственном модуле еще не так много кода (будет намного хуже). Это пряжа 1.5.1.

Мы используем yarn add ../a с относительными путями, если это имеет значение.

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

Это пряжа 1.5.1.

Эта проблема была исправлена ​​в версии 1.6.0, которая вышла совсем недавно.

Я до сих пор вижу это с 1.6. С момента перехода с npm на yarn давным-давно uws как всегда перестроен (или по крайней мере yarn застрял на uws на примерно 5-10 секунд).

Действия по воспроизведению:

1. $ пряжа устарела
2. выберите устаревший пакет
3. $ yarn upgrade [пакет]

@grantila, можете ли вы предоставить полный package.json или репозиторий с шагами, которые воспроизводят это с помощью Yarn 1.6.0 ?

это все еще происходит в 1.6.0

вы можете воспроизвести это с помощью https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784

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

"dependencies": {
    "bufferutil": "3.0.4",
    "chance": "1.0.16",
    "discord.js": "11.3.2",
    "dog-facts": "1.0.3",
    "erlpack": "discordapp/erlpack",
    "flickr-sdk": "3.7.0",
    "html-entities": "1.2.1",
    "node-opus": "0.2.7",
    "snekfetch": "4.0.0",
    "sodium": "2.0.3",
    "utf-8-validate": "4.0.1"
  }

После их установки я добавил пакет unescape , который вызвал перестройку sodium . Затем я удалил его, что вызвало перестройку того, что казалось каждым пакетом, который нужно было скомпилировать. Добавление этого простого пакета заняло 36 секунд, а удаление - 100 секунд!

РЕДАКТИРОВАТЬ: используя Node 8.11.1 и пряжу 1.6.0 в Debian Stretch.

@arcanis @ rally25rs просит повторно открыть проблему, многочисленные сообщения об этом все еще происходят, даже с объединенным исправлением.

Думаю, это скорее проблема @ rally25rs :)

@grantila и upgrade _всегда_ пересобирают все. Это сделано намеренно. npm делает то же самое (я упоминаю об этом в комментарии где-то в этой длинной цепочке), хотя потенциально мы могли бы попытаться прекратить это делать. Я не уверен, какие последствия это может иметь.

Все остальные:

В # 5680 я указываю, что это все еще происходит, если пакет удаляет свои собственные файлы _ (ну почему они делают эти вещи 😿) _, а yarn не отслеживает это нигде (мы отслеживаем, какие файлы создаются или изменяются), поэтому он просто думает, что в пакете отсутствуют файлы, и перестраивает его.

Я полагаю, мы можем снова открыть это, но это было исправлено для большинства пакетов. Если кто-то хочет добавить к этому «я тоже», _пожалуйста_ либо предоставьте свой package.json, либо конкретно укажите, какой пакет постоянно перестраивается, так как у вас могут быть некоторые зависимости, которые перестраиваются, а некоторые - нет.

Сделать пиар для этого может любой желающий! (см. мои отладочные комментарии в # 5680)

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

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

Я согласен с @ james-rabbit

Ага, ты прав. Я собираюсь заблокировать его, чтобы ответ @ rally25rs оставался видимым.

Если у вас проблема с собственными пакетами:

• Если это происходит с каждой собственной зависимостью, откройте общую проблему. Эта проблема должна была быть решена, поэтому я не ожидаю увидеть ее в ближайшее время - тем не менее, если вы можете предоставить шаги по воспроизведению, не стесняйтесь открывать новую проблему (и вы можете ссылаться на нее, если хотите).

• Если это происходит с одной конкретной собственной зависимостью, также откройте проблему, но не забудьте указать имя зависимости в заголовке (как объяснялось, разные пакеты могут быть перестроены по разным причинам - сохранение одной проблемы для каждого из них будет чтобы всем было проще делиться информацией).