<p>A instalação do yarn falha com `ENOENT: nenhum arquivo ou diretório` ocasionalmente</p>

Interessante, então ele só falha no Travis, mas funciona ao testar localmente? Isso é muito estranho, já que o Docker deve garantir que o ambiente seja consistente.

@ Daniel15 eu sei né ...

Fiz downgrade do nó para a versão 6 e ainda falha no Travis. Eu adicionei a bandeira --verbose a yarn install e tudo o que consegui foi

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'".

Estou aberto a ideias sobre como depurar isso.

Fazer downgrade para o fio 0.18.1 pareceu consertar isso para mim. Parece que 0,19 pode ter uma regressão; veja # 1834

Eu também tenho esse problema com o yarn 0.23.3, não está acontecendo durante a construção de uma imagem, mas simplesmente durante a execução de alguns CI.
O erro é o seguinte:

$ 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

Acho que pode haver uma maneira estranha de remover arquivos ...

Ponto importante: o cache estava vazio!

E na minha máquina, se tento reproduzir, obtenho o seguinte:

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.

E com fio 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.

Isso é terrível!

E eu concordo com @twooster sobre 0.18.1 funcionando bem!

@ Daniel15 também não funciona localmente. Na verdade, ele NUNCA funciona quando o cache está vazio para mim!

@victornoel o erro recente pode ser https://github.com/yarnpkg/yarn/issues/2714

@bestander, eu tentei 0.19.1 na época e não funcionou ...

Tentei novamente e agora o bug:

• não aparece com um cache vazio, mas aparece no seguinte caso (eu realmente espero que seja reproduzível ...):
  
  
  
  • rm -rf o cache de fios
  
  
  • clone https://gitlab.com/linagora/petals-cockpit.git
  
  
  • checkout 5f31ccb4b2357201baa50539b30702cffceb6992
  
  
  • execute o fio no diretório frontend
  
  
  • checkout master
  
  
  • execute o yarn novamente no diretório frontend
  
  
  • Eu obtenho: 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'". (estou usando meu próprio registro, mas o mesmo acontece sem ele)
  
  
• aparece com fio 0.21.2, 0.19.1, mas não com 0.18.2

Então eu não acho que seja a mesma coisa, vamos esperar que você possa reproduzi-lo pelo menos ...

(na verdade, eu apenas tentei novamente e reproduzi o bug com um cache vazio e yarn 0.21.2 enquanto não era o caso antes, talvez haja outro arquivo em outro lugar que é a origem deste problema, e que não está no cache?)

@bestander , ainda

Envie-me um ping se eu puder ajudar.
A melhor ação é enviar um PR com um teste e2e quebrado (e pulado).

@bestander bem, não, ainda recebo erros como:

➜  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'".

ou:

➜  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'".

Vou ver se consigo fazer um teste e2e.

@bestander de qualquer maneira, posso obter um rastreamento de pilha completo do erro?

Só vejo isso no 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)

Isso é um pouco inútil :)

o erro detalhado é:

{ 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)' ] }

Não sei exatamente o que fazer com isso ... está acontecendo em package-fetcher.js , linha 56 exatamente, mas tenho problemas para encontrar a fonte ...

Parece estúpido, mas sinto que só falha quando meu espelho npm em rede (um nexo de sonatipo em minha empresa) espelha o artefato @angular/core . Se não, as coisas vão bem e depois falha em outro artefato que já está espelhado ( typescript neste caso).

Se eu remover o artefato do espelho Nexus com a mão, ele funciona!

Então ... é um pouco como o yarn não consegue acompanhar se as coisas chegam muito rápido ^^ porque quando eu uso o registro npm normal sem usar o meu espelho, as coisas geralmente vão bem (temos uma conexão de internet lenta).
E explicaria por que muitas vezes falha em sistemas CI, porque eles geralmente têm conexões de internet muito rápidas ...

Concluir isso é um pouco forçado, mas pode ajudar a encontrar a origem do problema.
WDYT @bestander?

Para registro, acho que o erro é proveniente da etapa tar.Extract no pipeline de busca, mas não tenho certeza total ^^

Obrigado por pesquisar mais, @victornoel , você pode estar em algo aqui.

Posso reproduzir o cenário de https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896.
Olhando para isso.

eu recebo

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'".

No entanto, se eu tentar yarn install novamente e novamente, a instalação terminará.
Parece que a explosão do arquivo .tgz termina com erro.

Atualizar:

• o .tgz parece bom, posso descompactar manualmente aquele que falha durante a fase de busca
• Eu me pergunto se o pacote tar está gerando esse erro por algum motivo, poderia ser simultaneidade?

Alguns ajudam a investigar por que descompactar essas poucas dependências (no meu caso, texto datilografado e núcleo angular) causa erro é bem-vindo.
Simultaneidade? Bug em https://github.com/npm/node-tar?

@victornoel , você pode reproduzir o bug com yarn install --network-concurrency 1 ?

@bestander com --network-concurrency 1 o bug não aparece (enquanto sem ele, ele aparece sempre).
Mas qual é o valor padrão deste parâmetro? Qualquer que seja o valor que eu escolher para ele (1, 2, 4, 8), ele funciona, enquanto se eu não colocá-lo, ele falha ...

O padrão é 15, posso reproduzir o problema com a simultaneidade 15 com uma verificação limpa de https://gitlab.com/linagora/petals-cockpit.git#075bac4c54fee466568c000c7ffe8025f593e212 .

Excelente notícia! Um passo adiante em direção a uma solução E uma solução alternativa :)

Alguns resultados.

TL; DR Não tenho ideias de como consertar adequadamente para sempre. Isso requer um conhecimento mais profundo do Node.js.

1. A rede pode ser eliminada de possíveis problemas.
   Eu configurei o espelho offline para os arquivos .tgz em yarn.lock e posso reproduzir o problema com pacotes instalados do disco.

O problema está no fluxo de descompactação / descompactação do código do tarball.

1. Tentei uma biblioteca diferente que extrai tar - https://github.com/mafintosh/tar-fs vs atual https://github.com/npm/node-tar/. Ambos falham da mesma maneira.
   Indo um pouco mais fundo - exceções estão acontecendo no nó ao fazer várias operações 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' }

Eu acho que core-4.0.0 e typescript-2.2.1 falham porque eles têm alguns arquivos e estruturas de pastas profundas, e eles falham na instalação ao fazer muitas operações mkdir / copy simultâneas.

Cada vez que há um syscall diferente que falha: chmod, rmdir, mkdir, lstat, utime.

E não é algo óbvio no código das bibliotecas.

1. Falha na mesma nos nós 4, 6 e 7.

2. Não consegui reproduzir o erro com a simultaneidade definida como 8, então enviarei um PR para reduzir a simultaneidade de rede padrão.

1. Eu queria saber como a simultaneidade afeta a velocidade de instalação.

5.1. Usando o espelho offline (sem download), no meu MBPro 13 ", limpe o cache e use node-tar para descompactar os arquivos.
Simultaneidade 12 - falha
Simultaneidade 8 - 18 segundos
Simultaneidade 4 - 18 segundos
Simultaneidade 2 - 21 segundos

5,2 Usando o espelho offline (sem download), no meu MBPro 13 ", limpe o cache e use tar-fs para descompactar os arquivos.
Simultaneidade 12 - 15 segundos
Simultaneidade 8 - 15 segundos
Simultaneidade 4 - 17 segundos
Simultaneidade 2 - 18 segundos

5,3. Baixando pacotes da internet, no meu MBPro 13 ", limpe o cache e use tar-fs para descompactar os arquivos.
Simultaneidade 12 - falhou uma vez
Simultaneidade 8 - 21 segundos
Simultaneidade 4 - 23 segundos
Simultaneidade 2 - 34 segundos

Parece que definir a simultaneidade como 8 é seguro o suficiente, mas também faz sentido mudar a biblioteca tar.
Seguirei com um PR.

Uma maneira adequada de corrigir isso seria bifurcar https://github.com/mafintosh/tar-fs e fazer operações fs mais inteligentes, por exemplo, usando mkdir para cada pasta apenas uma vez

O mantenedor do tar-fs parece estar ativo, talvez possamos abrir um problema lá e ver o que eles sabem / propõem sobre isso?

