<p>Установка пряжи иногда завершается ошибкой `ENOENT: нет такого файла или каталога`</p>

Интересно, значит, он не работает только на Travis, но работает при локальном тестировании? Это очень странно, учитывая, что Docker должен обеспечивать согласованность среды.

@ Daniel15 Я правильно понимаю ...

Я понизил версию узла до 6, но он все еще не работает на Трэвисе. Я добавил флаг --verbose к yarn install и все, что у меня было, было

verbose Performing "GET" request to "https://registry.yarnpkg.com/spawn-wrap/-/spawn-wrap-1.3.4.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/yargs/-/yargs-6.6.0.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/yargs-parser/-/yargs-parser-4.2.1.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/fibers/-/fibers-1.0.15.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/selenium-standalone/-/selenium-standalone-5.11.2.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/tcp-port-used/-/tcp-port-used-0.1.2.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/babel-runtime/-/babel-runtime-5.8.38.tgz".
verbose Error: ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol'
    at Error (native)
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol'".

Я открыт для идей, как это отладить.

Переход на пряжу 0.18.1, похоже, решил это для меня. Похоже, что у 0,19 может быть регресс; см. # 1834

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

$ time yarn --frozen-lockfile
yarn install v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/builds/linagora/petals-cockpit/yarncache/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/src'".
info If you think this is a bug, please open a bug report with the information provided in "/builds/linagora/petals-cockpit/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

real    0m9.812s
user    0m7.596s
sys 0m0.932s

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

Важный момент: кеш был пуст!

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

yarn install v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-beta.8.tgz: EEXIST: file already exists, mkdir '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/src/metadata'".
info If you think this is a bug, please open a bug report with the information provided in "/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

А с пряжей 0,21,2:

yarn install v0.21.2
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-beta.8.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/bundles/core.umd.js'".
info If you think this is a bug, please open a bug report with the information provided in "/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Это ужасно!

И я согласен с @twooster, что 0.18.1 работает нормально!

@ Daniel15 он тоже не работает локально. Собственно, у меня НИКОГДА не работает, когда кеш пуст!

@victornoel недавняя ошибка могла быть https://github.com/yarnpkg/yarn/issues/2714

@bestander Я тогда пробовал 0.19.1, и это не сработало ...

Я повторил попытку, и теперь ошибка:

• не появляется с пустым кешем, но появляется в следующем случае (я очень надеюсь, что это можно воспроизвести…):
  
  
  
  • rm -rf кеш пряжи
  
  
  • клон https://gitlab.com/linagora/petals-cockpit.git
  
  
  • касса 5f31ccb4b2357201baa50539b30702cffceb6992
  
  
  • запустить пряжу в каталоге frontend
  
  
  • кассир
  
  
  • снова запустить yarn в каталоге frontend
  
  
  • Я получаю: error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, utime '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core/testing.js'". (я использую свой реестр, но то же самое происходит и без него)
  
  
• появляется с пряжей 0,21,2, 0,19,1, но не с 0,18,2

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

(на самом деле, я просто попробовал еще раз и воспроизвел ошибку с пустым кешем и пряжей 0.21.2, хотя раньше этого не было, возможно, где-то еще есть файл, который является источником этой проблемы, и его нет в кеш?)

@bestander Я все равно буду тестировать пряжу, как только # 2744 будет доступен в качестве ночной сборки :)

Напишите мне, если я могу помочь.
Лучшее действие - отправить PR со сломанным (и пропущенным) тестом e2e.

@bestander ну нет, я все еще получаю такие ошибки, как:

➜  frontend git:(master) ✗ yarn
yarn install v0.22.0-20170227.1509
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/facade/lang.d.ts'".

или же:

➜  frontend git:(master) ✗ yarn
yarn install v0.22.0-20170227.1509
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/typescript/-/typescript-2.2.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-typescript-2.2.1-4862b662b988a4c8ff691cc7969622d24db76ae9/lib/typescriptServices.js'".

Я посмотрю, смогу ли я сделать тест e2e.

@bestander в любом случае я могу получить полную трассировку ошибки?

Я вижу это только в yarn-error.log:

Trace: 
  Error: http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.es5.js'
      at Error (native)

Немного бесполезно :)

Подробная ошибка:

{ Error: http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js'
    at Error (native)
  errno: -2,
  code: 'ENOENT',
  syscall: 'lstat',
  path: '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js',
  fstream_type: 'File',
  fstream_path: '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js',
  fstream_class: 'FileWriter',
  fstream_stack: 
   [ '/home/vnoel/Linagora/Petals/dev/git/yarn/node_modules/fstream/lib/writer.js:285:28',
     '/home/vnoel/Linagora/Petals/dev/git/yarn/node_modules/graceful-fs/polyfills.js:284:29',
     'FSReqWrap.oncomplete (fs.js:123:15)' ] }

Не знаю точно, что с этим делать ... это происходит в package-fetcher.js , точно в строке 56, но у меня проблемы с поиском источника ...

Это кажется глупым, но я чувствую, что он терпит неудачу только тогда, когда мое сетевое зеркало npm (связующее звено сонатипа в моей компании) отражает артефакт @angular/core . Если этого не произошло, все идет хорошо, а затем происходит сбой на другом артефакте, который уже зеркалирован (в данном случае typescript ).

Если я вручную удалю артефакт с зеркала нексуса, он работает!

Так что… это немного похоже на то, что yarn не успевает, если что-то приходит слишком быстро ^^ потому что, когда я использую обычный реестр npm без зеркала, все обычно идет хорошо (у нас медленное интернет-соединение).
И это объяснило бы, почему он часто дает сбой в системах CI, потому что у них обычно очень быстрое подключение к Интернету ...

Это немного натянуто, чтобы сделать такой вывод, но это может помочь найти источник проблемы.
WDYT @bestander?

Для записи, я думаю, что ошибка возникает из- tar.Extract шага

Спасибо за дополнительные исследования, @victornoel , возможно, вы здесь что-то

Я могу воспроизвести сценарий из https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896.
Заглядывая в это.

я получил

error An unexpected error occurred: "https://registry.yarnpkg.com/typescript/-/typescript-2.2.1.tgz: ENOENT: no such file or directory, lstat '/Users/bestander/Library/Caches/Yarn/npm-typescript-2.2.1-4862b662b988a4c8ff691cc7969622d24db76ae9/lib/typescriptServices.js'".

Однако, если я просто попробую yarn install снова и снова, установка в конечном итоге завершится.
Похоже, расширение файла .tgz заканчивается ошибкой.

Обновить:

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

Некоторая помощь в выяснении того, почему удаление этих нескольких зависимостей (в моем случае машинописный текст и angular-core) вызывает ошибку, приветствуется.
Параллелизм? Ошибка в https://github.com/npm/node-tar?

@victornoel , можете ли вы воспроизвести ошибку с помощью yarn install --network-concurrency 1 ?

@bestander с --network-concurrency 1 ошибка не появляется (а без нее она появляется каждый раз).
Но каково значение этого параметра по умолчанию? Какое бы значение я ни выбрал (1, 2, 4, 8), он работает, а если я его вообще не поставлю, он не работает ...

По умолчанию 15, я могу воспроизвести проблему с параллелизмом 15 с чистой проверкой https://gitlab.com/linagora/petals-cockpit.git#075bac4c54fee466568c000c7ffe8025f593e212 .

Отличные новости! Еще один шаг к решению и обходному пути :)

Некоторые результаты.

TL; DR У меня нет идей, как это исправить навсегда, для этого нужны более глубокие знания Node.js.

1. Сеть можно исключить из возможных проблем.
   Я установил автономное зеркало для файлов .tgz в yarn.lock и могу воспроизвести проблему с пакетами, установленными с диска.

Проблема заключается в распаковке / распаковке потока в коде сборщика архивов.

1. Я пробовал другую библиотеку, которая извлекает tar - https://github.com/mafintosh/tar-fs против текущего https://github.com/npm/node-tar/. Оба они терпят неудачу одинаково.
   Немного глубже - исключения происходят в узле при выполнении нескольких операций mkdirp

Error: ENOENT: no such file or directory, chmod '/Users/bestander/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/di/injector.d.ts'
  errno: -2,
  code: 'ENOENT',
  syscall: 'chmod',
  path: '/Users/bestander/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/di/injector.d.ts' }

Я думаю, что core-4.0.0 и typescript-2.2.1 не работают, потому что у них довольно много файлов и глубоких структур папок, и они не могут быть установлены при выполнении многих одновременных операций mkdir / copy.

Каждый раз происходит сбой другого системного вызова: chmod, rmdir, mkdir, lstat, utime.

И в коде библиотек это не заметно.

1. Не работает то же самое на узлах 4, 6 и 7.

2. Я не смог воспроизвести ошибку с параллелизмом, установленным на 8, поэтому я отправлю PR, чтобы уменьшить сетевой параллелизм по умолчанию.

1. Мне было интересно, как параллелизм влияет на скорость установки.

5.1. Используя offline-mirror (без загрузки), на моем MBPro 13 "очистите кеш и используйте node-tar для распаковки файлов.
Параллелизм 12 - сбой
Параллелизм 8-18 секунд
Параллелизм 4 - 18 секунд
Параллелизм 2 - 21 секунда