@victornoel , você faria isso, por favor?

@bestander feito! mafintosh / tar-fs # 61 :)

Encontrei esta mensagem de erro em um cenário um tanto semelhante ao testar yarn nos agentes de compilação do meu Jenkins.

Você sabe quais são as condições necessárias para acionar esse bug? Eu gostaria de substituir as chamadas de npm meu sistema de construção por yarn para velocidade, mas se eu tiver que desabilitar a simultaneidade, estou preocupado que possa anular qualquer bônus lá.

@ProdigySim , conforme explicado em # 2829 (que foi mesclado no yarn master), a redução da simultaneidade da rede não tem grande efeito no desempenho do yarn. Você pode simplesmente definir para 8 e deve ficar tudo bem. De qualquer forma, mesmo ao baixar 8 dependências de uma vez, não tenho certeza se a maioria dos drives seguirá na taxa de transferência, então você não perderá muito com certeza :)

@victornoel Obrigado pela informação. Não tenho certeza se apenas reduzir --network-concurrency será suficiente no meu caso, já que também executaríamos várias instâncias de fio em paralelo.

Posso reproduzir esse problema mesmo com --network-concurrency 1 , mas talvez eu deva abrir um problema separado para isso?

Usando o mesmo repositório de teste fornecido acima:

#!/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 &

Isso me mostra o erro todas as vezes (4 em 4 até agora)

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'".

No fio 0.21.3, nó v4.5.0, OSX 10.11.6

Até agora, fui capaz de contornar esse problema incluindo apenas fios em trabalhos de construção que nunca serão executados em paralelo, ou usarão conjuntos de pacotes completamente diferentes, mas mesmo assim não tenho certeza se será seguro - daí perguntando sobre as condições de raiz para este bug.

@ProdigySim
Este é um problema separado, mas relacionado, causado pelo cache global de download do Yarn. Uma solução alternativa é criar um cache diferente para cada diretório.

Você ainda pode executar com --network-concurrency 8 . (Na verdade, não tenho problemas com simultaneidade de rede ilimitada.)

Mais contexto aqui .

@bestander surpreendentemente, hoje, o problema reapareceu (desencadeado por um tar para uma nova versão do angular ^^) mesmo com a concorrência de rede em 8, mas apenas no meu CI ... Mudei para 2 e funciona (e não t realmente me importo se leva mais alguns segundos para baixar dependências, então está tudo bem por enquanto)
Parece que não estamos recebendo feedbacks do projeto tar-fs ... quem mais poderíamos contatar para obter ajuda nisso?

tendo esse problema também em minhas compilações Travis para OS X. Eu limpei o cache e configurei a simultaneidade de rede, mas nada ajudou.

@kevingelion para qual valor você definiu a simultaneidade de rede? seja drástico e defina algo como 2 para ver se o problema é este :)

@victornoel Eu defini como 1 e 2, e ambas as opções resultaram em falha. Usei yarn --mutex network e também não usei dados.

@bestander o seguinte hack corrige (editar: NÃO) o problema:

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

Obviamente não é uma correção, ele ignora completamente o gerenciador de pedidos e seu sistema de enfileiramento, mas mostra que o problema está vindo deste subsistema.

Obrigado, Victor!

Em 24 de março de 2017 às 18:07, Victor Noël [email protected] escreveu:

@bestander https://github.com/bestander o seguinte hack corrige o
problema:

diff --git a / src / util / request-manager.js b / src / util / request-manager.js
índice e0e134a2..995dac69 100644
--- a / src / util / request-manager.js
+++ b / src / util / request-manager.js
@@ -214,8 +214,7 @@ exportar classe padrão RequestManager {
}, params.headers);

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

• this.queue.push ({params, resolver, rejeitar});
• this.shiftQueue ();
• this.execute ({params, resolver, rejeitar});
  });

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

Obviamente, não é uma solução, ele ignora completamente o gerenciador de solicitações e
seu sistema de filas, mas mostra que o problema está vindo deste
subsistema.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-289102067 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ACBdWF66L-NzAInx7Bhs6V7s7LKahxxUks5rpAZ1gaJpZM4L3JbX
.

whoups não, não faz: D, mas melhora um pouco as coisas

Desculpe pelo falso positivo, eu estava muito ansioso para relatar minhas descobertas :)

Isso muda as coisas porque antes de eu poder rodar o yarn muitas vezes e nunca conseguir baixar a dependência angular-core ou o texto datilografado (sempre esses), mas aí falhou na primeira vez e na segunda vez, e eu esqueci de remover o cache entre minhas tentativas, então pensei que estava funcionando.

Bem, depende, agora às vezes funciona, às vezes não (com o hack, então não é uma falha total ou minha conexão de internet está muito lenta agora ...)

Também estou encontrando isso em nossos builds de CI. Depois de muitos testes, finalmente consegui reproduzir localmente.

Novamente, às vezes funciona, mas falha frequentemente com um dos seguintes erros (o que faz parecer que existe algum tipo de condição de corrida em algum lugar):

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

Eu o isolei em um pacote que instalamos diretamente de um repositório privado no GitHub. Curiosamente, o pacote referenciado na mensagem de erro é sempre uma dependência desse pacote (e é sempre outro pacote que instalamos diretamente do GitHub, embora não seja um repositório privado). Portanto, parece que um caso de repro é instalar pacotes de URLs privados do GitHub que possuem subdependências que também são instaladas de repositórios do GitHub (não necessariamente privados).

Não tenho certeza se isso ajuda em tudo ... Estou feliz em tentar ajudar de todas as maneiras que puder!

Editar: Não tenho certeza se isso é útil ou não, mas o pacote de nível superior está listado no formato de "git+ssh://[email protected]/org/package.git#v1.0.0" e, no erro, a subdependência sendo baixada parece que está sendo baixada em https com um url de "https://codeload.github.com/org/package/tar.gz/ljasdf08i234098aifj" .

Estou investigando isso um pouco mais.
Tentando construir um script autônomo para extrações de tar-fs simultâneas, mas tendo a pensar que o problema está na quebra do arquivo tar durante o download.

Encontrei, Doh.

No exemplo de https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 Yarn tem pacotes duplicados que estão sendo baixados e extraídos em paralelo.
Os duplicados são @angular/core/-/core-4.0.0-rc.1 e typescript/-/typescript-2.2.1.tgz .

Com alta simultaneidade, simplesmente fazemos extrações simultâneas na mesma pasta de cache.
Investigarei por que o Yarn não desduplica esses dois pacotes e enviarei uma correção.

Nenhuma mágica no sistema operacional ou nível de extração de tar.

haha, bom trabalho @bestander , que bom que finalmente encontramos o problema!

Trabalho incrível @bestander : tada :! Correr para https://github.com/yarnpkg/yarn/pull/3090 e https://github.com/yarnpkg/yarn/pull/3106 foi o que nos impediu de usar o Yarn.

obrigado!

Eu tive esse problema ao instalar o módulo prop-types. Cada vez que tentava instalá-lo ENOENTIA em um nome de arquivo diferente. Para mim, o problema foi embora depois de instalar o 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 É provável que seja coincidência - o Yarn não usa o cliente npm, portanto, a versão do npm não afeta a execução do Yarn.

Isso está fazendo com que minhas compilações do Travis falhem quase todas as vezes, com alguns pacotes diferentes. Já existe uma solução?
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
O mesmo aqui, mas funciona:

yarn install --network-concurrency 1

Qual versão você está usando? Isso já deve ser consertado ...

Em 8 de agosto de 2017 18:37, "Ben Merckx" [email protected] a écrit:

@Redmega https://github.com/redmega
O mesmo aqui, mas funciona:

yarn install --network-concurrency 1

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-321011749 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAJ0z5qFb7gSW4w14_RbFNjsn4sRYV78ks5sWI7hgaJpZM4L3JbX
.

@victornoel Estou usando v0.27.5 na máquina jenkins, igual ao meu local.

Tente os nightlies: https://yarnpkg.com/en/docs/nightly

Remover o arquivo yarn.lock e yarn install resolveu o problema para mim.

Isso também faz com que minhas compilações do Jenkins falhem ocasionalmente. Normalmente funciona após uma segunda tentativa, mas falhará novamente mais tarde.

@ajcrites @Redmega @headione @benmerckx você deve abrir outro problema se estiver tendo esse tipo de problema. Esse problema foi corrigido com certeza, portanto, seu problema deve ser diferente, mesmo que apresente alguns sintomas semelhantes.
Tenho certeza de que há mais chance de o seu problema ser resolvido se você abrir outra edição :)

Temos o mesmo problema, fazendo builds paralelos de pacotes no Jenkins com o Node 8.5. No momento, precisamos nos limitar a 0.27.5, até que 1.0.2 seja lançado, corrigindo outro bug. Mas obrigado pelo seu apoio e trabalho de qualquer maneira :)

@floric Estou recebendo o mesmo problema com o mesmo contexto (Jenkins + Parallel) com o nó 8.9.4. Seu problema foi resolvido?

Edit: Vou tentar usar 8.11.1 para ver se inclui uma versão mais recente do yarn sem o bug.

@Niceplace, você pode tentar a opção --mutex : https://yarnpkg.com/en/docs/cli#toc -concurrency-and-mutex

Temos planos para adicionar um melhor bloqueio por pacote para evitar isso em breve.

Estou tendo erros intermitentes com ENOENT: no such file or directory, chmod e ENOENT: no such file or directory, lstat tentando executar yarn --mutex=network na raiz de um monorepo com a área de trabalho do Yarn habilitada ...

Não parece ser consistente, eu recebo um ou outro aleatoriamente. (1.6.0 e nó 8.11.1 e 9.11.1)

Especificamente, os erros são:

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

e

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

Estou executando o Yarn 1.7.0 e estou tendo um erro semelhante. O Yarn finalmente consegue instalar o pacote após várias execuções.

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'".

EDITAR:
Usei yarn --network-concurrency 1 mas o erro ainda ocorre comigo. Aqui está outro exemplo do arquivo error e 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'".

Estou usando o Yarn 1.7.0. E posso confirmar que o mesmo comportamento ainda está acontecendo comigo.

É completamente aleatório. Às vezes acontece, às vezes não.

O último que recebi foi:

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

Estou vendo esse erro com frequência com o Yarn 1.9.2 no subsistema Windows para Linux.

Hoje tivemos problemas semelhantes com pacotes quebrados no Jenkins CI, onde o pipeline executa yarn install em paralelo. Estava funcionando bem há alguns dias.
Corrigido com yarn install --network-concurrency 1 (conforme mencionado em um comentário ). O desempenho não diminuiu muito: ~ 7 seg -> ~ 8 seg.

Por que isso foi fechado? Ainda acontece:

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.

Note que no meu caso ele desapareceu após fazer yarn remove fs-extra e yarn add fs-extra em dois pacotes, efetivamente atualizando esta dependência.

Oi, acho que encontrei algo.

Eu estava brincando com um pedaço de código que lista arquivos em um diretório especificado recursivamente usando fs e rxjs e descobri que provavelmente iria falhar se eu não esperasse por lstat chamada a ser encerrada antes de chamar outro lstat .

Fiz um pacote NPM simples, async-dirtree-test , para testar se seu ambiente é afetado ou não com isso. Estou usando WSL e descobri que é provável que ele falhe ao lidar com um diretório que tem muitos diretórios filhos, como node_modules , mesmo com um baixo número de simultaneidade.

Bem, ainda não sei se esse problema é específico do WSL ou não. No momento não posso testá-lo em outro ambiente, como Linux, Mac, etc.