5.2. Используя offline-mirror (без загрузки), на моем MBPro 13 "очистите кеш и используйте tar-fs для распаковки файлов.
Параллелизм 12-15 секунд
Параллелизм 8-15 секунд
Параллелизм 4-17 секунд
Параллелизм 2 - 18 секунд

5.3. Загрузка пакетов из Интернета на моем MBPro 13 ", очистка кеша и использование tar-fs для распаковки файлов.
Параллелизм 12 - сбой один раз
Параллелизм 8 - 21 секунда
Параллелизм 4 - 23 секунды
Параллелизм 2 - 34 секунды

Похоже, что установка concurrency на 8 достаточно безопасна, также имеет смысл переключить библиотеку tar.
Я свяжусь с PR.

Правильный способ исправить это - разветвить https://github.com/mafintosh/tar-fs и выполнить более умные операции с fs, например, использовать mkdir для каждой папки только один раз.

Сопровождающий tar-fs кажется активным, может быть, мы могли бы открыть там вопрос и посмотреть, что они знают / предлагают по этому поводу?

@victornoel , не могли бы вы сделать это, пожалуйста?

@bestander готово! mafintosh / tar-fs # 61 :)

Я столкнулся с этим сообщением об ошибке в похожем сценарии при тестировании yarn на моих агентах сборки jenkins.

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

@ProdigySim , как объяснено в # 2829 (который был объединен в yarn master), уменьшение сетевого параллелизма не оказывает большого влияния на производительность yarn. Вы можете просто установить его на 8, и все должно быть в порядке. В любом случае, даже при загрузке 8 зависимостей за раз, я не уверен, что большая часть диска будет соответствовать пропускной способности, поэтому вы точно не потеряете :)

@victornoel Спасибо за информацию. Я не уверен, что в моем случае будет достаточно просто уменьшения --network-concurrency , поскольку мы также будем запускать несколько экземпляров yarn параллельно.

Я могу воспроизвести эту проблему даже с помощью --network-concurrency 1 , но, может быть, мне стоит открыть для этого отдельную проблему?

Используя то же тестовое репо, которое вы указали выше:

#!/bin/bash
set -x # echo commands

# Clear yarn cache
rm -rf $(yarn cache dir)

# Clone the repo into two separate spots
git clone https://gitlab.com/linagora/petals-cockpit.git repo1
git clone https://gitlab.com/linagora/petals-cockpit.git repo2

# Run yarn on both in parallel
cd repo1/frontend && yarn --network-concurrency 1 &
cd repo2/frontend && yarn --network-concurrency 1 &

Это приводит меня к ошибке каждый раз (пока 4 из 4)

error An unexpected error occurred: "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.2.tgz: 
ENOENT: no such file or directory, lstat '/Users/<snip>/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.2-59535050e5d0e6141417186eee571296f8e9c3d0/@angular/core.es5.js'".

На пряжи 0.21.3, узел v4.5.0, OSX 10.11.6

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

@ProdigySim
Это отдельная, но связанная проблема, вызванная глобальным кешем загрузки Yarn. Обходной путь - создать отдельный кеш для каждого каталога.

Вы все еще можете работать с --network-concurrency 8 . (На самом деле у меня нет проблем с неограниченным параллелизмом в сети.)

Больше контекста здесь .

@bestander, как ни странно, сегодня проблема снова возникла (вызвана tar для новой версии angular ^^) даже с параллелизмом в сети на 8, но только на моем CI ... Я переместил его на 2, и он работает (и я не Мне действительно все равно, требуется ли еще несколько секунд для загрузки зависимостей, так что пока все в порядке).
Похоже, что мы не получаем отзывов от проекта tar-fs… К кому еще мы можем обратиться за помощью?

эта проблема возникает и в моих сборках Travis для OS X. Я очистил кеш и установил сетевой параллелизм, но ничего не помогло.

@kevingelion какое значение вы установили для сетевого параллелизма? быть решительным и установить что-то вроде 2, чтобы увидеть, не в этом ли проблема :)

@victornoel Я установил его на 1 и 2, и оба варианта привели к сбою. Я использовал yarn --mutex network и никаких кубиков.

@bestander следующие исправления взлома (редактировать: НЕ) проблему:

diff --git a/src/util/request-manager.js b/src/util/request-manager.js
index e0e134a2..995dac69 100644
--- a/src/util/request-manager.js
+++ b/src/util/request-manager.js
@@ -214,8 +214,7 @@ export default class RequestManager {
     }, params.headers);

     const promise = new Promise((resolve, reject) => {
-      this.queue.push({params, resolve, reject});
-      this.shiftQueue();
+      this.execute({params, resolve, reject});
     });

     // we can't cache a request with a processor

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

Спасибо, Виктор!

24 марта 2017 года в 18:07 Виктор Ноэль [email protected] написал:

@bestander https://github.com/bestander следующий хак исправляет
проблема:

diff --git a / src / util / request-manager.js b / src / util / request-manager.js
индекс e0e134a2..995dac69 100644
--- a / src / util / request-manager.js
+++ б / SRC / утилит / запрос-менеджер.js
@@ -214,8 +214,7 @@ экспорт класса по умолчанию RequestManager {
}, params.headers);

 const promise = new Promise((resolve, reject) => {

• this.queue.push ({параметры, разрешение, отклонить});
• this.shiftQueue ();
• this.execute ({параметры, разрешить, отклонить});
  });

 // we can't cache a request with a processor

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

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

да нет, это не так: D, но это немного улучшает ситуацию

Извините за ложное срабатывание, я слишком хотел сообщить о своих выводах :)

Это меняет ситуацию, потому что до того, как я мог запускать yarn много раз, и он никогда не смог бы загрузить зависимость angular-core или машинописный текст (всегда эти), но там он не удался в первый раз и преуспел во второй раз, и я забыл удалить кеш между моими попытками, поэтому я думал, что он работает.

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

Я тоже сталкиваюсь с этим в наших сборках CI. После долгого тестирования я наконец-то смог воспроизвести локально.

Опять же, иногда это работает, но часто дает сбой из-за одной из следующих ошибок (что создает впечатление, что где-то есть какое-то состояние гонки):

• ENOENT: no such file or directory, lstat 'cache/directory/some-file'
• EEXIST: file already exists, mkdir 'package-name'

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

Не уверен, что это вообще поможет ... Я рад попытаться помочь чем могу!

Изменить: не уверен, что это полезно или нет, но пакет верхнего уровня указан в формате "git+ssh://[email protected]/org/package.git#v1.0.0" , и в ошибке загружаемая подзависимость выглядит так, как будто она загружается через https с URL-адресом "https://codeload.github.com/org/package/tar.gz/ljasdf08i234098aifj" .

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

Нашел, До.

В примере из https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 Yarn имеет дублирующиеся пакеты, которые загружаются и извлекаются параллельно.
Дублированные - @angular/core/-/core-4.0.0-rc.1 и typescript/-/typescript-2.2.1.tgz .

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

Никакого волшебства на уровне ОС или извлечения tar.

Ха- ха, отличная работа,

Потрясающая работа @bestander : tada :! Запуск как https://github.com/yarnpkg/yarn/pull/3090, так и https://github.com/yarnpkg/yarn/pull/3106 был тем, что помешало нам использовать Yarn.

благодаря!

У меня возникла проблема с установкой модуля prop-types. Каждый раз, когда я пытался установить его, ENOENT для другого файла. Для меня проблема исчезла после установки npm 5.0.2

$ yarn add prop-types
yarn add v0.21.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/prop-types/-/prop-types-15.5.10.tgz: ENOENT: no such file or directory
....

$ npm -g install npm

# whoops, looks like npm installed itself to different location than apt-get did
$ npm -v 
3.5.2

# remove the cached link from shell so the right version can surface
$ hash -d npm
$ npm -v
5.0.2

$ yarn add prop-types
... properly installs prop-types as expected

@skylize Вероятно, это совпадение - Yarn вообще не использует клиент npm, поэтому версия npm вообще не влияет на выполнение Yarn.

Это приводит к тому, что мои сборки Travis почти каждый раз терпят неудачу с несколькими разными пакетами. Есть ли решение?
error An unexpected error occurred: "https://registry.yarnpkg.com/apollo-client/-/apollo-client-1.8.0.tgz: ENOENT: no such file or directory, utime '/var/lib/jenkins/.cache/yarn/v1/npm-apollo-client-1.8.0-3b5d1976a06a0f82b2fc66fe71754868193dadb9/flow-typed/npm/webpack_vx.x.x.js'".

@Redmega
То же самое здесь, но это работает:

yarn install --network-concurrency 1

Какую версию вы используете? Это уже должно быть исправлено ...

Le 8 août 2017 18:37, "Ben Merckx" [email protected] автор:

@Redmega https://github.com/redmega
То же самое здесь, но это работает:

yarn install --network-concurrency 1

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

@victornoel Я использую v0.27.5 на машине jenkins, как и мой локальный.

Попробуйте ночные выпуски: https://yarnpkg.com/en/docs/nightly

Удаление файла yarn.lock и yarn install устранило проблему для меня.

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