@nieltg Eu queria compartilhar uma observação que pode ajudar a moldar algumas das outras. Estou usando Docker CE em WSL e Docker para Windows como meu host, então quando trabalho com Docker em WSL, parece nativo, mas na realidade o host opera no mundo do Windows nativamente (portanto, meus Dockerfiles realmente resolvem / c / foobar para c: / foobar no mecanismo Docker). Isso é extremamente relevante quando eu uso vínculos (dentro do meu contêiner, estou montando minhas pastas locais de forma que / usr / src dentro do contêiner esteja em c: / src / foobar (embora meu Dockerfile mostre a ligação como / c / src / foobar: / usr / src (veja a tradução automática no caminho?)

Essa distinção é importante porque se eu yarn install dentro de uma dessas pastas locais, dentro do meu contêiner, recebo os mesmos erros que recebo diretamente no WSL (sem Docker envolvido).

Por outro lado ... se eu apenas mkdir /tmp/src && cp ./package.json /tmp/src/ && cd /tmp/src && yarn install , tudo ocorre perfeitamente e eu posso apenas mv /tmp/src/node_modules /c/src/foobar/ e estou bem, então essa é minha solução alternativa. Lembre-se de que /tmp existe como um armazenamento docker (todo o IO parece um único arquivo para o sistema operacional porque é efetivamente uma partição em um arquivo).

Eu sei que envolver docker não é ideal aqui, mas parece sugerir que o tratamento rápido de arquivos pode ser um problema, já que o IO em si não é e pode ajudar outros a contornar isso.

... distraiu-se e foi submetido cedo demais. De qualquer forma, meu cérebro está em outro lugar no momento, mas voltarei mais tarde e verei se consigo criar um teste usando sua abordagem e o Docker para tirar outras conclusões.

REABRIR

Recentemente, começamos a ver o mesmo tipo de erro usando yarn 1.10.1, executando uma compilação de CI no Azure Devops (anteriormente Visual Studio Team Services).

A dependência real que está falhando parece ser aleatória, pelo que posso dizer, mas yarn install está caindo intermitentemente com o erro ENOENT: no such file or directory, open '/usr/local/share/.cache/yarn........ . Em uma ocasião, a compilação funcionará, na próxima, falhará.

A solução alternativa de yarn install --network-concurrency 1 parece funcionar para nós.

@ Marclev78 mesmo erro, mas yarn install --network-concurrency 1 não parece funcionar para mim

@ Marclev78 mesma coisa aqui, usando yarn 1.10.1 no Azure Devops e obtendo o erro:

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'

Localmente, tudo funciona conforme o esperado.

Estou aqui simplesmente para dizer que também estou vendo esse erro.

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

Infelizmente, acho que tenho que abandonar o yarn para meus binários de nó global e voltar para o npm até que isso seja corrigido.

Infelizmente, esse problema também começou a afetar nossos builds de CI recentemente; (

A sugestão de WSL

Acho que as operações de gravação e leitura também se comportam de maneira diferente. Mesmo com meus hacks, frequentemente vejo erros ao chamar o fs.writeFile do node (envolto no bluebird promisify). Em cada instância, posso confirmar que o arquivo existe imediatamente após receber o erro de gravação.

Estou enviando uma string (conteúdo de arquivo XML) para fs.writeFile (), que em última análise chama o seguinte, mas não tenho certeza se estou preparado para enfrentar o desafio que é necessário para configurar uma construção personalizada com depuração adicional saída deste projeto C ++, para que eu possa confirmar exatamente onde está o sentimento certo de acordo com o nó ou este módulo C ++.

O ponto principal é que as gravações não estão falhando, mas o nó acredita que sim, então o cenário que faz sentido para mim é que o módulo c + plus está tendo sucesso, mas internamente ele verifica o arquivo e falha, então os relatórios não sentem sua volta ao nó e então a gravação real ocorre de forma que quando eu for verificar o arquivo, ele está lá e o erro não faz sentido.

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

@bestander alguma maneira de reabrir esse problema? É claro que isso não foi corrigido e está afetando muitas pessoas.

Confirmar que isso ainda acontece com o yarn 1.12 e o Azure Pipelines.

Obrigado por confirmar a todos.
Parece que há vários motivos para esse erro.
Vou reabrir o problema, mas a ajuda da comunidade para depurar isso é necessária.

também acontece com o fio 1.11, mas não com 1.10

@bestander - Relacionado? https://github.com/yarnpkg/yarn/issues/6312

Nesse caso, há um bom trabalho de reprodução aqui

Eu também sou afetado por esse problema.

Windows 10 / WSL

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

@limonte WSL apresentou um erro por um tempo que geraria aleatoriamente um erro semelhante ao executar npm install / yarn install. Isso estava acontecendo quando muitos arquivos de uma vez foram copiados para o disco rígido. Certifique-se de que está usando a versão mais recente do Windows (1809 ou superior), pois pode não ser causado pelo fio em si.

Também estamos vendo o problema de 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'"

Até agora, mitigamos isso usando apenas uma conexão de rede simultânea com a opção --network-concurrency 1 . Mas esta é mais uma solução temporária.

Também posso confirmar o problema em node:11.5.0-alpine .

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

Percebi que os problemas pareciam estar relacionados à vinculação à versão do repositório git dos pacotes.

Reproduzir

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

Gambiarra

Definir network-concurrency 1 corrige o problema para mim.

Executar npm install também funciona.

Notas

Remover qualquer um dos pacotes da lista de dependências não causa o erro, nem o uso das versões npm publicadas desses pacotes.

Parece lançar um erro diferente a cada vez. Parece acontecer aleatoriamente em arquivos diferentes e com erros ligeiramente diferentes.

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'"

Variações

• 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

Outras mensagens

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

Na verdade, acabei de tentar reproduzir usando seu package.json e um erro apareceu na primeira tentativa.

Qual camada o sistema de arquivos WSL interage com os fs NTFS que já estão em vigor?

Vocês estão vendo esse erro em uma unidade montada (/ c ou / mnt / c para exemplos comuns) ou fora de uma dessas montagens? Importa-se de testar uma alternativa (~ /. Por exemplo) e relatar qualquer diferença?

Minha intuição está me incomodando, mas posso estar confundindo meus problemas com minhas experiências no docker e preciso verificar isso independentemente.

[2/4] Buscando pacotes ...
erro https://registry.yarnpkg.com/smartwrap/-/smartwrap-1.0.10.tgz : Falha ao extrair o conteúdo do tar de undefined, o arquivo parece ser co
rrupt: "ENOENT: nenhum arquivo ou diretório, abra 'C: \ Users \ Administrator \ AppData \ Local \ Yarn \ Cache \ v4 \ npm-smartwrap-1.0.10-873ef350d
4ee1262fed4a80a55634d86ae1faf48 \ node_modules \ smartwrap \ ejq '"
informações Visite https://yarnpkg.com/en/docs/cli/global para documentação sobre este comando.

Vocês estão vendo esse erro em uma unidade montada (/ c ou / mnt / c para exemplos comuns) ou fora de uma dessas montagens? Importa-se de testar uma alternativa (~ /. Por exemplo) e relatar qualquer diferença?

Existe um caso consistentemente reproduzível em que isso esteja acontecendo? Tem sido bastante aleatório para mim, mas eu faço todas as minhas yarn add -ing em uma unidade montada e isso ocorre com frequência.

Consegui reproduzir https://github.com/yarnpkg/yarn/issues/2629#issuecomment -451638917 em uma unidade montada e em ~ .

Eu também tentei reproduzir https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896, mas não consegui buscar o último pacote, que tenho certeza de que não está relacionado.

Tive o mesmo problema nas últimas horas. yarn estava falhando aleatoriamente ao instalar vários pacotes, mostrando os erros que foram mencionados acima.

Tentei redefinir o cache do yarn e reinstalar e executar com simultaneidade de rede 1, nenhum dos dois funcionou.

O que resolveu o problema para mim foi mudar para uma rede diferente (usei apenas o AP do meu telefone em vez de WiFi) e tudo funcionou como mágica.

Tenho um palpite de que esse problema pode estar relacionado à recuperação incorreta de alguns erros de rede muito específicos. Examinarei isso mais tarde.

Posso confirmar o comentário anterior. Definir network-concurrency não ajuda. Mudar para o ponto de acesso do telefone corrigiu o problema para mim. Meu ambiente: Windows 10 (subsistema Linux - Ubuntu)

Estou no WSL e tenho visto esse problema com o pacote geo-tz que tem uma estrutura de pastas profundamente aninhada (um pouco estranha). Tentei --network-timeout e --network-concurrency coisas, mas não cheguei a lugar nenhum. No entanto, quando habilitei caminhos longos no Windows (veja esta postagem do SuperUser ) agora está funcionando bem. Talvez isso possa ajudar outras pessoas no WSL. Editar , parece que falei muito cedo. Estava funcionando e vincular dependências é mais rápido, mas agora estou vendo o mesmo erro novamente.

Ainda quebrando CI ....

Temos o mesmo problema com o Yarn 1.13.0 rodando em uma máquina Debian Linux que serve como um nó escravo Jenkins. Observe que temos um servidor de repositório yarn local, portanto, durante a construção, não há (ou há muito poucos) downloads físicos de servidores de repositório de Internet pública.

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'".

O arquivo real já existe, tanto em nosso servidor repo quanto no sistema de arquivos.
Se iniciarmos a construção novamente, ela pode ser bem-sucedida ou pode falhar com algum outro arquivo (aleatório).
Não alteramos a configuração de concorrência de rede padrão.

Idem - Isso ainda é um problema, mesmo em 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'

Além disso:

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

Isso é muito chato, vemos isso diariamente em máquinas locais e ci.

Confirmando que isso está acontecendo o tempo todo em CI para nós também

Olá, confirmando que esse problema ocorre em nosso CI.
Isso está de acordo com o problema.

erro https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz : Falha ao extrair conteúdo tar de undefined, o arquivo parece estar corrompido: "ENOENT: nenhum arquivo ou diretório, chmod '/usr/local/share/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/es7/regexp.js' "
informações Visite https://yarnpkg.com/en/docs/cli/install para documentação sobre este comando.

O mesmo problema começou a acontecer hoje com um de nossos projetos de código aberto.

Você pode ver uma construção com falha aqui:
https://travis-ci.com/quid/refraction/builds/103692106

E aquele que tem sucesso (com --network-concurrency 1 ) aqui:
https://travis-ci.com/quid/refraction/builds/103693682

Espero que possa ajudar a diagnosticar o problema!

O código-fonte do repositório está em:
https://github.com/quid/refraction

Talvez isso ajude alguém:
Em nosso Jenkins CI, o problema era que o Jenkins acionava compilações paralelas para nossos aplicativos, o que significa que dois (ou mais) scripts de shell acionaram "instalação de yarn" ao mesmo tempo, onde um dos processos de compilação _removeu ainda mais o cache de yarn completamente_ (usando "yarn cache clean") antes de iniciar a "instalação do yarn". Este foi um problema fatal para os outros processos de fios, é claro.
Em seguida, removemos a limpeza do cache e alteramos o comando yarn para
yarn install --verbose --prefer-offline --mutex file:/tmp/.yarn-mutex --network-concurrency 1
(_-- verboso_ não é realmente necessário) e inserido
child-concurrency 1
em .yarnrc.
Agora, conforme as construções paralelas são acionadas, o fio detectou que outro processo de fio está ativo e esperou até que ele termine. Isso resolveu os problemas de "nenhum arquivo" em nosso CI.

Eu recebo esse problema em minha máquina local sempre que uso uma referência de pacote com este formato:

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

Características notáveis: pacote privado, url github, git + https, referência git marcada

Passos que se reproduzem para mim:

1. Limpe o quadro: remova todas essas referências e execute yarn install . Funciona bem.
2. Adicione todas essas referências de volta ao meu package.json e execute yarn install novamente, ele ainda funciona bem na primeira execução após essas referências serem adicionadas de volta.
3. Executar yarn install vezes adicionais depois disso funciona, desde que não haja alterações.
4. No entanto, modifique todos os pacotes e execute yarn install e recebo o erro.
5. Se eu remover todos esses pacotes e executar yarn install , não obtenho o erro. Isso nos leva de volta à etapa 1.

O erro é semelhante a este:

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'".

Se eu remover todas as referências de tag git, observo o mesmo comportamento. Portanto, acredito que esse não seja o problema.
ie

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

Executar npm install também dá um erro:

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

Como acompanhamento, usei uma solução alternativa para fazer um script package.json para limpar esses pacotes do meu cache antes de instalar:

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

Ainda há alguma ideia de qual poderia ser esse problema?
Em nosso caso, estamos executando yarn install como parte de nosso CI (dentro do contêiner do docker) e obtendo os mesmos erros. Tentamos yarn cache clean

Não tenho certeza do que mais tentar neste ponto e está interrompendo nossas compilações. 😬

Dan, você tentou executar com --network-concurrency 1? Eu tenho um similar
cenário e isso resolveu meu problema.
Em 2 de abril de 2019, às 22h17, "Dan Van Brunt" [email protected] escreveu:

Ainda há alguma ideia de qual poderia ser esse problema?
No nosso caso, estamos executando a instalação do yarn como parte do nosso CI (dentro do docker
container) e obtendo os mesmos erros. Tentamos limpar o cache de fios

Não tenho certeza do que mais tentar neste ponto e está interrompendo nossas compilações. 😬

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-479283590 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AFU4O1iKA-HBd62Hema1ETmuUlMro_GLks5vdAEOgaJpZM4L3JbX
.

@tevaum que resolveu o problema do nosso CI também. Também diminuiu significativamente a velocidade de nossas compilações. Tão terrível, mas apenas uma solução alternativa.

Sim. É uma desvantagem ruim. Você pode tentar com números pequenos como 2 ou 4 ...
vai ser um pouco mais rápido, mas para mim, o único valor que funcionou foi 1: /

Portanto, teremos que esperar pela solução real para sermos felizes;)
Em 4 de abril de 2019, 00:26, "kunokdev" [email protected] escreveu:

@tevaum https://github.com/tevaum que resolveu o problema do nosso CI também.
Também diminuiu significativamente a velocidade de nossas compilações. Tão terrível.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-479735791 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AFU4O1a9lHn41K0eEQT9zZZzOoATiT61ks5vdXD8gaJpZM4L3JbX
.

Isso será consertado? Isso tornou o fio inutilizável em mais de um dos meus projetos

Use a opção mutex, documentada aqui: https://yarnpkg.com/en/docs/cli/#toc -concurrency-and-mutex

O uso do cache do Yarn não é seguro para uso em vários processos e esta é a razão para tais erros.

Como alternativa, você pode definir uma pasta de cache por processo usando a opção --cache-folder documentada aqui: https://yarnpkg.com/en/docs/cli/cache#change -the-cache-path-for-yarn-

A desvantagem de usar a opção mutex é ter apenas uma instância de yarn em toda a máquina (outras esperarão até que o processo ativo termine), o que significa que não há concorrência em todos os trabalhos de CI.

A desvantagem de uma pasta de cache por processo é o aumento de E / S e a perda de algum potencial devido à menor reutilização do cache.

A solução ideal seria implementar uma implementação de cache segura para o processo, o que não é muito fácil com a falta de qualquer recurso de bloqueio de arquivo no Node (a única opção confiável parece ser a criação de diretórios mutex). O segundo melhor é usar uma pasta de cache por braço paralelo, que permitiria a simultaneidade e a reutilização de cache no mesmo braço.

Não acho que seja a coisa mutex. Eu e alguns outros executamos um fio de cada vez - no meu caso, é apenas RUN yarn install em um Dockerfile - durante a fase de construção da imagem do docker. Isso garante que nenhum outro processo esteja sendo executado simultaneamente nesse ambiente.

Veja isso, exemplo de reprodução mínima (pelo menos para meu 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 é muito antigo e houve várias correções após essa versão. Você tentou usar um dos mais recentes dentro do Docker?

Na verdade, essa imagem de nó era bastante antiga. Aqui está um novo baixado há alguns minutos do nó 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 Você tentou construir este docker sozinho?

Vou tentar em alguns dias, quando eu chegar ao meu computador (no celular agora). Parece muito estranho, mas o diretório é consistente. Vou tentar ver o que está acontecendo, obrigado pelo caso repro.

@nopik - olhando mais de perto o log, ele realmente mostra várias instâncias do Yarn sendo executadas em paralelo. Você nunca deve ver a mesma mensagem "Resolvendo pacotes" duas vezes. Não sei por que isso está acontecendo, mas tenho 100% de certeza que é esse o motivo.

@BYK Vejo que um desses pacotes tem "scripts": { "build": "yarn babel --out-dir dist && del-cli 'dist/**/__tests__' && yarn tsc --emitDeclarationOnly", "prepare": "yarn build" } o outro tem scripts diferentes, mas ainda executando o yarn na preparação. Esses pacotes são iniciados pelo yarn durante a instalação?

@Nopik - não pense que isso causaria o problema, pois estão simplesmente executando scripts, não outra instalação. Além disso, esses scripts são executados após a fase de E / S. Deve haver algo mais acionando vários yarn install instanaces.

Eu concordo que provavelmente são várias instâncias de fios em execução ao mesmo tempo. O problema é que isso acontece em uma única invocação cli de yarn . Isso não precisa do docker para reproduzir.

Minha teoria, reconhecidamente mal informada, é que é algo relacionado à etapa de preparação e que o yarn pode estar lançando uma instância extra para "construir" pacotes git. Em particular, aposto que são duas dependências em que cada uma depende de um pacote comum que também precisa ser construído. O Yarn tenta ser inteligente e construir cada pacote separado em paralelo, mas falha quando tenta construir dois pacotes no mesmo local de cache.

Em nosso caso, não temos várias instâncias de fio.

Nosso sistema é executado em sua própria imagem docker. Possui _ instalação única _. Ele começou a se comportar mal de repente e agora não podemos trabalhar sem a simultaneidade de rede definida como 1.
A menos que o próprio fio tenha mudado durante a noite, não vejo outro problema além do fato de que o fio está criando problemas com condições específicas.

Se você tentar resolver esse problema com --mutex file ou mesmo --mutex network , você inevitavelmente (provavelmente) encontrará este bug https://github.com/yarnpkg/yarn/issues/6650 (aberto / não resolvido há 6 meses) 😢

O que significa que depois de executar yarn install , embora tenha sucesso, você nunca será capaz de executar outro comando yarn

Dan, você tentou executar com --network-concurrency 1? Tenho um cenário semelhante e isso resolveu meu problema.

@tevaum - Esse era exatamente o problema. OBRIGADO!
Eu tinha um script que nunca pensei que executaria mais de uma instância, mas estava. 🤦‍♂️

@tevaum resolvido para mim também. Obrigado.

Se você tentar resolver este problema com --mutex file ou mesmo --mutex network, você inevitavelmente (provavelmente) encontrará este bug # 6650 (aberto / não resolvido por 6 meses agora)

@sarink - Também encontrei o bug da opção mutex; obrigado por mencionar isso.

yarn diz que está tudo bem.

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.

Mesmo assim, a execução de yarn --check tenta construir, mas sempre falha.

Às vezes, com mensagens de erro distorcidas no final:

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>

Às vezes com erros diferentes:

...
[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>

Observe que dois processos de yarn estão em execução, embora eu tenha especificado --mutex .

Observe que este pacote possui uma dependência git que possui uma etapa tsc prepare que precisa ser executada. Esse pacote também possui uma dependência git que requer o mesmo processo. É claro que o fio está tentando desempacotar o mesmo pacote no mesmo lugar e estamos tendo uma condição de corrida.

Por que o yarn está executando várias instâncias, mesmo quando solicitado a não fazê-lo?

Como uma atualização, usar yarn install --network-concurrency 1 --mutex network parece funcionar sempre que usar uma ou outra opção tende a funcionar apenas parte do tempo.

Então, qual é a resolução para esse problema?
Eu uso o yarn 1.16 no Ubuntu Linux 18.04
E ainda recebo esta mensagem de erro:

erro Ocorreu um erro inesperado: "ENOENT: nenhum arquivo ou diretório, lstat '/ home / user / workspace / project / packages / components / node_modules / source-map-support'".

Meu comando é:

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

E recebo este erro uma vez a cada duas vezes: ((
PS: Eu trabalho em monorepo, então habilitei os espaços de trabalho de fios
PPS:
Eu verifiquei duas vezes
Adicionar arquivo --mutex ou rede --mutex não ajuda.

A única solução que posso confirmar que funciona é colocar um script

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

:(

Fwiw, consegui mudar para npm fazendo nada mais do que localizar / substituir yarn por npm , usando o synp para converter yarn.lock em package-lock.json e executando npm install . Achei que seria um processo doloroso, mas o npm avançou muito e levou apenas 30 minutos e agora funciona em qualquer lugar

Parece que o problema aqui é que não existe um exemplo verdadeiramente simples do que está errado. Publiquei um package.json trivial que reproduz o problema de forma confiável para mim, mas os pacotes incluídos são um tanto complicados.

Suspeito que o problema é quando você tem uma árvore de dependências com "folhas" / dicas compartilhadas que levam tempo para compilar / instalar (preparar) e o yarn tenta fazer isso preparar duas vezes, simultaneamente. Cada instância é "preparada" em um local previsível compartilhado e as duas não podem "gravar" no mesmo local ao mesmo tempo (um exclui um arquivo enquanto o outro espera que ele ainda esteja lá).

Tenho pretendido criar alguns pacotes simples de prova de conceito com etapas infladas de "preparação" para testar essa teoria, mas não tive tempo. Talvez outra pessoa possa testar essa teoria antes de eu chegar a ela?

Isso acontece quando você tem várias instâncias de yarn em execução simultaneamente. Você pode usar a opção --mutex documentada aqui: https://yarnpkg.com/en/docs/cli/#toc -concurrency-and-mutex

@BYK Parece que há muitos casos em que esse não é o problema. Outros até indicaram que esta opção causa outros problemas para eles.

@cinderblock # 6650 parece um caso extremo e não deve realmente afetar a resolução deste problema. O outro exemplo que você mencionou ainda é o yarn sendo acionado no modo de instalação durante outra instalação, o que provavelmente é um pacote problemático, pois você não deve acionar outra instalação durante a instalação do pacote. Isso também pode ser evitado por --ignore-scripts que também é recomendado.

Se você tiver outros leads, compartilhe para que alguém possa passar mais tempo para depurar isso.

@BYK Não vi ninguém usar intencionalmente yarn install dentro de um script install . Você viu este package.json trivial que produz este problema? Concedido, é algo nos pacotes dependentes que provoca esse erro, e talvez eles tenham um install enterrado ao qual você está se referindo. No entanto, package.json funciona muito bem com npm ...

Relacionado, como / onde --ignore-scripts recomendado? Muitos pacotes dependem de scripts de pós-instalação para funcionar.

Relacionado, como / onde é recomendado --ignore-scripts? Muitos pacotes dependem de scripts de pós-instalação para funcionar.

Oh, eu apenas recomendei aqui e acho que muitos membros do Yarn foram vocais sobre isso. 😀 A maioria dos pacotes são bons, mas de fato existem alguns pacotes que dependem de scrpits pós-instalação, sim.

Você viu este package.json trivial

Sim, mas mesmo um arquivo package.json "trivial" pode resultar em uma árvore de dependência muito grande, portanto, dizendo que é trivial, não muda muito, exceto que tendo a interpretá-lo de uma das seguintes maneiras:

• yarn é muito ruim, então nem consegue lidar com este arquivo _trivial_ package.json
• este problema pode ser reproduzido com um arquivo _trivial_ package.json, mas você ainda não pode / não corrigiu

onde nada disso é útil, por isso tendo a ignorar esse seu comentário.

Para o problema real, para o yarn ser executado com o mutex, todas as instâncias do yarn precisam ser chamadas com o sinalizador --mutex então a melhor maneira de ver se isso corrige o problema é adicionar --install.mutex network ao seu .yarnrc file (consulte https://yarnpkg.com/en/docs/yarnrc#toc-cli-arguments). Dito isso, isso pode resultar em um impasse se a instalação inicial acionar outra instalação, onde a segunda instalação irá esperar que a principal termine e a principal será bloqueada neste fio invocado por script para terminar, portanto, eu realmente não saiba como consertar esse problema além de implementar um sistema de cache seguro de thread / processo, que é quase impossível com as primitivas de bloqueio que node fornece. A coisa mais próxima parece ser este pacote de bloqueio adequado , mas nenhum de nós teve tempo para experimentá-lo. Posso ajudá-lo se você estiver interessado em tentar implementar isso no código de gravação / leitura do cache.

@BYK Oh, minhas desculpas se eu saí assim. Eu não tinha visto uma maneira de reproduzir o erro de forma confiável antes disso, mesmo que ele ainda não tenha sido destilado o suficiente para corrigir o problema. Esse foi todo o meu ímpeto para esse comentário.

Desculpe minha persistência, mas ainda não vejo como a opção mutex é uma solução. Eu tentei executar com mutex e ainda executou yarn simultaneamente. Talvez eu tenha cometido um erro no meu teste ? Eu esperava que a execução de yarn --mutex ... passasse essa opção para instâncias filho (como make faz, por exemplo). Também tentei sua sugestão de adicionar --install.mutex network ao meu arquivo .yarnrc sem sucesso (mesmos erros). --verbose confirma que as opções estão sendo carregadas.

Talvez pudéssemos vir de uma direção diferente? O que o yarn está fazendo que o npm não? Por que o npm não tem o mesmo problema?

@BYK , usar a mutex é completamente inaceitável, porque há um bug adicional do yarn que o impedirá de _nunca executar outro comando do yarn _... É como se sua solução para "Eu bloqueei minhas chaves em meu carro "estava," não se preocupe, pensei nisso! Basta usar esta ferramenta útil para quebrar todas as janelas e fechaduras de portas, agora você nunca mais poderá trancar o carro de novo! " 🙄

Trivial package.json ou não, este é um grande problema sem solução ou solução alternativa que torna o fio completamente inutilizável para muitas pessoas. Deve receber mais atenção. Especialmente considerando que está aberto há _dois anos_.

@sarink

@BYK , usar a sinalização mutex é completamente inaceitável, porque há um bug adicional do yarn que o impedirá de executar outro comando do yarn ...

Não estou ciente desse bug, você pode me indicar se ele já foi relatado? A maneira --mutex funciona é evitar que qualquer outra instância de yarn usando o mesmo mutex seja executado, até que o inicial termine. Portanto, o que você diz (não a sua descrição) soa como "funciona conforme o esperado" para mim.

Trivial package.json ou não, este é um grande problema sem solução ou solução alternativa que torna o fio completamente inutilizável para muitas pessoas. Deve receber mais atenção. Especialmente considerando que está aberto há dois anos.

Talvez você deva parar um minuto para refletir sobre a contradição interna de sua própria frase: "torna o fio completamente inútil para muita gente" e "está aberto há dois anos". Existem apenas 56 participantes nesta edição, o que inclui ~ 5 mantenedores do Yarn e um total de 138 comentários, a maioria deles circulando em torno das mesmas coisas. Não se trata de "muitas pessoas", trata-se de _algumas_ pessoas e com certeza é importante para elas, mas vejo que nenhuma delas considera isso tão importante enviar uma única linha de correção de código e simplesmente exigir correções para um software fornecido por completo livre para eles.

@blocos de concreto

Desculpe minha persistência, mas ainda não vejo como a opção mutex é uma solução.

Nada a perdoar em relação à persistência, na verdade é para ser comemorado enquanto você está tentando resolver o problema :)

Eu esperava que a execução de yarn --mutex ... passasse essa opção para instâncias filho (como make faz, por exemplo).

Tenho certeza de que não foi transmitido.

Também tentei sua sugestão de adicionar a rede --install.mutex ao meu arquivo .yarnrc sem sucesso (mesmos erros). --verbose confirma que as opções estão sendo carregadas.

Isso é muito interessante. Pode ser porque a nova instância do yarn foi disparada de outro diretório, ignorando seu arquivo .yarnrc . Posso sugerir o uso de um arquivo global .yarnrc com essa opção, que diz que não acho que seja uma solução adequada. Devemos apenas tentar isso para ver se ele realmente bloqueia a instalação como esperávamos anteriormente.

Talvez pudéssemos vir de uma direção diferente? O que o yarn está fazendo que o npm não? Por que o npm não tem o mesmo problema?

Eu aprecio o pensamento diverso, que disse Yarn e npm são tão diferentes em como eles funcionam, eu não acho que isso realmente se aplica aqui. Se pudermos identificar qual pacote aciona uma instalação do yarn como parte de sua própria instalação, podemos descobrir uma solução. Talvez você possa substituir o executável yarn por algum script bash que registra a origem da invocação, cwd e todos os argumentos passados ​​e, em seguida, executa o yarn normalmente para obter informações úteis de depuração e continuar a partir daí?

A solução definitiva seria uma implementação de cache compatível com a simultaneidade, como mencionei antes, mas com mais informações de depuração, podemos encontrar uma solução alternativa mais barata.

Muito obrigado por sua cooperação com este @cinderblock , muito apreciado.

A solução definitiva seria uma implementação de cache compatível com a simultaneidade, como mencionei antes, mas com mais informações de depuração, podemos encontrar uma solução alternativa mais barata.

Eu acho que deve ser possível fornecer manipulação de simultaneidade simplificada - por exemplo, se outras instâncias de yarn são chamadas durante a etapa de construção, deve haver muito poucas operações de cache pelo processo de yarn superior. Pelo menos, é isso que eu esperava. Certificar-se de que o cache seja liberado para o disco antes de invocar qualquer script possível pode resolver o problema. Não tenho certeza, quão complexo é isso para implementar, no entanto.

@BYK Oh! Não havia considerado a possibilidade de um subpacote estar chamando yarn ... em um script. Você está pensando que a razão de npm install não falhar é porque, quando suas dependências são executadas yarn ... há apenas uma instância em execução?

eu consegui resolver o problema de correr

yarn cache clean
rm ./yarn.lock
yarn install

Este processo, entretanto, leva muito tempo, porque baixa todos os pacotes novamente porque você a) não tem mais cache e seu arquivo de bloqueio foi removido.

Isso pode resolver em sua máquina local, mas o problema com o fio permanece no caso de ser usado em bitrise. É uma imagem limpa, do zero. A simultaneidade da rede é necessária em qualquer caso, mesmo quando o processo de fio único está em execução.

@BYK

Existem apenas 56 participantes nesta edição, que inclui ~ 5 mantenedores do Yarn e um total de 138 comentários, a maioria deles circulando em torno das mesmas coisas.

Parece um número muito alto para este repo. É o maior total de comentários entre todas as questões abertas e fechadas e está entre as contagens de participantes mais altas.

Além do mais, ao pesquisar um (provavelmente) problema relacionado, vi algumas pessoas com problemas que provavelmente estavam relacionados. O infeliz é que muitas dessas pessoas desistiram do fio como um todo ou engoliram o custo de fazer --network-cocurrency 1 sempre que o arquivo de bloqueio do fio mudava. Isso é exatamente o que eu estava fazendo para um de meus projetos até que finalmente descobri que era um sub-script.

Não se trata de "muitas pessoas", são algumas pessoas e com certeza é importante para elas, mas vejo que nenhuma delas considera isso tão importante enviar uma única linha de correção de código e simplesmente exigir correções para um software fornecido por completo livre para eles.

Yarn não é o tipo de projeto em que as pessoas podem entrar facilmente. É um sistema complexo que faz um monte de coisas de maneiras assíncronas, o que significa que você não pode simplesmente instalar um depurador e subir na pilha para ver o que está acontecendo. Como tal, não é fácil entender essa base de código e é ainda mais difícil modificá-la. Inferno, neste ponto eu já gastei alguns dias de tempo cumulativo lendo o código, e ainda não me sinto confiante o suficiente para enviar até mesmo um patch simples com testes relevantes. Dado que tenho mais de duas décadas de experiência e que a leitura de código é uma das minhas especialidades, não daria as maiores chances a um desenvolvedor comum.

Em outras palavras, o que pode ser uma solução rápida e simples de uma linha para você pode ser um grande projeto de vários dias para alguém que não está familiarizado com o funcionamento interno do projeto. Isso é antes de mencionar as políticas implícitas que existem em várias comunidades. Tive pelo menos alguns PRs negados em vários projetos de código aberto porque não segui algum protocolo ou não escrevi o teste certo, obedeci a especificação certa ou mesmo por apenas ter uma correção que não atendia a alguns padrões de codificação não documentados. Pode ser um desafio contribuir de forma significativa para grandes projetos como um estranho.

Se esta é realmente uma correção de uma linha para você, não seria mais rápido apenas escrever essa correção em vez de escrever um longo post criticando os outros por não fazê-lo?

Se pudermos identificar qual pacote aciona uma instalação do yarn como parte de sua própria instalação, podemos descobrir uma solução.

Eu tenho um exemplo de um pacote que exibe esse tipo de comportamento aqui , embora eu não veja um yarn install lá (a menos que bob build faça isso, embora também mostrasse esse problema quando o comando era "prepare": "node ./scripts/generate-mappings", ).

A solução definitiva seria uma implementação de cache compatível com a simultaneidade, como mencionei antes, mas com mais informações de depuração, podemos encontrar uma solução alternativa mais barata.

Um ótimo ponto de partida seria um aviso se tal situação for detectada (assumindo que seja detectável). Um cache amigável de simultaneidade parece que teria que ser um esforço concentrado de pelo menos um membro da comunidade yarn.

A atualização encontrou uma solução alternativa que funciona .... um submódulo git e, em seguida, ter a localização do pacote na pasta local. Não é o ideal, mas funciona.

Estamos tendo esse problema também no CircleCI e é um grande problema. O problema parece estar relacionado ao uso de um pacote hospedado em github.com e talvez Linux (funciona no OSX). mutex e network-concurrency options não fazem nada.

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

se eu remover isso funciona no CircleCI. Localmente funciona com ele no OSX com yarn 1.17.0.

Mas não funcionará em CircleCI com nó 12.8.1 e yarn 1.17.3 (círculo imagem circleci / nó: mais recente)

Ou com Node 8.15.0 e yarn 1.12.3 (círculo imagem 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 com êxito, --network-concurrency 8 com falha, em circleCI / nó: 10

Alguém pode me ajudar a entender por que Yarn precisa falhar em EEXIST e EOENT?

No caso do EEXIST, eu esperaria que o Yarn avisasse sobre isso e, em seguida, substituísse o arquivo.
No caso de EOENT, eu esperaria que o Yarn criasse a pasta ausente (que geralmente é a causa do problema).

Eu entendo que pode ter efeitos colaterais, então talvez esse comportamento possa ser tornado mais rígido com um sinalizador (ou vice-versa).

Mas de que adianta manter esses erros por perto? Eles não são úteis para ninguém.

@BYK Desculpe, acabei de ver seu comentário

Não estou ciente desse bug, você pode me indicar se ele já foi relatado? A maneira --mutex funciona é evitar que qualquer outra instância de yarn usando o mesmo mutex seja executado, até que o inicial termine. Portanto, o que você diz (não a sua descrição) soa como "funciona conforme o esperado" para mim.

Este é o bug: https://github.com/yarnpkg/yarn/issues/6650 conforme mencionado em https://github.com/yarnpkg/yarn/issues/2629#issuecomment -481297806 (que eu acredito que agora está enterrado sob o "mostrar mais história" neste tópico)

Existem apenas 56 participantes nesta edição

Bem, eu acho, esse é um ponto justo

Este bug ainda está no yarn v1.19.1. Não entendo por que o Yarn Team não repara esse bug muito incômodo.
aqui está meu .yarnrc e isso não ajuda:

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

O que acabei de descobrir é que executar npx lerna clean && ./yarn-install-in-loop.sh ajuda.
Limpar (remover) todos os diretórios node_modules em meu monorepo ajuda.

@gitowiec pode confirmar. Minhas invocações yarn install contêineres são dados competindo com algo no sistema de arquivos, e toda tentativa de limitar yarn a um único arquivo .yarnrc falha. Estou desistindo e voltando para npm .

Descobri que meu problema era ter dependências de pacote de repositórios git em vários níveis (ou seja, meu pacote -> pacote git -> pacote git -> pacote git). Além disso, o cache durante a instalação não funcionou bem em comparação com o npm (o npm verifica apenas uma vez, mas o yarn verifica várias vezes o mesmo pacote durante a mesma instalação).
Estou voltando para o npm. Funciona bem desde a v6.

A mencionado acima, esse problema ainda existe. Aqui está o que adicionamos ao nosso config.yml para fazer nossos testes passarem:
- run: name: Yarn Install source ~/setyarnpath.sh i=5; until yarn; do echo "Yarn failed. Retrying..."; ((i--)); if [[ "$i" == '0' ]]; then break; fi; done

Eu estava tendo o mesmo problema. Usando macOS e docker-compose, com um volume host [1] que tinha meu código E node_modules dentro dele.

Node_modules alterado para estar dentro de um volume anônimo , mas acho que um volume nomeado também funcionaria. E parece estar funcionando bem agora, e também instalando as dependências MUITO mais rápido.

Meu arquivo docker-compose mudou de:

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

Para:

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

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

Estou vendo um novo erro com yarn recente que acredito ser um novo sintoma desse problema.

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

Nota: yarn stderr/out são os prefixos que meu programa dá para a saída do yarn em meu env

Acredito que este seja o mesmo problema porque meu projeto poderia criar de forma bastante consistente os sintomas antigos da mesma maneira que esses novos sintomas estão acontecendo (e os sintomas antigos pararam).

Para referência, isso acontece na instalação depois que eu limpo o cache do yarn e node_modules ou atualizo uma determinada dependência de pacote git.

A dependência particular do pacote é uma dependência de outro pacote git do qual eu realmente dependo (ambos têm prepare passos semelhantes que dependem do TypeScript). Se eu fizer alterações nessas dependências em #master e fizer yarn upgrade --latest , o problema ocorrerá (e em yarn install subsequentes.

Quando eu atualizo esse subpacote manualmente (em uma pasta node_modules completamente separada!), O yarn install funciona novamente. Isso me faz pensar que o yarn está acidentalmente usando o cache por dois processos simultaneamente e isso está causando os problemas que estamos vendo neste problema.

Isso acontece comigo quando uso 2 ou mais pacotes instalados pela dependência git. De alguma forma, existem vários processos para o mesmo pacote executando o script prepare . Além disso, ele começa a falhar com o npm também nas últimas versões.

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

Isso foi aberto por anos e ainda acontece com o fio 1.22.0.
Passei horas tentando depurar o que estava acontecendo, sem sorte, e parece que não fui o único.

A única solução que estou vendo agora é mudar para npm.

@gregory No meu caso, lembro-me de que em junho de 2019, o yarn sempre terminava instalando os pacotes necessários, mesmo que ainda era mais rápido do que o npm.

Eu executaria novamente até que o fio terminasse usando comandos como este:

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

A solução mais fácil para nós foi publicar um pacote privado e usá-lo em vez de um link git. Ainda é chato

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

Realmente triste que a única correção seja a força bruta ... inacreditável que ninguém consertou isso ainda.

cc @arcanis

Tentar instalar dois fios subsequentes funciona pela primeira vez e depois falha.

Gerenciamento de dependências rápido, confiável e seguro.

Isso não é confiável.
`` `[3/5] Obtendo pacotes ...
erro https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Falha ao extrair conteúdo tar de undefined, o arquivo parece estar corrompido: "ENOENT: nenhum arquivo ou diretório, link '/ app /.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lachez4yarnode '->' /app/ /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-Integrity / node_modules / lz4 / build / Release / obj.target / lz4.node '"
informações Visite https://yarnpkg.com/en/docs/cli/install para documentação sobre este comando.
[1/5] Validando package.json ...
[2/5] Resolvendo pacotes ...
[3/5] Buscando pacotes ...
info Parece haver problemas com sua conexão de rede. Tentando novamente ...
info [email protected] : A plataforma "linux" é incompatível com este módulo.
info " [email protected] " é uma dependência opcional e falha na verificação de compatibilidade. Excluindo-o da instalação.
info [email protected] : A plataforma "linux" é incompatível com este módulo.
info " [email protected] " é uma dependência opcional e falha na verificação de compatibilidade. Excluindo-o da instalação.
[4/5] Vinculando dependências ...
[5/5] Construindo novos pacotes ...
$ npm run prepare: mjs && npm run prepare: js

[email protected] prepare: mjs /app/.cache/yarn/v6/.tmp/43563e016bb56318ebd76037a0f6ce2f.73d5f4dbffab6f6a27f26c6611e32662c98c2891.prepare
BABEL_ESM = 1 babel src -d. --keep-file-extension

39 arquivos compilados com sucesso com o Babel.

[email protected] prepare: js /app/.cache/yarn/v6/.tmp/43563e016bb56318ebd76037a0f6ce2f.73d5f4dbffab6f6a27f26c6611e32662c98c2891.prepare
babel src -d.

39 arquivos compilados com sucesso com o Babel.

[3/5] Buscando pacotes ...
erro https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Falha ao extrair conteúdo tar de indefinido, o arquivo parece estar corrompido: "ENOENT: nenhum arquivo ou diretório, link '/ app /.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lachez4yarnode '->' /app/ /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-Integrity / node_modules / lz4 / build / Release / obj.target / lz4.node '"
informações Visite https://yarnpkg.com/en/docs/cli/install para documentação sobre este comando.
info Parece haver problemas com sua conexão de rede. Tentando novamente ...

`` `

Alguém tem alguma ideia de por que o fio chamaria

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'"

quando o caminho certo deveria ser:

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

parece que o fio está adicionando obj.target/build/Release/ por algum motivo. Pode estar relacionado a https://github.com/yarnpkg/yarn/commit/0e7133ca28618513503b4e1d9063f1c18ea318e5

Eu estava recebendo esse mesmo erro frustrante e difícil de depurar. O problema no meu caso parecia ser yarn workspace comportamento causado por diferentes versões da mesma dependência em diferentes pacotes (especificamente ava versões 2 e 3). Somente depois de atualizar todas as ocorrências de ava para as últimas, parei de receber este erro.

Estou executando 1.22.4 e fiquei preso neste problema por horas. Nosso monorepo possui vários módulos usando os mesmos pacotes. Finalmente resolvi aplicando o seguinte:
1) Certifique-se de usar a mesma versão de um pacote em todos os módulos - isso causará uma falha com certeza, mesmo em devDependencies .
2) Fixar todas as versões no monorepo em todos os arquivos package.json .

Pode confirmar ainda um problema em 1.22.4 . Originalmente, era mocha , e depois de ter certeza de que todos os pacotes estavam usando a mesma versão, agora estou recebendo erros gerados a partir de camelcase que eu nem mesmo uso em meu projeto - aparentemente é de yargs , possivelmente de Lerna.

erro Ocorreu um erro inesperado: "ENOENT: nenhum arquivo ou diretório, lstat '/ code / project / src / packages / private-package / node_modules / camelcase'".

Posso perguntar se há uma solução à vista? Continuamos excluindo 20 node_modules e yarn.lock para consertar.

Posso perguntar se há uma solução à vista? Continuamos excluindo 20 node_modules e yarn.lock para consertar.

Eu, pessoalmente, mudei para a lerna em relação ao manuseio do espaço de trabalho.

Quase certo que a atual Lerna simplesmente passa para Yarn.

Consegui contornar meus problemas adicionando uma configuração nohoist para pacotes Ember - meu env atual está usando uma versão mais antiga do Ember, que é incompatível com áreas de trabalho.

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

Acho que temos uma reprodução mínima aqui agora: https://github.com/yarnpkg/yarn/issues/7212#issuecomment -637978197

Excluir yarn.lock depois yarn install funcionou para mim

Alguma notícia aqui? Nosso processo de CI simplesmente caiu com todos os pipelines falhando por causa da falha de instalação de dependência do yarn. Isso é ridículo.

Definir --network-concurrency não corrige nada e os trabalhos são executados em máquinas limpas (sem node_modules, sem yarn .cache).

@cadavre Não dá nenhuma garantia, mas isso pode não ser um problema na v2, você pode tentar com

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

Isso começou a acontecer comigo também, depois de atualizar algumas das minhas dependências vue e firebase. Agora 100% repetível em minhas máquinas de CI e dev. Adicionar --network-concurrency 1 não o corrige de forma confiável. Não estou sem espaço em disco ou inodes. Estou no WSL1. Fios 1.22.4.

Consertei alterando temporariamente o diretório de cache, que excluo logo em seguida.

Para mim, é uma versão do Docker:

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