@ajcrites @Redmega @headione @benmerckx, вам следует открыть другую проблему, если вы столкнулись с такой проблемой. Эта проблема точно исправлена, поэтому ваша проблема должна быть другой, даже если она проявляет похожие симптомы.
Я почти уверен, что у вашей проблемы больше шансов решить, если вы откроете другую проблему :)

У нас та же проблема, когда мы делаем параллельные сборки пакетов в Jenkins с Node 8.5. В настоящее время нам нужно придерживаться версии 0.27.5, пока не будет выпущена 1.0.2, исправляющая еще одну ошибку. Но все равно спасибо за поддержку и работу :)

@floric У меня такая же проблема с тем же контекстом (Jenkins + Parallel) с узлом 8.9.4. Решена ли ваша проблема?

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

@Niceplace, вы можете попробовать вариант --mutex : https://yarnpkg.com/en/docs/cli#toc -concurrency-and-mutex

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

У меня периодически возникают ошибки, когда ENOENT: no such file or directory, chmod и ENOENT: no such file or directory, lstat пытаются запустить yarn --mutex=network в корне монорепозитория с включенной рабочей областью Yarn ...

Кажется, это непоследовательно, я получаю либо одно, либо другое случайным образом. (1.6.0 и узел 8.11.1 и 9.11.1)

В частности, это ошибки:

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/Users/federicozivolo/test/packages/foobar/node_modules/detect-port-alt'".

и

error An unexpected error occurred: "ENOENT: no such file or directory, chmod '/Users/federicozivolo/test/packages/foobar/node_modules/jest/node_modules/.bin/jest'".

Я использую Yarn 1.7.0, и у меня аналогичная ошибка. Yarn, наконец, удается установить пакет после нескольких запусков.

An unexpected error occurred: "ENOENT: no such file or directory, lstat '/home/nieltg/.cache/yarn/v1/npm-npm-registry-client-8.5.1-8115809c0a4b40938b8a109b8ea74d26c6f5d7f1/lib/dist-tags/fetch.js'".

РЕДАКТИРОВАТЬ:
Я использовал yarn --network-concurrency 1 но ошибка все еще возникает у меня. Вот еще один образец файла error и yarn-error.log .

An unexpected error occurred: "ENOENT: no such file or directory, copyfile '/home/nieltg/.cache/yarn/v1/npm-core-js-2.5.7-f972608ff0cead68b841a16a932d0b183791814e/library/fn/date/now.js' -> '/mnt/c/Users/nieltg/Projects/React/React-16-Demo/node_modules/core-js/library/fn/date/now.js'".

Я использую Yarn 1.7.0. И я могу подтвердить, что со мной происходит то же самое.

Это совершенно случайно. Иногда это случается, иногда нет.

Последнее, что я получил:

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/root/.yarn-cache/v1/npm-@storybook/addon-actions-3.4.5-ba0d0c0c74357c0852e0b890b40

Я довольно часто вижу эту ошибку в Yarn 1.9.2 в подсистеме Windows для Linux.

Сегодня мы столкнулись с аналогичными проблемами со сломанными пакетами в Jenkins CI, где конвейер запускает yarn install параллельно. Несколько дней назад он работал нормально.
Исправлено с помощью yarn install --network-concurrency 1 (как указано в комментарии ). Производительность сильно не ухудшилась: ~ 7 сек -> ~ 8 сек.

Почему это было закрыто? Еще бывает:

Toms-MacBook-Pro-2:design-to-code tommedema$ yarn install
yarn install v1.9.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/Users/tommedema/projects/vg/design-to-code/packages/vgcli/node_modules/fs-extra'".
info If you think this is a bug, please open a bug report with the information provided in "/Users/tommedema/projects/vg/design-to-code/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Toms-MacBook-Pro-2:design-to-code tommedema$ yarn install --network-concurrency 1
yarn install v1.9.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 24.85s.

Обратите внимание, что в моем случае он исчез после выполнения yarn remove fs-extra и yarn add fs-extra в двух пакетах, эффективно обновляя эту зависимость.

Привет, я думаю, что нашел кое-что.

Я баловался с фрагментом кода, который рекурсивно перечислял файлы в указанном каталоге, используя fs и rxjs и я обнаружил, что он, скорее всего, потерпит неудачу, если я не буду ждать lstat вызов должен быть завершен перед вызовом другого lstat .

Я сделал простой пакет NPM, async-dirtyree-test , чтобы проверить, влияет ли это на вашу среду или нет. Я использую WSL, и обнаружил, что при обработке каталога, в котором много дочерних каталогов, например node_modules , возможен сбой, даже при небольшом количестве параллелизма.

Что ж, я до сих пор не знаю, связана ли эта проблема с WSL или нет. Прямо сейчас я не могу протестировать его в другой среде, например Linux, Mac и т. Д.

@nieltg Я хотел поделиться наблюдением, которое может помочь сформировать некоторые другие. Я использую Docker CE в WSL и Docker для Windows в качестве хоста, поэтому, когда я работаю с Docker в WSL, он кажется родным, но на самом деле хост изначально работает в мире Windows (так что мои файлы Dockerfiles фактически разрешают / c / foobar для c: / foobar в движке Docker). Это невероятно актуально, когда я использую привязки (внутри своего контейнера я монтирую свои локальные папки, так что / usr / src внутри контейнера в конечном итоге находится в c: / src / foobar (хотя в моем Dockerfile привязка будет отображаться как / c / src / foobar: / usr / src (видите автоматический перевод в пути?)

Это различие важно, потому что если я yarn install внутри одной из этих локальных папок, внутри моего контейнера, я получаю те же ошибки, что и непосредственно в WSL (без участия Docker).

С другой стороны .... если я просто mkdir /tmp/src && cp ./package.json /tmp/src/ && cd /tmp/src && yarn install , все будет хорошо, я могу просто mv /tmp/src/node_modules /c/src/foobar/ и я в порядке, так что это мой нынешний обходной путь. Имейте в виду, что /tmp существует как хранилище докеров (все операции ввода-вывода выглядят как один файл для ОС, потому что это фактически раздел в файле).

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

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

ОТКРЫТЬ

Недавно мы начали видеть такую ​​же ошибку при использовании yarn 1.10.1 при выполнении сборки CI в Azure Devops (ранее Visual Studio Team Services).

Фактическая зависимость, которая не работает, кажется случайной, насколько я могу судить, но yarn install периодически падает с ошибкой ENOENT: no such file or directory, open '/usr/local/share/.cache/yarn........ . Один раз сборка будет работать, в следующий раз произойдет сбой.

Нам кажется, что обходной путь yarn install --network-concurrency 1 работает.

@ Marclev78 такая же ошибка, но yarn install --network-concurrency 1 , похоже, не работает для меня

@ Marclev78 здесь то же самое, используя пряжу 1.10.1 в Azure Devops и получая сообщение об ошибке:

Error: https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz: ENOENT: no such file or directory, utime 'C:\Users\grpsshagent\AppData\Local\Yarn\Cache\v1\npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636\fn\string\pad-left.js'

Локально все работает как положено.

Я здесь, чтобы просто сказать, что тоже вижу эту ошибку.

error An unexpected error occurred: "ENOENT: no such file or directory, chmod '/usr/local/opt/asdf/installs/nodejs/8.12.0/.npm/bin/atob'".

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

К сожалению, эта проблема недавно начала преследовать и наши сборки CI; (

Предложение @rainabba сработало для меня на WSL

Я думаю, что операции записи и чтения также ведут себя по-разному. Даже с моими взломами я часто вижу ошибки при вызове узла fs.writeFile (хотя и обернутым в bluebird promisify). В каждом отдельном случае я могу подтвердить, что файл существует сразу после получения ошибки записи.

Я отправляю строку (содержимое XML-файла) в fs.writeFile (), что в конечном итоге вызывает следующее, но я не уверен, готов ли я взять на себя задачу, которая потребуется для настройки пользовательской сборки с дополнительной отладкой вывод из этого проекта C ++, чтобы я мог точно подтвердить, где на самом деле ощущается правильность в соответствии с узлом или этим модулем C ++.

Суть в том, что записи не завершаются ошибкой, но узел считает, что это так, поэтому сценарий, который имеет для меня смысл, заключается в том, что модуль c + plus работает успешно, но внутренне он проверяет файл и терпит неудачу, а затем отчеты не чувствуют вашу спину к узлу а затем происходит фактическая запись, так что, когда я иду проверить файл, он там, и ошибка не имеет смысла.

https://github.com/nodejs/node/blob/master/src/node_file.cc#L1795

@bestander есть ли способ повторно открыть эту проблему? Очевидно, что это не исправлено и затрагивает множество людей.

Подтверждение, что это все еще происходит с пряжей 1.12 и Azure Pipelines.

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

также бывает с пряжей 1.11, но не с 1.10

@bestander - Связано? https://github.com/yarnpkg/yarn/issues/6312

Если да, то здесь есть отличные репродукции.

Меня тоже затронула эта проблема.

Windows 10 / WSL

"ENOENT: no such file or directory, lstat '/mnt/c/Users/<username>/.cache/yarn/v4/<random_file_in_random_package>"

@limonte WSL какое-то время выдает ошибку , которая случайным образом выдает аналогичную ошибку при выполнении npm install / yarn install. Это происходило, когда на жесткий диск копировалось сразу много файлов. Убедитесь, что вы используете последнюю версию Windows (1809 или выше), поскольку это может быть вызвано не самой пряжей.

Мы также наблюдаем проблему Extracting tar content of undefined .

error https://registry.yarnpkg.com/eslint/-/eslint-4.19.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat '/tmp/yarncache.KTKNZ/v4/npm-eslint-4.19.1-32d1d653e1d90408854bfb296f076ec7e186a300/node_modules/eslint/lib/rules/no-compare-neg-zero.js'"

До сих пор мы смягчали это, используя только одно одновременное сетевое соединение с опцией --network-concurrency 1 . Но это скорее временное решение.

Я также могу подтвердить проблему на node:11.5.0-alpine .

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/app/node_modules/<random_pacakge>

Я заметил, что проблемы, похоже, были связаны с привязкой к версии пакетов репозитория git.

Воспроизводить

package.json

{
  "dependencies": {
    "react-navigation-core": "https://github.com/react-navigation/react-navigation-core",
    "react-navigation-hooks": "https://github.com/react-navigation/react-navigation-hooks"
  }
}

rm -rf node_modules && yarn cache clean && yarn

Обходной путь

Установка network-concurrency 1 каждый раз решает проблему.

Запуск npm install также работает.

Ноты

Удаление любого пакета из списка зависимостей не вызывает ошибки, равно как и использование опубликованных версий этих пакетов npm.

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

error https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod  '/home/cameron/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/library/modules/es6.reflect.apply.js'"

Вариации

• ENOENT: no such file or directory, chmod
• ENOENT: no such file or directory, stat
• ENOENT: no such file or directory, open
• EEXIST: file already exists, mkdir

Другие сообщения

info There appears to be trouble with your network connection. Retrying...

Действительно, я только что попытался воспроизвести, используя ваш package.json, и ошибка обнаружилась с первой попытки.

На каком уровне файловая система WSL взаимодействует с уже существующей файловой системой NTFS?

Вы, ребята, видите эту ошибку на смонтированном диске (/ c или / mnt / c для общих примеров) или за пределами одного из этих монтирований? Тестирование мышления альтернативно (например, ~ /.) И сообщение о какой-либо разнице?

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

[2/4] Получение пакетов ...
ошибка https://registry.yarnpkg.com/smartwrap/-/smartwrap-1.0.10.tgz : Не удалось извлечь содержимое tar неопределенного значения, файл выглядит как co
rrupt: "ENOENT: нет такого файла или каталога, откройте 'C: \ Users \ Administrator \ AppData \ Local \ Yarn \ Cache \ v4 \ npm-smartwrap-1.0.10-873ef350d
4ee1262fed4a80a55634d86ae1faf48 \ node_modules \ smartwrap \ ejq '"
info Посетите https://yarnpkg.com/en/docs/cli/global для документации по этой команде.

Вы, ребята, видите эту ошибку на смонтированном диске (/ c или / mnt / c для общих примеров) или за пределами одного из этих монтирований? Тестирование мышления альтернативно (например, ~ /.) И сообщение о какой-либо разнице?

Есть ли постоянно воспроизводимый случай, когда это происходит? Для меня это было довольно случайным образом, но я делаю все свои yarn add -ing на смонтированном диске, и это происходит часто.

Мне удалось воспроизвести https://github.com/yarnpkg/yarn/issues/2629#issuecomment -451638917 как на смонтированном диске, так и в ~ .

Я также попытался воспроизвести https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896, но ему не удавалось получить последний пакет, который, я уверен, не имеет отношения.

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

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

Что решило проблему для меня, так это переключение на другую сеть (просто использовал мою телефонную точку доступа вместо Wi-Fi), и все работало как по волшебству.

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

Могу подтвердить предыдущий комментарий. Установка network-concurrency не помогает. Переключение на точку доступа телефона устранило проблему для меня. Моя среда: Windows 10 (подсистема Linux - Ubuntu)

Я использую WSL и видел эту проблему с пакетом geo-tz , который имеет (немного странную) глубоко вложенную структуру папок. Я пробовал кое-что --network-timeout и --network-concurrency но ничего не добился. Однако, когда я включил длинные пути в Windows (см. Этот пост SuperUser ), теперь он работает нормально. Возможно, это поможет другим пользователям WSL. Редактировать, похоже, я заговорил слишком рано. Он работал, и связывание зависимостей стало быстрее, но теперь я снова вижу ту же ошибку.

Все еще ломается CI ....

У нас такая же проблема с Yarn 1.13.0, запущенным на машине Debian Linux, которая служит подчиненным узлом Jenkins. Обратите внимание, что у нас есть локальный сервер репозитория пряжи, поэтому во время сборки нет (или очень мало) физических загрузок с общедоступных серверов репозитория в Интернете.

yarn install v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://sqrep01.rsint.net:4873/lodash/-/lodash-4.17.10.tgz: ENOENT: no such file or directory, open '/home/jenkins/.cache/yarn/v4/npm-lodash-4.17.10-1b7793cf7259ea38fb3661d4d38b3260af8ae4e7/node_modules/lodash/.yarn-tarball.tgz'".

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

То же самое - это все еще проблема, даже в 1.14

Arguments: 
  /home/jeff/n/bin/node /usr/share/yarn/bin/yarn.js install

PATH: 
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Windows/System32/OpenSSH:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Program Files/Git/cmd:/mnt/c/Users/jkono/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/jkono/AppData/Local/hyper/app-2.1.2/resources/bin:/mnt/c/Users/jkono/AppData/Local/Programs/Microsoft VS Code/bin:/home/jeff/n/bin

Yarn version: 
  1.14.0

Node version: 
  10.15.1

Platform: 
  linux x64

Trace: 
  Error: ENOENT: no such file or directory, scandir '/mnt/c/Users/jkono/dev/PROJECT/node_modules/@storybook/addon-links/src'

Также:

➜  yarn cache dir
/mnt/c/Users/jkono/home/.cache/yarn/v4

Это довольно неприятно, мы видим это ежедневно на локальных и компьютерных машинах.

Подтверждение того, что это происходит постоянно в CI и для нас

Привет, подтверждаю, что эта проблема возникает в нашем CI.
Это проблема.

ошибка https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz : Не удалось извлечь содержимое tar неопределенного значения, файл выглядит поврежденным: «ENOENT: нет такого файла или каталога, chmod '/usr/local/share/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/es7/regexp.js' "
info Посетите https://yarnpkg.com/en/docs/cli/install для документации по этой команде.

Та же проблема стала возникать сегодня с одним из наших проектов с открытым исходным кодом.

Здесь вы можете увидеть неудачную сборку:
https://travis-ci.com/quid/refraction/builds/103692106

И тот, который преуспел (с --network-concurrency 1 ) здесь:
https://travis-ci.com/quid/refraction/builds/103693682

Надеюсь, это поможет диагностировать проблему!

Исходный код репозитория находится по адресу:
https://github.com/quid/refraction

Может быть, это кому-нибудь поможет:
В нашем Jenkins CI проблема заключалась в том, что Jenkins запускает параллельные сборки для наших приложений, а это означает, что два (или более) сценария оболочки запускают «установку пряжи» одновременно, при этом один из процессов сборки дополнительно _удаленный кеш пряжи полностью_ (с помощью «очистки кеша пряжи») перед запуском «установки пряжи». Конечно, это было фатальной проблемой для других процессов пряжи.
Затем мы удалили очистку кеша и изменили команду пряжи на
yarn install --verbose --prefer-offline --mutex file:/tmp/.yarn-mutex --network-concurrency 1
(_-- verbose_ не обязательно) и вставил
child-concurrency 1
в .yarnrc.
Теперь, когда запускаются параллельные сборки, yarn обнаружила, что другой процесс пряжи активен, и дождался его завершения. Это решило проблему отсутствия такого файла на нашем CI.

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

"connect-js-adapter-tls": "git+https://github.com/jeremyjs/connect-js-adapter-tls.git#v3.2.2",

Примечательные характеристики: частный пакет, URL-адрес github, git + https, ссылка на git с тегами

Шаги, которые воспроизводятся для меня:

1. С чистого листа: удалите все такие ссылки и запустите yarn install . Работает нормально.
2. Добавьте все такие ссылки обратно в мой package.json и снова запустите yarn install , он по-прежнему отлично работает при первом запуске после того, как эти ссылки добавлены обратно.
3. Выполнение yarn install дополнительных раз после этого работает до тех пор, пока нет изменений.
4. Однако измените любые пакеты и запустите yarn install и я получаю сообщение об ошибке.
5. Если затем удалить все такие пакеты и запустить yarn install я не получу сообщения об ошибке. Это возвращает нас к шагу 1.

Ошибка выглядит так:

error An unexpected error occurred: "ENOENT: no such file or directory, open '/Users/jeremy/Library/Caches/Yarn/v4/npm-connect-js-adapter-tls-3.2.2-0c97726d92c21183a7fb7334344eb5047e8bc158/node_modules/connect-js-adapter-tls/.yarn-metadata.json'".

Если я удалю все ссылки на теги git, я наблюдаю такое же поведение. Так что я считаю, что проблема не в этом.
т.е.

"connect-js-adapter-tls": "git+https://github.com/jeremyjs/connect-js-adapter-tls.git",

Запуск npm install также дает ошибку:

npm ERR! premature close

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/jeremy/.npm/_logs/2019-03-20T04_38_38_739Z-debug.log

npm-debug.log: https://gist.github.com/jeremyjs/e97381b16f46124ff7a9bd75ad79fd62

В качестве продолжения я использовал обходной путь создания сценария package.json для очистки этих пакетов из моего кеша перед установкой:

"install-clean": "yarn cache clean connect-js-adapter-tls connect-js-api connect-js-codec connect-js-encode-decode connect-protobuf-messages && yarn install"

Есть ли еще идеи, в чем может быть эта проблема?
В нашем случае мы запускаем yarn install как часть нашего CI (внутри контейнера докеров) и получаем те же ошибки. Мы пробовали yarn cache clean

Не уверен, что еще попробовать на этом этапе, и это останавливает наши сборки. 😬

Дэн, вы пробовали работать с --network-concurrency 1? У меня есть похожий
сценарий, и это решило мою проблему.
2 апреля 2019 г., 22:17, «Дэн Ван Брант» [email protected] написал:

Есть ли еще идеи, в чем может быть эта проблема?
В нашем случае мы запускаем yarn install как часть нашего CI (внутри docker
контейнер) и получить те же ошибки. Мы пробовали очистить кеш пряжи

Не уверен, что еще попробовать на этом этапе, и это останавливает наши сборки. 😬

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

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

Да уж. Это плохой недостаток. Вы можете попробовать с маленькими числами, такими как 2 или 4 ...
будет немного быстрее, но для меня единственное значение, которое сработало, было 1: /

Так что нам придется дождаться настоящего исправления, чтобы быть счастливым;)
4 апреля 2019 г., 00:26, "kunokdev" [email protected] написал:

@tevaum https://github.com/tevaum, который также решил проблему для нашего CI.
Это также значительно замедлило наши сборки. Так ужасно.

-
Вы получаете это, потому что вас упомянули.

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

Будет ли это когда-нибудь исправлено? Это сделало пряжу непригодной для использования более чем в одном из моих проектов.

Используйте параметр мьютекса, описанный здесь: https://yarnpkg.com/en/docs/cli/#toc -concurrency-and-mutex

Использование кеша Yarn небезопасно для использования в нескольких процессах, и это является причиной таких ошибок.

В качестве альтернативы вы можете установить папку кэша для каждого процесса, используя параметр --cache-folder, описанный здесь: https://yarnpkg.com/en/docs/cli/cache#change -the-cache-path-for-yarn-

Обратной стороной использования опции мьютекса является наличие только одного экземпляра пряжи на всей машине (другие будут ждать завершения активного процесса), что означает отсутствие параллелизма между заданиями CI.

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

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

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

Посмотрите этот пример минимального воспроизведения (по крайней мере, для моей OSX):

728 22:49:55 iMac ~/tmp/ynse$ ls
Dockerfile  package.json
729 22:49:58 iMac ~/tmp/ynse$ cat Dockerfile
FROM node
ADD . /app
WORKDIR /app
RUN yarn

730 22:50:00 iMac ~/tmp/ynse$ cat package.json
{
  "dependencies": {
    "react-navigation-core": "https://github.com/react-navigation/react-navigation-core",
    "react-navigation-hooks": "https://github.com/react-navigation/react-navigation-hooks"
  }
}
731 22:50:03 iMac ~/tmp/ynse$ docker build -t yt .
Sending build context to Docker daemon  15.87kB
Step 1/4 : FROM node
 ---> 39337023f8d4
Step 2/4 : ADD . /app
 ---> aa86b2d7f191
Step 3/4 : WORKDIR /app
 ---> Running in 83baa8603935
Removing intermediate container 83baa8603935
 ---> 80741f170292
Step 4/4 : RUN yarn
 ---> Running in 0718118bdcd6
yarn install v1.3.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
error An unexpected error occurred: "https://registry.yarnpkg.com/lodash/-/lodash-4.17.11.tgz: EEXIST: file already exists, mkdir '/usr/local/share/.cache/yarn/v1/npm-lodash-4.17.11-b39ea6229ef607ecd89e2c8df12536891cac9b8d'".
^C
732 22:50:23 iMac ~/tmp/ynse$

@nopik - Yarn 1.3.2 очень старая, и после этой версии было много исправлений. Вы пробовали использовать одну из последних версий Docker?

Действительно, образ узла был довольно старым. Вот свежий, загруженный несколько минут назад с узла dockerhub

Sending build context to Docker daemon  15.87kB
Step 1/4 : FROM node
 ---> a9c1445cbd52
Step 2/4 : ADD . /app
 ---> Using cache
 ---> 26ed37136c09
Step 3/4 : WORKDIR /app
 ---> Using cache
 ---> b2339e7d25af
Step 4/4 : RUN yarn
 ---> Running in cdbdfd9c373c
yarn install v1.15.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/v4/npm-lodash-4.17.11-b39ea6229ef607ecd89e2c8df12536891cac9b8d/node_modules/lodash'".
info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

@BYK Вы

Попробую через несколько дней, как только доберусь до своего компьютера (сейчас на мобильном телефоне). Выглядит очень странно, но каталог согласован. Попробую посмотреть, что происходит, спасибо за репродукцию.

@nopik - если присмотреться к журналу, действительно видно, что несколько экземпляров Yarn работают параллельно. Вы никогда не должны видеть одно и то же сообщение «Разрешение пакетов» дважды. Я не знаю, почему это происходит, но я уверен, что причина именно в этом.

@BYK Я действительно вижу, что в одном из этих пакетов есть "scripts": { "build": "yarn babel --out-dir dist && del-cli 'dist/**/__tests__' && yarn tsc --emitDeclarationOnly", "prepare": "yarn build" } в другом - другие сценарии, но все еще выполняется yarn в процессе подготовки. Они запускаются yarn во время установки?

@Nopik - не думайте, что это вызовет проблему, поскольку они просто запускают сценарии, а не другую установку. Также эти сценарии запускаются после фазы ввода-вывода. Должно быть что-то еще, запускающее несколько экземпляров yarn install .

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

Моя, по общему признанию, недостаточно информированная, теория состоит в том, что это что-то связано с этапом подготовки, и что yarn может запускать дополнительный экземпляр для «сборки» пакетов git. В частности, я уверен, что это две зависимости, каждая из которых зависит от общего пакета, который также необходимо построить. Yarn пытается быть умным и строить каждый отдельный пакет параллельно, но терпит неудачу, когда пытается собрать два пакета в одном месте кэша.

В нашем случае у нас нет нескольких экземпляров пряжи.

Наша система работает в собственном образе докера. Он имеет одиночную _ установку пряжи _. Он внезапно начал плохо себя вести, и теперь мы не можем работать без сетевого параллелизма, установленного на 1.
Если сама пряжа не изменилась за ночь, я не вижу проблем, кроме того, что пряжа сама по себе создает проблемы при определенных условиях.

Если вы попытаетесь решить эту проблему с помощью --mutex file или даже --mutex network , вы неизбежно (вероятно) просто столкнетесь с этой ошибкой https://github.com/yarnpkg/yarn/issues/6650 (открыто / не решено в течение 6 месяцев) 😢

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

Дэн, вы пробовали работать с --network-concurrency 1? У меня есть аналогичный сценарий, и это решило мою проблему.

@tevaum - Именно в этом и была проблема. БЛАГОДАРЯ!
У меня был сценарий, который, как я думал, никогда не будет запускать более одного экземпляра, но это было. 🤦‍♂️

@tevaum тоже решил за меня. Спасибо.

Если вы попытаетесь решить эту проблему с помощью --mutex file или даже --mutex network, вы неизбежно (вероятно) просто столкнетесь с этой ошибкой # 6650 (открытой / нерешенной уже 6 месяцев)

@sarink - Я тоже столкнулся с ошибкой опции мьютекса; спасибо, что упомянули об этом.

yarn говорит, что все в порядке.

PS C:\Users\chtacklind\Desktop\git\Project> yarn --verbose
yarn install v1.10.1
verbose 0.282 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.284 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.285 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.286 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.288 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.289 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.29 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.npmrc".
verbose 0.291 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.npmrc".
verbose 0.295 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.297 Checking for configuration file "C:\\Users\\.npmrc".
verbose 0.3 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.301 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.302 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.309 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.312 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.317 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.318 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.319 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.yarnrc".
verbose 0.326 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.yarnrc".
verbose 0.327 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.333 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.336 Checking for configuration file "C:\\Users\\.yarnrc".
verbose 0.346 current time: 2019-05-12T11:56:12.800Z
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.33s.

Тем не менее, при запуске yarn --check пытается построить, но всегда терпит неудачу.

Иногда с искаженными сообщениями об ошибках в конце:

PS C:\Users\chtacklind\Desktop\git\Project> yarn --check-files --network-concurrency 1 --mutex file:C:/.yarn-mutex --verbose
yarn install v1.10.1
verbose 0.286 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.288 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.289 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.29 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.291 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.292 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.293 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.npmrc".
verbose 0.294 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.npmrc".
verbose 0.295 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.296 Checking for configuration file "C:\\Users\\.npmrc".
verbose 0.302 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.304 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.305 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.306 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.307 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.308 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.311 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.313 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.yarnrc".
verbose 0.314 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.yarnrc".
verbose 0.315 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.316 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.317 Checking for configuration file "C:\\Users\\.yarnrc".
verbose 0.32 current time: 2019-05-12T11:56:20.033Z
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 2.344 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.npmrc".
verbose 2.344 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 2.345 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 2.345 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 2.348 Checking for configuration file "C:\\Users\\.npmrc".
verbose 2.348 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.yarnrc".
verbose 2.349 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.35 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.351 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 2.352 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.yarnrc".
verbose 2.353 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
verbose 2.358 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.yarnrc".
verbose 2.359 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
verbose 2.36 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.yarnrc".
verbose 2.361 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.yarnrc".
verbose 2.362 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.yarnrc".
verbose 2.363 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.364 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.366 Checking for configuration file "C:\\Users\\.yarnrc".
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 2.541 Performing "GET" request to "https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz".
verbose 3.263 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.264 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.265 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 3.266 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.268 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 3.27 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 3.271 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 3.273 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 3.278 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 3.279 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 3.28 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.281 Checking for configuration file "C:\\Users\\.npmrc".
verbose 3.283 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.285 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 5.007 Error: https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\lib\\tsserver.js'"nd\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc
    at MessageError.ExtendableBuiltin (C:\Program Files (x86)\Yarn\lib\cli.js:243:66)
    at new MessageError (C:\Program Files (x86)\Yarn\lib\cli.js:272:123)pData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
    at Extract.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:56849:14)a\\Local\\Yarn\\Cache\\v2\\.yarnrc".
    at Extract.emit (events.js:194:15)on file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
    at Extract.module.exports.Extract.destroy (C:\Program Files (x86)\Yarn\lib\cli.js:131115:17)nrc".
    at onunlock (C:\Program Files (x86)\Yarn\lib\cli.js:130992:26)nd\\AppData\\Local\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:43373:25rs\\chtacklind\\AppData\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:43339:23rs\\chtacklind\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:56799:13acklind\\.yarnrc".
    at FSReqWrap.oncomplete (fs.js:153:21)ile "C:\\Users\\.yarnrc".
error https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\lib\\tsserver.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\Users\chtacklind\Desktop\git\Project>

Иногда с разными ошибками:

...
[2/4] Fetching packages...
verbose 2.635 Performing "GET" request to "https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz".
verbose 3.465 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.466 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.467 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 3.468 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.469 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 3.47 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 3.471 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 3.473 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 3.474 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 3.48 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 3.481 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.482 Checking for configuration file "C:\\Users\\.npmrc".
verbose 3.483 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.485 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.486 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.49 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 3.492 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.493 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
verbose 3.494 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.yarnrc".
verbose 3.495 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
verbose 3.496 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.yarnrc".
verbose 3.497 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.yarnrc".
verbose 3.501 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.yarnrc".
verbose 3.503 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.504 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.505 Checking for configuration file "C:\\Users\\.yarnrc".
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 4.608 Error: EPERM: operation not permitted, unlink 'C:\Users\chtacklind\AppData\Local\Yarn\Cache\v2\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\.yarn-tarball.tgz'
error An unexpected error occurred: "EPERM: operation not permitted, unlink 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\.yarn-tarball.tgz'".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\chtacklind\\Desktop\\git\\Project\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\Users\chtacklind\Desktop\git\Project>

Обратите внимание, что два процесса пряжи запущены, хотя я указал --mutex .

Следует отметить, что у этого пакета есть зависимость от git, в которой необходимо выполнить шаг tsc prepare . Этот пакет также имеет зависимость от git, которая требует того же процесса. Понятно, что yarn пытается распаковать тот же пакет в то же место, и мы получаем состояние гонки.

Почему пряжа запускается в нескольких экземплярах, даже если не говорят?

В качестве обновления, использование yarn install --network-concurrency 1 --mutex network похоже, работает каждый раз, когда использование одного или другого параметра имеет тенденцию к успеху только в некоторых случаях.

Итак, каково решение этой проблемы?
Я использую пряжу 1.16 в Ubuntu Linux 18.04
И я все еще получаю это сообщение об ошибке:

error Произошла непредвиденная ошибка: «ENOENT: нет такого файла или каталога, lstat '/ home / user / workspace / project / packages / components / node_modules / source-map-support'».

Моя команда:

yarn install --check-files --frozen-lockfile --network-concurrency 1

И я получаю эту ошибку один раз в два раза: ((
PS: Я работаю в монорепозитории, поэтому я включил рабочие области пряжи
PPS:
Я дважды проверил
Добавление --mutex файла или --mutex network не помогает.

Единственное решение, которое я могу подтвердить, что работает - это скрипт

until
    yarn install --check-files --frozen-lockfile;
do
    echo "Surprise, surprise. Let's try again..."
done

:(

Fwiw, я смог переключиться на npm, не выполняя ничего, кроме поиска / замены yarn на npm , используя synp для преобразования yarn.lock в package-lock.json и работает npm install . Я думал, что это будет болезненный процесс, но npm значительно продвинулся, и мне потребовалось всего около 30 минут, и теперь он просто работает везде

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

Я подозреваю, что проблема заключается в том, что у вас есть дерево зависимостей с общими «листьями» / подсказками, которым требуется время для компиляции / установки (подготовки), и yarn пытается выполнить эту подготовку дважды, одновременно. Каждый экземпляр «подготовлен» в совместно используемом предсказуемом месте, и они не могут одновременно «писать» в одно и то же место (один удаляет файл, а другой ожидает, что он все еще там).

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

Это происходит, когда у вас одновременно работает несколько экземпляров пряжи. Вы можете использовать параметр --mutex описанный здесь: https://yarnpkg.com/en/docs/cli/#toc -concurrency-and-mutex

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

@cinderblock # 6650 кажется --ignore-scripts что также рекомендуется.

Если у вас есть другие зацепки, поделитесь ими, чтобы кто-нибудь, надеюсь, потратил больше времени на отладку.

@BYK Я не видел, чтобы кто-нибудь намеренно использовал yarn install внутри сценария install . Вы видели этот тривиальный package.json который вызывает эту проблему? Допустим, что-то в зависимых пакетах вызывает эту ошибку, и, возможно, у них есть скрытый install о котором вы говорите. Однако этот package.json отлично работает с npm ...

По теме, как / где рекомендуется --ignore-scripts ? Многие пакеты для работы полагаются на сценарии после установки.

Связано, как / где рекомендуется --ignore-scripts? Многие пакеты для работы полагаются на сценарии после установки.

О, я просто порекомендовал это здесь, и я думаю, что многие участники Yarn высказались по этому поводу. 😀 Большинство пакетов в порядке, но действительно есть несколько пакетов, которые полагаются на сценарии после установки.

Вы видели этот банальный package.json

Да, но даже "тривиальный" файл package.json может привести к очень большому дереву зависимостей, поэтому, говоря, что это тривиально, на самом деле мало что меняет, за исключением того, что я склонен интерпретировать его одним из следующих способов:

• пряжа слишком дрянная, поэтому она даже не может справиться с этим файлом _trivial_ package.json
• эту проблему можно воспроизвести с помощью файла _trivial_ package.json, но вы по-прежнему не можете / не исправляйте ее

где ни один из них не помогает, поэтому я стараюсь игнорировать этот ваш комментарий.

Что касается фактической проблемы, то для работы пряжи с мьютексом все экземпляры пряжи должны быть вызваны с флагом --mutex поэтому лучший способ узнать, решает ли это проблему, - добавить --install.mutex network в ваш .yarnrc файл (см. Https://yarnpkg.com/en/docs/yarnrc#toc-cli-arguments). Тем не менее, это может привести к тупиковой ситуации, если первоначальная установка запускает другую установку, при которой вторая установка будет ждать завершения основной, а основная будет заблокирована на этой запускаемой скриптом пряжи для завершения, поэтому я действительно не знать, как исправить эту проблему, кроме реализации системы кэширования, безопасной для потоков / процессов, что практически невозможно с примитивами блокировки, которые предоставляет node . Самая близкая вещь похожа на этот пакет с надлежащей блокировкой , но ни у кого из нас не было времени попробовать его. Я могу помочь вам, если вы хотите попытаться реализовать это в коде записи / чтения кеша.

@BYK Приношу свои извинения, если я так поступил. До этого я не видел способа надежно воспроизвести ошибку, даже если она все еще недостаточно очищена, чтобы устранить проблему. Это был весь мой импульс для этого комментария.

Простите за настойчивость, но я до сих пор не понимаю, как вариант мьютекса может быть решением. Я пробовал работать с мьютексом, и он по-прежнему выполнял пряжу одновременно. Может я ошибся в тестировании ? Я ожидал, что запуск yarn --mutex ... передаст эту опцию дочерним экземплярам (например, make ). Я также попробовал ваше предложение добавить --install.mutex network в мой файл .yarnrc но безрезультатно (те же ошибки). --verbose подтверждает, что параметры загружаются.

Может быть, мы могли бы подойти к этому с другой стороны? Что делает пряжа, чего не делает npm? Почему у npm нет такой же проблемы?

@BYK , использование флага mutex совершенно неприемлемо, потому что есть дополнительная ошибка пряжи, которая затем помешает вам _ никогда выполнять другую команду пряжи _... Это похоже на ваше решение «Я заблокировал свои ключи в моя машина "не волнуйся, я думал об этом! Просто воспользуйтесь этим удобным инструментом, чтобы взломать все окна и дверные замки, теперь ты никогда больше не сможешь запереть свою машину!" 🙄

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

@sarink

@BYK , использование флага mutex совершенно неприемлемо, потому что есть дополнительная ошибка пряжи, которая затем помешает вам когда-либо выполнить другую команду пряжи ...

Мне неизвестна такая ошибка, можете ли вы указать мне на нее, если о ней уже сообщалось? Способ --mutex заключается в том, чтобы предотвратить запуск любого другого экземпляра yarn использующего тот же мьютекс, до завершения первого. То, что вы говорите (а не ваше изображение), для меня звучит как «работает, как ожидалось».

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

Может быть, вам стоит уделить минуту размышлениям о внутреннем противоречии вашего собственного предложения: «делает пряжу совершенно непригодной для многих людей» и «она открыта уже два года». В этом выпуске всего 56 участников, в том числе ~ 5 разработчиков Yarn и 138 комментариев, большинство из которых связаны с одними и теми же вещами. Это не «много людей», это _ некоторые_ люди, и они, конечно, важны для них, но я вижу, что никто из них не считает важным отправить хотя бы одну строчку исправления кода и просто требовать исправлений для программного обеспечения, которое предоставляется полностью. бесплатно для них.

@cinderblock

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

Нечего прощать за настойчивость, это действительно нужно праздновать, поскольку вы пытаетесь решить проблему :)

Я ожидал, что запуск yarn --mutex ... передаст эту опцию дочерним экземплярам (например, make).

Я совершенно уверен, что это не передается.

Я также пробовал ваше предложение добавить сеть --install.mutex в мой файл .yarnrc, но безрезультатно (те же ошибки). --verbose подтверждает, что параметры загружаются.

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

Может быть, мы могли бы подойти к этому с другой стороны? Что делает пряжа, чего не делает npm? Почему у npm нет такой же проблемы?

Я ценю разностороннее мышление, которое говорит о том, что Yarn и npm настолько разные в том, как они работают, я не думаю, что здесь это действительно применимо. Если мы сможем определить, какой пакет запускает установку пряжи как часть их собственной установки, мы сможем найти решение. Может быть, вы можете заменить исполняемый файл yarn каким-нибудь сценарием bash, который регистрирует источник вызова, cwd и все переданные аргументы, а затем запускает yarn как обычно, чтобы получить полезную информацию отладки и продолжить оттуда?

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

Большое спасибо за сотрудничество с этим @cinderblock , очень признателен.

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

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

@BYK Ой! Я не рассматривал возможность того, что подпакет вызывает yarn ... в сценарии. Вы думаете, что причина, по которой npm install не терпит неудачу, заключается в том, что когда его зависимости запускают yarn ... работает только один экземпляр?

мне удалось решить проблему с запуском

yarn cache clean
rm ./yarn.lock
yarn install

Этот процесс, однако, занимает много времени, потому что он снова загружает все пакеты, потому что у вас а) больше нет кеша и ваш файл блокировки был удален.

Это может решить проблему на вашем локальном компьютере, но проблема с пряжей останется, если она будет использоваться на bitrise. Это чистый образ, с нуля. Параллелизм в сети требуется в любом случае, даже если запущен однонитевой процесс.

@BYK

В этом выпуске всего 56 участников, включая ~ 5 разработчиков Yarn и 138 комментариев, большинство из которых связаны с одними и теми же вещами.

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

Более того, исследуя (возможно) связанную проблему, я увидел довольно много людей с проблемами, которые, вероятно, были связаны. Прискорбно то, что многие из этих людей либо отказались от пряжи в целом, либо поглотили затраты на выполнение --network-cocurrency 1 при каждом изменении файла блокировки пряжи. Это именно то, что я делал для одного из своих проектов, пока наконец не понял, что это был вспомогательный сценарий.

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

Пряжа - это не тот проект, в который люди могут легко сесть. Это сложная система, которая выполняет множество задач асинхронно, что означает, что вы не можете просто запустить отладчик и подняться по стеку, чтобы посмотреть, что происходит. Таким образом, понять эту кодовую базу отнюдь не легко, а еще труднее изменить ее. Черт, к этому моменту я уже потратил несколько дней совокупного времени на чтение кода, и я все еще не чувствую себя достаточно уверенно, чтобы отправить даже простой патч с соответствующими тестами. Учитывая, что у меня более двух десятилетий опыта и что чтение кода - одна из моих специализаций, я бы не дал среднему разработчику больших шансов.

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

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

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

У меня есть пример пакета, который демонстрирует такое поведение здесь , хотя я не вижу там yarn install (если только bob build не делает это, хотя он также показал эту проблему, когда команда была "prepare": "node ./scripts/generate-mappings", ).

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

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

Обновление нашло обходной путь, который действительно работает ... подмодуль git, а затем укажите местоположение пакета в локальной папке. Не идеально, но работает.

У нас тоже есть эта проблема в CircleCI, и это большая проблема. Проблема, похоже, связана с использованием пакета, размещенного на github.com и, возможно, Linux (он работает на OSX). Опции mutex и network-concurrency ничего не делают.

"my-js-lib": " ssh: //[email protected] : dgobaud / my-js-ib # 1.0.0"

если я удалю, это будет работать в CircleCI. Локально он работает с ним на OSX с пряжей 1.17.0.

Но он не будет работать на CircleCI с узлом 12.8.1 и пряжей 1.17.3 (изображение круга circleci / node: latest)

Или с узлом 8.15.0 и пряжей 1.12.3 (круговое изображение circleci / node: 8.15.0)

#!/bin/bash -eo pipefail
yarn install --mutex network --network-concurrency 1
yarn install v1.12.3
[1/4] Resolving packages...
warning Resolution field "[email protected]" is incompatible with requested version "mixin-deep@^1.2.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^0.4.3"
[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...
$ cd functions && yarn install
yarn install v1.12.3
[1/5] Validating package.json...
[2/5] Resolving packages...
warning Resolution field "[email protected]" is incompatible with requested version "mixin-deep@^1.2.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.1"
[3/5] Fetching packages...
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error https://registry.yarnpkg.com/lodash/-/lodash-4.17.15.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/home/circleci/.cache/yarn/v4/npm-lodash-4.17.15-b447f6670a0455bbfeedd11392eff330ea097548/node_modules/lodash/_arrayReduceRight.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
info There appears to be trouble with your network connection. Retrying...
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Exited with code 1

--network-concurrency 1 завершается успешно, --network-concurrency 8 терпит неудачу, на circleCI / node: 10

Может ли кто-нибудь помочь мне понять, почему Yarn должен терпеть неудачу на EEXIST и EOENT?

В случае EEXIST я ожидаю, что Yarn предупредит об этом, а затем переопределит файл.
В случае EOENT я ожидаю, что Yarn создаст отсутствующую папку (что обычно является причиной проблемы).

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

Но какой смысл хранить эти ошибки? Они никому не нужны.

@BYK Извините, я только что видел ваш комментарий

Мне неизвестна такая ошибка, можете ли вы указать мне на нее, если о ней уже сообщалось? Способ --mutex заключается в том, чтобы предотвратить запуск любого другого экземпляра yarn использующего тот же мьютекс, до завершения первого. То, что вы говорите (а не ваше изображение), для меня звучит как «работает, как ожидалось».

Это ошибка: https://github.com/yarnpkg/yarn/issues/6650, как указано в https://github.com/yarnpkg/yarn/issues/2629#issuecomment -481297806 (который, как мне кажется, теперь похоронен под "показать больше истории" в этой ветке)

В этом выпуске всего 56 участников

Ну, я думаю, это справедливый момент

Эта ошибка все еще присутствует в yarn v1.19.1. Я не понимаю, почему Yarn Team не исправляет эту очень надоедливую ошибку.
вот мой .yarnrc и это не помогает:

save-prefix ""
--install.check-files true
--add.check-files true
--remove.check-files true
--install.frozen-lockfile true
--add.frozen-lockfile true
--remove.frozen-lockfile true
--install.mutex network
--install.mutex file

Я только что обнаружил, что запуск npx lerna clean && ./yarn-install-in-loop.sh помогает.
Очистка (удаление) всех каталогов node_modules в моем монорепозитории действительно помогает.

@gitowiec может подтвердить. Мои контейнеризованные вызовы yarn install представляют собой гонку данных в файловой системе, и каждая попытка ограничить yarn одним файлом .yarnrc терпит неудачу. Я сдаюсь и возвращаюсь к npm .

Я обнаружил, что моя проблема связана с зависимостями пакетов от репозиториев git на нескольких уровнях (например, мой пакет -> пакет git -> пакет git -> пакет git). Кроме того, кеш во время установки не работал хорошо по сравнению с npm (npm только проверял один раз, но пряжи проверяли несколько раз один и тот же пакет во время одной и той же установки).
Я возвращаюсь в npm. Хорошо работает с v6.

Как уже упоминалось выше, эта проблема все еще существует. Вот что мы добавили в наш config.yml для circleci, чтобы наши тесты прошли:
- run: name: Yarn Install source ~/setyarnpath.sh i=5; until yarn; do echo "Yarn failed. Retrying..."; ((i--)); if [[ "$i" == '0' ]]; then break; fi; done

У меня была такая же проблема. Используя macOS и docker-compose, с томом host [1], внутри которого был мой код И node_modules.

Изменен node_modules, чтобы он находился внутри анонимного тома, но я думаю, что именованный том также будет работать. И, похоже, теперь он работает нормально, а также НАМНОГО быстрее устанавливает зависимости.

Мой файл для создания докеров изменился с:

services:
  ...
  web:
    build: .
    volumes:
      - .:/home/example
    ports:
      - "3000:3000"
    ...

Кому:

services:
  ...
  web:
    build: .
    volumes:
      - .:/home/example
      - /home/example/node_modules
    ports:
      - "3000:3000"
    ...

[1] https://success.docker.com/article/different-types-of-volumes

Я вижу новую ошибку с недавним yarn которая, как мне кажется, является новым признаком этой проблемы.

yarn stdout [1/4] Resolving packages...
yarn stdout [2/4] Fetching packages...
yarn stderr error https://registry.yarnpkg.com/prettier/-/prettier-1.19.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "EEXIST: file already exists, mkdir '/home/pi/.cache/yarn/v6/npm-prettier-1.19.1-f7d7f5ff8a9cd872a7be4ca142095956a60797cb-integrity/node_modules/prettier'"
yarn stdout info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn stderr Process stalled
yarn stderr Active handles:
yarn stderr   - Socket
yarn stderr   - Socket
yarn stderr   - Socket
yarn stderr   - TLSSocket
yarn stderr   - TLSSocket
yarn stderr   - TLSSocket

Примечание: yarn stderr/out - это префикс, который моя программа дает для вывода пряжи в моем окружении.

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

Для справки, это происходит при установке после того, как я очищаю кеш пряжи и node_modules или обновляю одну конкретную зависимость пакета git.

Конкретная зависимость пакета - это зависимость другого пакета git, от которого я действительно зависим (оба имеют похожие шаги prepare которые зависят от TypeScript). Если я внесу изменения в эти зависимости для #master и сделаю yarn upgrade --latest , проблема возникнет (и при последующих yarn install .

Когда я обновляю этот подпакет вручную (в совершенно отдельную папку node_modules !), yarn install снова работает. Это заставляет меня думать, что yarn случайно использует кеш двумя процессами одновременно, и это вызывает проблемы, которые мы наблюдаем в этой проблеме.

Это случается со мной, когда я использую 2 или более пакетов, установленных зависимостью git. Каким-то образом в одном пакете выполняется несколько процессов, выполняющих сценарий prepare . Кроме того, он начинает давать сбой с npm также в последних выпусках.

Dependencies:
A -> B & C (both by git, with prepare script)
B -> C (by git, with prepare script)

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

Единственное решение, которое я вижу сейчас, - это перейти на npm.

@gregory В моем случае, я помню, в июне 2019 года yarn всегда заканчивал установку необходимых пакетов, даже если для этого требовалось 2-4 повторных все еще была быстрее, чем npm.

Я бы перезапустил его, пока пряжа не закончится, используя такие команды:

while ! yarn install; do echo --- ; done

Простым решением для нас было опубликовать частный пакет и использовать его вместо ссылки git. Все еще раздражает

while ! yarn install; do echo --- ; done

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

cc @arcanis

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

Быстрое, надежное и безопасное управление зависимостями.

Это ненадежно.
`` [3/5] Получение пакетов ...
ошибка https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Сбой при извлечении содержимого tar undefined, файл выглядит поврежденным: «ENOENT: нет такого файла или каталога, ссылка '/ app /.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lzache4.node.c -> '/app/yarn. /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-целостность / node_modules / lz4 / build / Release / obj.target / lz4.node '"
info Посетите https://yarnpkg.com/en/docs/cli/install для документации по этой команде.
[1/5] Проверка package.json ...
[2/5] Разрешение пакетов ...
[3/5] Получение пакетов ...
info Похоже, проблема с сетевым подключением. Повторная попытка ...
info [email protected] : Платформа "linux" несовместима с этим модулем.
info « [email protected] » - это необязательная зависимость и неудачная проверка совместимости. Исключение из установки.
info [email protected] : Платформа "linux" несовместима с этим модулем.
info « [email protected] » - это необязательная зависимость и неудачная проверка совместимости. Исключение из установки.
[4/5] Связывание зависимостей ...
[5/5] Создание новых пакетов ...
$ npm run prepare: mjs && npm run prepare: js

[email protected] подготовить: mjs /app/.cache/yarn/v6/.tmp/43563e016bb56318ebd76037a0f6ce2f.73d5f4dbffab6f6a27f26c6611e32662c98c2891.prepare
BABEL_ESM = 1 babel src -d. --keep-расширение-файла

Успешно скомпилировано 39 файлов с помощью Babel.

[email protected] подготовить: js /app/.cache/yarn/v6/.tmp/43563e016bb56318ebd76037a0f6ce2f.73d5f4dbffab6f6a27f26c6611e32662c98c2891.prepare
babel src -d.

Скомпилировано 39 файлов с помощью Babel.

[3/5] Получение пакетов ...
ошибка https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Сбой при извлечении содержимого tar undefined, файл выглядит поврежденным: «ENOENT: нет такого файла или каталога, ссылка '/ app /.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lzache4.node '->' /app/yarn. /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-целостность / node_modules / lz4 / build / Release / obj.target / lz4.node '"
info Посетите https://yarnpkg.com/en/docs/cli/install для документации по этой команде.
info Похоже, проблема с сетевым подключением. Повторная попытка ...

`` ''

Кто-нибудь знает, почему пряжа называется

error https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, link '/app/.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lz4.node' -> '/app/.cache/yarn/v6/npm-lz4-0.6.3-
  df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/lz4.node'"

когда правильный путь должен был быть:

/app/.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/lz4.node

кажется, пряжа почему-то добавляет obj.target/build/Release/ . Может быть связано с https://github.com/yarnpkg/yarn/commit/0e7133ca28618513503b4e1d9063f1c18ea318e5

У меня была такая же неприятная и трудная для отладки ошибка. В моем случае проблема заключалась в поведении yarn workspace вызванном разными версиями одной и той же зависимости в разных пакетах (в частности, ava версии 2 и 3). Только после того, как я обновил все вхождения ava до последнего, я перестал получать эту ошибку.

У меня 1.22.4 и я долго не мог решить эту проблему. В нашем monorepo есть несколько модулей, использующих одни и те же пакеты. Наконец, он был отсортирован, применив следующее:
1) Убедитесь, что вы используете одну и ту же версию пакета для всех модулей - это обязательно вызовет сбой, даже на devDependencies .
2) Закрепите все версии в монорепозитории во всех файлах package.json .

Могу еще подтвердить проблему на 1.22.4 . Первоначально это было mocha , и после того, как я убедился, что все пакеты используют одну и ту же версию, теперь я получаю ошибки, сгенерированные из camelcase которые я даже не использую в своем проекте - очевидно это от yargs , возможно, от Лерны.

error Произошла непредвиденная ошибка: «ENOENT: нет такого файла или каталога, lstat '/ code / project / src / packages / private-package / node_modules / camelcase'».

Могу я спросить, есть ли решение? Мы продолжаем удалять 20 node_modules и yarn.lock чтобы исправить это.

Могу я спросить, есть ли решение? Мы продолжаем удалять 20 node_modules и yarn.lock чтобы исправить это.

Я лично перешел на lerna по поводу работы с рабочим пространством.

Совершенно уверен, что нынешняя Лерна просто переходит к Ярну.

Мне удалось обойти свои проблемы, добавив конфигурацию nohoist для пакетов Ember - в моем текущем env используется более старая версия Ember, которая несовместима с рабочими пространствами.

    "nohoist": [
      "**/ember-package/*ember*",
      "**/ember-package/*ember*/**",
      "**/ember-package/loader.js"
    ]

Думаю, теперь у нас есть минимальное воспроизведение: https://github.com/yarnpkg/yarn/issues/7212#issuecomment -637978197

Удаление yarn.lock затем yarn install тоже помогло мне

Есть новости? Наш процесс CI просто остановился, и все конвейеры вышли из строя из-за сбоя установки зависимости из пряжи. Это просто смешно.

Установка --network-concurrency ничего не исправляет, и задания выполняются на чистых машинах (без node_modules, без yarn .cache).

@cadavre Никаких гарантий, но это может не быть проблемой в версии 2, вы можете попробовать

yarn set version 2 && yarn config set nodeLinker node-modules

https://yarnpkg.com/getting-started/install#per -project-install
https://yarnpkg.com/configuration/yarnrc#nodeLinker

Это только начало происходить со мной, после обновления некоторых моих зависимостей vue и firebase. Теперь 100% повторяемость на моих машинах CI и dev. Добавление --network-concurrency 1 не исправляет ее. У меня нет места на диске или индексных дескрипторов. Я на WSL1. Пряжа 1.22.4.

Я исправил это, временно изменив каталог кеша, который я удалил сразу после этого.

Для меня это сборка Docker:

RUN yarn install --check-files --cache-folder .ycache && rm -rf .ycache