Yarn: Extração do conteúdo tar de undefined falhou

Criado em 27 ago. 2018  ·  69Comentários  ·  Fonte: yarnpkg/yarn

Você quer solicitar um recurso ou relatar um bug ?
Relatando um bug ao executar yarn install para instalar dependências de nó. Para a gravidade, esse bug parece crítico, considerando que essencialmente me impede de adquirir dependências de nó.

Qual é o comportamento atual?
Às vezes falha com erros como o seguinte:

yarn install v1.9.4
[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 https://registry.yarnpkg.com/lodash/-/lodash-4.17.10.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/usr/local/share/.cache/yarn/v2/npm-lodash-4.17.10-1b7793cf7259ea38fb3661d4d38b3260af8ae4e7/_cacheHas.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn install v1.9.4
[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 https://registry.yarnpkg.com/lodash/-/lodash-4.17.10.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "EEXIST: file already exists, mkdir '/usr/local/share/.cache/yarn/v2/npm-lodash-4.17.10-1b7793cf7259ea38fb3661d4d38b3260af8ae4e7'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn install v1.9.4
[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 https://registry.yarnpkg.com/fbjs/-/fbjs-0.8.17.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/usr/local/share/.cache/yarn/v2/npm-fbjs-0.8.17-c4d598ead6949112653d6588b01a5cdcd9f90fdd/lib/resolveImmediate.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command

A ocorrência desse erro é a parte desafiadora. Nem sempre falha e nem sempre falha com a mesma dependência. A instalação às vezes é bem-sucedida após 3-5 tentativas.

Se o comportamento atual for um bug, forneça as etapas para reproduzir.
Tentei instalar dependências em bare-metal e em um contêiner do docker node:8-alpine . Ambos às vezes podem encontrar o erro. Eu testei isso em meu dispositivo pessoal em Montreal, Canadá (Mac OS X10.13), em uma instância AWS EC2 (Ubuntu 18.04), em uma instância GCE (Ubuntu 16.04) e em um servidor de produção na França (Debian 8) . Cada um deles às vezes pode encontrar esse erro. Também tentei instalar com e sem yarn.lock sem sucesso. Encontre um package.json que às vezes pareça reproduzir o problema nesta essência . O problema não parece acontecer com projetos com menos dependências.

Qual é o comportamento esperado?
Instalação bem-sucedida de todos os pacotes como npm install ou npm ci que deterministicamente teve sucesso sem erros de tar ou cache.

Mencione seu node.js, yarn e versão do sistema operacional.
Testado com a seguinte versão:
Nó: 8 LTS, 10
Fio: 1.9.2, 1.9.4
SO: Ubuntu 18.04 LTS, Ubuntu 16.04 LTS, Debian 8, Mac OSX 10.13
Registrie: registry.yarnpkg.com , registry.npmjs.org , registro privado

Se você precisar de alguma informação adicional, não hesite em solicitá-la. FWIW, reduzir a simultaneidade de rede parece produzir uma taxa de sucesso ligeiramente maior, mas não de forma consistente o suficiente para concluir que os erros estão relacionados. No entanto, pode ser uma área a ser investigada. Infelizmente, esgotei todo o tempo que podia gastar com isso depois de alguns dias para solucionar problemas. Relutantemente, tive que migrar todas as nossas compilações de CI de volta para o uso de npm install / npm ci :(

cat-bug triaged

Comentários muito úteis

Não há ~/.npmrc criado no meu caso. Mas regenerar yarn.lock funcionou para mim.

Simplesmente,

$ rm yarn.lock && yarn

EDIT: Enfrentei esse problema duas vezes apenas para acabar pousando aqui. :sorriso:

Todos 69 comentários

Mesmo problema, está bloqueando meu CI também, atualizamos recentemente para o yarn 1.9.2

@opiation O erro é de fato aleatório, mas posso ter encontrado a causa: você tem URLs git distantes em seu package.json sem .git no final? Tínhamos dois deles e adicionar .git corrigiu o problema. Não sei por que a mensagem de erro não afirma diretamente esse é o problema.

Além disso, talvez relacionado a: https://github.com/yarnpkg/yarn/issues/5536

@adrienharnay , você pode definir o que você quer dizer com _distant_? Para registro, aqui está o package.json que usei . Há apenas uma dependência do github e ainda recebo erros sem ela. Não sei como acrescentaria .git a dependências não git, a menos que tenha entendido mal sua sugestão.

Distante não era a palavra certa, eu apenas quis dizer pacotes instalados do Git 🙂

Você poderia tentar isso?

"storybook-addon-markdown": "https://github.com/mihalik/storybook-addon-markdown.git"

De acordo com meu comentário anterior, ainda encontro o problema sem a dependência de storybook-addon-markdown . Portanto, não acredito que esse problema decorra do manuseio incorreto de URLs git pelo yarn.

Na verdade, eu li muito rápido. Bem, isso corrigiu nosso bug, mas eu não tenho ideia sobre o seu 😕 Desculpe

@opiation Você atualizou seu arquivo yarn.lock também? Porque eu tive que fazer isso

@Titozzz , encontro este erro com e sem o arquivo yarn.lock . Excluí e recriei o arquivo de bloqueio várias vezes, sem sucesso.

Eu também entendi e não tenho nenhum pacote do git.

Eu queria contornar esse problema (https://github.com/yarnpkg/yarn/issues/6256) usando as versões tarball dos pacotes, mas, na verdade, o erro acima é lançado para urls tarball na empresa Github auto-hospedada.

Github.com hospedou tarballs de alguma forma funcionou. por exemplo
https://github.com/luwes/chameleon/archive/grasshopper-v0.0.1-beta.4.tar.gz

Estou vendo o mesmo problema com um projeto que temos. No entanto, quando eu removo os deps que executam um script prepare como parte da instalação (por serem urls git), ele funciona. Acontece que estes estão apontando urls git, mas eu acho que na verdade são os prepare que parecem iniciar mais yarn install processos que parecem subverter o sinalizador mutex por algum motivo. Eu me pergunto se isso é porque os outros processos são iniciados pelo processo raiz em vez de por processos raiz diferentes. Não sei se esta informação ajuda ou se na verdade está muito errada. Mas achei que deveria compartilhar o que descobri de qualquer maneira.

@khendry Eu peguei o problema de novo, e você está certo, ele vem de dependências git que têm um script prepare em seu package.json! : +1:

Eu tenho rastreado isso com um projeto que temos e até agora reduzi para a instalação simultânea que o git-fetcher começa aqui . Se o pacote que está sendo instalado pelo git-fetcher tiver qualquer uma das mesmas dependências do pacote atualmente em instalação, uma condição de corrida é criada, onde os pacotes duplicados serão descompactados para o cache offline ao mesmo tempo.

Eu não vi o suficiente da base de código para entender onde / qual é a correção correta, mas esse é o início do problema.

Alguma novidade sobre isso? Também estamos enfrentando esse problema.

Mesmo problema. É impossível usar fio com CI. Cada 2ª compilação falhou com este erro 😞

tente excluir node_modules,

yarn cache clean
yarn install --network-concurrency 1

Obrigado por compartilhar isso. É pelo menos uma solução alternativa 🤗, mas nenhuma solução real se você quiser que seu tempo de compilação seja razoavelmente rápido 😅

Tentamos usar a bandeira --network-concurrency sem sucesso. Portanto, isso não resolve realmente esse problema específico. O sinalizador aborda a simultaneidade em um nível mais alto do que onde o problema ocorre.

Para mim, --network-concurrency 1 resolve o problema. Eu sei que é uma correção temporária, mas funciona. Mas o valor deve ser exatamente 1 .

Eu falei cedo demais. Eu perguntei ao meu companheiro de equipe se tínhamos tentado isso, ao invés de realmente tentar eu mesmo e ele estava _muito_ confiante de que tínhamos ... ele se enganou e leu errado o post anterior pensando que estava relacionado ao sinalizador mutex, não à rede simultaneidade. Tentamos novamente e podemos confirmar que isso também parece resolver o problema para nós.

definir --network-concurrency 1 não funciona realmente para mim.

agora, a única solução que encontrei envolve regenerar completamente yarn.lock . O erro que recebo é:

2.054 Performing "GET" request to "https://<private-artifactory-npm-registry>/@myorg/eslint-plugin-import/-/@myorg/eslint-plugin-import-3.0.0.tgz".
verbose 2.519 Error: https://<private-artifactory-npm-registry>/@myorg/eslint-plugin-import/-/@myorg/eslint-plugin-import-3.0.0.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"
    at MessageError.ExtendableBuiltin (/Users/me/.nvm/versions/node/v8.12.0/lib/node_modules/yarn/lib/cli.js:237:66)
    at new MessageError (/Users/me/.nvm/versions/node/v8.12.0/lib/node_modules/yarn/lib/cli.js:266:123)
    at Extract.<anonymous> (/Users/me/.nvm/versions/node/v8.12.0/lib/node_modules/yarn/lib/cli.js:59446:14)
    at emitOne (events.js:121:20)
    at Extract.emit (events.js:211:7)
    at Extract.module.exports.Extract.destroy (/Users/me/.nvm/versions/node/v8.12.0/lib/node_modules/yarn/lib/cli.js:135306:17)
    at Extract.module.exports.Extract._final (/Users/me/.nvm/versions/node/v8.12.0/lib/node_modules/yarn/lib/cli.js:135364:34)
    at callFinal (/Users/me/.nvm/versions/node/v8.12.0/lib/node_modules/yarn/lib/cli.js:70270:10)
    at _combinedTickCallback (internal/process/next_tick.js:139:11)
    at process._tickCallback (internal/process/next_tick.js:181:9)

Atualização: acabei de descobrir que usar --skip-integrity-check me permite ignorar esse erro. Embora, obviamente, isso seja realmente uma solução. Isso parece um bug importante na lógica de verificação de integridade.

Estou usando [email protected] , [email protected]

@arcanis @ rally25rs mais detalhes sobre este erro:

screen shot 2018-10-28 at 10 04 18 am

screen shot 2018-10-28 at 10 08 07 am

Então, parece muito estranho para mim que esteja falhando na soma de verificação de integridade, considerando que os sha1 são os mesmos:

Error: sha1-Sl7Hxk364iw6FBJNus3uhG2Ay8Q= integrity checksum failed when using sha1: wanted sha1-Sl7Hxk364iw6FBJNus3uhG2Ay8Q= but got sha1-AHoWKXweP+Pg9aZkGBsAjFruGaM=. (77 bytes)
    at Transform.on (/Users/shargrove/.nvm/versions/node/v8.12.0/lib/node_modules/yarn/lib/cli.js:32831:19)
    at emitNone (events.js:111:20)
    at Transform.emit (events.js:208:7)
    at endReadableNT (_stream_readable.js:1064:12)
    at _combinedTickCallback (internal/process/next_tick.js:139:11)
    at process._tickCallback (internal/process/next_tick.js:181:9)

Atualização: depois de ver acima, confirmei que --skip-integrity-check ignora esse erro. Parece um bug mais sério na lógica de verificação de integridade.

@opiation por curiosidade, você pode colar seu package.json? Você está usando a seguinte técnica de "substituição" em algum lugar?

"dependencies": {
  "foo": "npm:@myorg/foo"
}

Por exemplo, estou usando:

"eslint-plugin-import": "npm:@myorg/eslint-plugin-import",

E, este é o pacote que vejo o erro para .. Então, será que isso está relacionado?

@hulkish , de acordo com meu post inicial, aqui está a essência que criei com meu package.json , yarn.lock e todos os testes que executei que produziram o erro descrito. Para esclarecer, cada linha em failing_test.sh pode encontrar esse erro, mas não de forma consistente. Pode ser necessário tentar mais de uma vez para encontrar o erro. Só para constar neste tópico, vou resumir cada teste abaixo:

Testes reprovados

  • yarn install
  • yarn install --frozen-lockfile
  • yarn install --pure-lockfile
  • yarn install --mutex network
  • yarn install --network-concurrency 1
  • Todos os testes acima com rm yarn.lock antecipadamente
  • Todos os testes acima em um contêiner node:alpine com git instalado (alpino no momento em que este tópico foi criado)
  • Todos os testes acima em um contêiner node:8-alpine com git instalado

Quanto à técnica de "substituição", não tenho certeza do que você quer dizer. Se você está se referindo ao prefixo do tipo _protocol_ no valor da dependência (como npm: em seu exemplo), então sim, uma dependência dev usa um pacote github :

"storybook-addon-markdown": "github:mihalik/storybook-addon-markdown"

Os erros ainda são encontrados, no entanto, mesmo quando eu removo a dependência dev, então isso não parece relacionado.

Grite para @holyxiaoxina - adicionar --network-concurrency 1 resolveu isso para o meu IC 👍

ping @imsnif ? Parece relacionado à verificação de integridade, de acordo com o comentário de

@khendry Não usar o prepare mais em nossas dependências git resolveu isso para o nosso ci, enquanto --network-concurrency 1, --child-concurrency 1 e --skip-integridade-check não eram suficientes

Conseguimos corrigir isso com npm config set always-auth true (conforme documentado aqui ). Pelo que posso dizer, o npm por padrão fornecerá suas credenciais _apenas_ para publicar pacotes, não para buscá-los. Por algum motivo, o fio não respeitava essa configuração, mas agora respeita.

Recentemente, tive esse problema, usando yarn 1.12.3 e node 10.13.0 . Depois de tentar muitas das soluções acima, sem sucesso, excluir / regenerar o arquivo yarn.lock funcionou.

Tenho recebido um problema semelhante. Remover yarn.lock como @mvonballmo sugeriu foi a única coisa que o fez funcionar. Ainda não está funcionando totalmente.

yarn install v1.12.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error https://registry.yarnpkg.com/iconv-lite/-/iconv-lite-0.4.23.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOSPC: no space left on device, write"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn install v1.12.3
info No lockfile found.
[1/4] Resolving packages...
warning celebrate > joi > [email protected]: This version is no longer maintained. Please upgrade to the latest version.
warning xo > eslint > file-entry-cache > flat-cache > [email protected]: CircularJSON is in maintenance only, flatted is its successor.
[2/4] Fetching packages...
error https://registry.yarnpkg.com/babel-runtime/-/babel-runtime-6.26.0.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOSPC: no space left on device, write"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Oi amigos,

Portanto, a julgar pelos diferentes erros relatados aqui - na verdade, parece que podem haver vários problemas diferentes:
ENOSPC: no space left on device, write ,
wanted sha1-Sl7Hxk364iw6FBJNus3uhG2Ay8Q= but got sha1-AHoWKXweP+Pg9aZkGBsAjFruGaM= (aliás, dá uma olhada, mas não são iguais),
the file appears to be corrupt: "Unexpected end of data" , etc.

Embora eu reconheça que isso pode estar acontecendo em um lugar semelhante, eles podem ser causados ​​por problemas e / ou ambientes totalmente diferentes. A verificação de integridade (especificamente o untarStream no retorno de chamada de erro - obrigado pela depuração detalhada @hulkish!) É um funil que pode reunir muitos erros e é um pouco difícil fornecer feedback além do erro real para o usuário.

O acima é especialmente verdadeiro para a migração de integridade (preenchendo um yarn.lock antigo com os novos campos de integridade), uma vez que este processo único (uma vez supondo que seja bem-sucedido ofc) requer mais rede do que uma instalação normal (ele percorre todos os pacotes sem um campo integrity e busca seu manifesto de registro).

As teorias sobre uma condição de corrida são interessantes e definitivamente uma possibilidade, eu ficaria feliz em examiná-las mais detalhadamente. Infelizmente , a reprodução de yarn para instalá-lo com aquele package.json e yarn.lock - eu entendo isso ainda causou o problema para você?)

@opiation - você ainda pode reproduzir este problema? Nas mesmas condições? Talvez possamos descer um nível de resolução e você pode me dizer tudo o que você faz até os comandos para fazer isso acontecer.

Alguém mais neste tópico tem uma configuração que pode compartilhar que reproduz esse problema, mesmo que parcialmente de maneira consistente? Eu ficaria muito feliz em chegar ao fundo disso.

Encontrei a mesma mensagem de erro em meu sistema de CI:

2018-11-12T04:32:13.0386630Z error https://pkgs.dev.azure.com/JeremyTCD/_packaging/Main/npm/registry/cheerio/-/cheerio-0.22.0.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"
2018-11-12T04:32:20.4838361Z 
2018-11-12T04:32:20.4852626Z     yarn install v1.12.3                                                                    
2018-11-12T04:32:20.4853491Z     [1/4] Resolving packages...                                                             
2018-11-12T04:32:20.4855400Z     [2/4] Fetching packages...                                                              
2018-11-12T04:32:20.4856037Z     info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Mas consegui descobrir meu problema particular. Pensei em deixar uma nota aqui para quem encontrar algo semelhante:

Causa

Chamei yarn install em minha máquina local depois de adicionar uma nova dependência ao meu projeto ([email protected]). Devido a um .npmrc , o yarn restaurou a dependência de um registro privado meu. O yarn.lock gerado continha as seguintes linhas:

[email protected]:
  version "0.22.0"
  resolved "https://pkgs.dev.azure.com/JeremyTCD/_packaging/Main/npm/registry/cheerio/-/cheerio-0.22.0.tgz#a9baa860a3f9b595a6b81b1a86873121ed3a269e"
  dependencies:
  ...

Observe como o pacote foi resolvido de um repositório privado. Na minha máquina de CI, eu não tinha um .npmrc com as credenciais para o registro privado. Esta foi a causa da mensagem de erro:

https://pkgs.dev.azure.com/JeremyTCD/_packaging/Main/npm/registry/cheerio/-/cheerio-0.22.0.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"

Consertei meu .npmrc e regenerou meu yarn.lock :

[email protected]:
  version "0.22.0"
  resolved "http://registry.npmjs.org/cheerio/-/cheerio-0.22.0.tgz#a9baa860a3f9b595a6b81b1a86873121ed3a269e"
  integrity sha1-qbqoYKP5tZWmuBsahocxIe06Jp4=

Observe como o pacote agora é resolvido do registro NPM padrão. O erro parou de ocorrer depois que fiz isso.

Consertar

Se a causa do seu problema for igual à minha, você pode:

  • Adicione as credenciais necessárias à sua máquina CI ou
  • Ajuste seu .npmrc ( yarn config list imprimirá o registro do qual o yarn restaura) e, em seguida, regenere yarn.lock .

Notas

Talvez a mensagem de erro possa ser mais específica.

Edit: Inicialmente pensei que reverter o Yarn resolveria o problema - acidentalmente vinculei meu commit defeituoso a esse problema. O fio não foi o problema no final.

TL; DR: tente excluir seu arquivo yarn.lock e gerá-lo novamente.

Recebi um erro ao tentar construir no Netlify: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"

Excluir a pasta node_modules e o arquivo yarn.lock e gerá-los novamente por meio de yarn install me deu um novo arquivo yarn.lock com dependências diferentes. Com este novo arquivo o Netlify construiu com sucesso meu projeto.

@imsnif concorda que aparentemente existem vários problemas diferentes sendo relatados aqui. Acho que tenho um caso de reprodução de um projeto no qual estou trabalhando que aciona o problema descrito por @khendry aqui

Estou vendo o mesmo problema com um projeto que temos. No entanto, quando eu removo os deps que executam um script prepare como parte da instalação (por serem urls git), ele funciona. Acontece que estes estão apontando urls git, mas eu acho que na verdade são os prepare que parecem iniciar mais yarn install processos que parecem subverter o sinalizador mutex por algum motivo. Eu me pergunto se isso é porque os outros processos são iniciados pelo processo raiz em vez de por processos raiz diferentes.

Compartilhar as etapas de reprodução abaixo na esperança de permitir que você reproduza o problema. Deixe-me saber se você precisar de mais informações.

Etapas Repro

  1. Com o nó v10.3.0 e yarn v1.12.3 , em uma nova pasta de teste, baixe package.json e yarn.lock desta essência
  2. execute rm -rf ~/.cache/yarn* node_modules/ && yarn install --frozen-lockfile --network-concurrency 16 (limpe o cache e instale previamente os módulos de nó para um ambiente confiável. Defina a simultaneidade como alta para aumentar as chances de problemas)
  3. observe a saída como a seguir:
yarn install v1.12.3
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
warning Pattern ["object-assign@latest"] is trying to unpack in the same destination "/home/ocderby/.cache/yarn/v4/npm-object-assign-4.1.1-2109adc7965887cfc05cbbd442cac8bfbb360863/node_modules/object-assign" as pattern ["object-assign@^4.1.0","object-assign@^4.1.0","object-assign@^4","object-assign@^4.1.1","object-assign@^4.1.0","[email protected]","object-assign@^4.1.0","object-assign@^4.1.1","object-assign@^4.1.0","object-assign@^4.1.0","object-assign@^4.1.0","object-assign@^4.1.0","object-assign@^4.1.0","object-assign@^4.1.0","object-assign@^4.1.0","object-assign@^4.1.1","object-assign@^4.1.1","object-assign@^4.0.1","object-assign@^4.0.1","object-assign@^4.1.0","object-assign@^4.0.1","object-assign@^4.0.1","object-assign@^4.0.1","object-assign@^4.1.0","object-assign@^4.0.1"]. This could result in non-deterministic behavior, skipping.
info No lockfile found.
[1/4] Resolving packages...
warning eslint > file-entry-cache > flat-cache > [email protected]: CircularJSON is in maintenance only, flatted is its successor.
warning jest > jest-cli > prompts > [email protected]: Please upgrade to kleur<strong i="26">@3</strong> or migrate to 'ansi-colors' if you prefer the old syntax. Visit <https://github.com/lukeed/kleur/releases/tag/v3.0.0\> for migration path(s).
[2/4] Fetching packages...
error https://registry.yarnpkg.com/lodash/-/lodash-4.17.4.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/home/ocderby/.cache/yarn/v4/npm-lodash-4.17.4-78203a4d1c328ae1d86dca6460e369b57f4055ae/node_modules/lodash/_shortOut.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Outras notas

Tentei uma variedade de coisas, aqui estão minhas notas:

  1. O problema não se reproduz 100% do tempo para mim. Conforme observado acima, aumentar a simultaneidade de rede usada parece tornar o problema mais provável de ocorrer.
  2. Usar uma versão de react-textarea-autosize publicada no registro do pacote faz o problema desaparecer (parecendo confirmar o que @khendry relatou acima)
  3. Definir --mutex file não parece ajudar em nada aqui
  4. Conforme relatado acima, se eu limitar a simultaneidade de rede a 1 (por meio do argumento --network-concurrency 1 ), tudo será instalado corretamente, embora mais lento.
  5. Eu reproduzi isso no nó v8.12.0, com yarn v1.9.4 e v1.12.3. Isso estava sendo executado na imagem do docker circleci/node:8-stretch em execução no Circle CI 2.0.

Comecei a ver esse erro recentemente depois de atualizar o fio para 1.12.3 .
Veja minha falha de compilação travis-ci https://travis-ci.org/ankurk91/vue-cleave-component

$ yarn install --non-interactive
yarn install v1.12.3
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.2.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
The command "yarn install --non-interactive" failed and exited with 1 during .

Isso está acontecendo apenas com [email protected] .
Vou postar de volta se eu tiver sucesso de alguma forma.
PS.
Era específico para o pacote do validador har.

Eu também consigo
error https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.2.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"
com curl, obtive 404 para https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.2.tgz
mas no meu navegador posso baixá-lo.
Se eu fizer downgrade do yarn para 1.12.1, um dos meus servidores começará a funcionar, mas no outro servidor, mesmo se eu fizer downgrade, o erro permanece o mesmo (removo o diretório do cache do yarn em ambos os casos).
É possível que seja algum tipo de problema de cloudflare (configuração)?

Não, esta instância específica (a sua e a de @ ankurk91) foi causada por har-validator ter sido publicada (cf # 6694).

Recebo este erro apenas no meu ambiente de CI, depois de adicionar outro repo como uma dependência ( "@team/myproject": "git+ssh://[email protected]/team/myproject.git#master", ). Eu posso confirmar isso

  • adicionar --network-concurrency 1 ao meu script de CI resolve o problema, mas é claro torna a compilação muito lenta
  • executando yarn install --network-concurrency 16 provoca o erro localmente também

Nem limpar o cache nem redefinir yarn.lock fez diferença para mim

EDITAR: Parece que a correção --network-concurrency 1 não é consistente, infelizmente 😢

mesmo erro aqui,
fácil de reproduzir:
yarn upgrade typescript@^2.8

então:
yarn upgrade [email protected]

Eu fiz ctrl + c enquanto instalava este último pacote .. e quando tento 'yarn upgrade' novamente, recebo:


yarn upgrade v1.12.3
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error https://registry.yarnpkg.com/typescript/-/typescript-2.8.4.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat '/Users/u/Library/Caches/Yarn/v4/npm-typescript-2.8.4-0b1db68e6bdfb0b767fa2ab642136a35b059b199/node_modules/typescript/lib/lib.d.ts'"
info Visit https://yarnpkg.com/en/docs/cli/upgrade for documentation about this command.

ATUALIZAÇÃO: O seguinte foi devido a metadados corrompidos em nossa instalação Sonatype Nexus e, portanto, não é um problema do Yarn. Saindo para o contexto.

Vendo isso para vários pacotes em nosso ambiente de CI. Fio 1.12.3 e Nó 11.1:

responsive-props-1.2.2.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Invalid tar header. Maybe the tar is corrupted or it needs to be gunzipped?"
styled-components-breakpoint-2.1.3.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Invalid tar header. Maybe the tar is corrupted or it needs to be gunzipped?"

Tive um problema semelhante, mas recebo ... o arquivo parece estar corrompido: "EBUSY: ...".
Limpei todo o cache do yarn e o executei novamente e ainda obtive o mesmo erro, então parece que o yarn está criando arquivos e os bloqueando por si mesmo.

Isso está no Windows 10.

yarn install v1.10.1 [1/4] Resolving packages... [2/4] Fetching packages... error https://registry.yarnpkg.com/fbjs/-/fbjs-0.8.17.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "EBUSY: resource busy or locked, open 'c:\\src\\yarn\\cache\\v2\\npm-fbjs-0.8.17-c4d598ead6949112653d6588b01a5cdcd9f90fdd\\lib\\UserAgent.js'" info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Eu fiz uma solução alternativa executando "yarn --pnp" que funcionou. Estranho, já que deveria ser um código mais recente e provavelmente mais instável.

Remover yarn.lock foi o que o fez funcionar para mim.

Olá a todos, apenas tive o mesmo problema. Resolvido removendo .npmrc do diretório inicial.

rm ~/.npmrc

@binchik - essa é a única coisa que funcionou para mim.

Obrigado @binchik , isso funcionou para mim. 👍

Então, depois de voltar para a série de eventos que levaram à falha de yarn , acredito que executei um script npm em um package.json que era mais ou menos assim:

"audit": "npm audit"

O que é totalmente bobo, porque eu nunca uso npm nesse projeto. Após este comando, tudo (incluindo npm) apenas começaria a ter falhas aleatórias e nunca seria concluído, de acordo com a experiência de outros neste segmento.

Se alguém reproduzindo o erro pudesse investigar e descobrir o que exatamente está causando o problema, seria muito útil! Já tentei, mas não consigo reproduzir 🙁

Algumas dicas:

  • Precisamos descobrir o que entra em untarStream quando ele falha - minha hipótese é que talvez estejamos tentando processar uma resposta json como um tarball (https://github.com/yarnpkg/yarn/blob/master /src/fetchers/tarball-fetcher.js#L146-L150)

  • a única coisa que acho que poderia importar no .npmrc é o token de autenticação. Eu apreciaria se alguém pudesse confirmar que o problema desapareceu simplesmente removendo a linha do token de autenticação de .npmrc (em vez de todo o arquivo)

FWIW, encontrei este problema hoje. Algumas coisas:

  • A remoção de .npmrc corrigiu. A única coisa no arquivo tinha a ver com o token de autenticação.
  • npm install também falhou e registrou um erro 401 não autorizado.
  • Depois de remover o arquivo .npmrc , npm install funcionou novamente.

@deleteme de acordo com minhas descobertas, isso soa mais como um subproduto do bug do que como a causa.

Encontrei com e sem .npmrc ou .yarnrc

Dado que esse problema de repente aparece muito mais do que o normal e que é durante o registro npm sendo especialmente fragmentado , é bem provável que minha hipótese não esteja muito distante

@arcanis começou a ter esse problema hoje. Posso confirmar que, ao remover essa linha de token de autenticação npmrc, o problema foi resolvido.

Não há ~/.npmrc criado no meu caso. Mas regenerar yarn.lock funcionou para mim.

Simplesmente,

$ rm yarn.lock && yarn

EDIT: Enfrentei esse problema duas vezes apenas para acabar pousando aqui. :sorriso:

No meu caso, eu uso o CircleCI, a imagem circleci/node:10.11.0 docker e [email protected] e não há ~/.npmrc . Obrigada @achillesrasquinha. Funciona para mim.

Tenho enfrentado esse problema há mais de uma semana. yarn install --network-concurrency 1 resolveu o problema, mas é muito lento.

Aliás, essa informação pode ser útil para qualquer pessoa.
Eu estava usando um pacote NPM personalizado (interno) em meu projeto. Sempre estou tendo o mesmo problema como .cache/v4 mas mostrando nomes de pacotes diferentes a cada falha. Depois de passar muito tempo, encontro uma observação aleatória.
Meu projeto e pacote npm personalizado estão usando o mesmo yarn build para construir o pacote. Eu atualizei meu nome de script de construção de pacote personalizado para outro nome como yarn build:p . Então é começar a trabalhar. Corri build muitas vezes. Não falhou. Não tenho certeza como esses 2 são dependentes, mas funcionaram para mim.

Remover .npmrc apenas não funcionou para mim. Eu também tive que remover meu arquivo yarn.lock como @davidalee mencionado. Eu não sei por que ele está sendo rejeitado por isso 🤷‍♂️

Não tenho certeza se remover .npmrc teve algum efeito para mim.

Não sou muito fã de deletar o arquivo yarn.lock então o que fiz foi apenas remover o pacote har-validator do yarn.lock e depois executar novamente yarn que corrigiu o problema para mim.

Sim rm yarn.lock trabalha para mim. Enfrentando problemas com o pacote har-validator-5.1.2 .

error https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.2.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"

Olá, har-validator-5.1.2 não foi publicado no npm conforme declarado aqui https://github.com/ahmadnassri/node-har-validator/issues/112#issuecomment -437378269, portanto, você precisa atualizar suas dependências via yarn upgrade (provavelmente tem o mesmo efeito que remover yarn.lock recomendado pelos outros).

Suponho que este problema pode ser resolvido.

Remover yarn.lock não funcionou para mim, conforme mencionado no meu relatório de problema inicial. Nem a remoção de .npmrc . Além disso, tanto quanto eu sei, a imagem node:10-alpine docker não tem ou cria um arquivo .npmrc .

Por último, o erro não se limita ao pacote har-validator . Na verdade, nunca o encontrei com esse pacote. Eu o encontrei com os pacotes lodash , fbjs , react e muitos outros.

Resumi minhas tentativas que ainda reproduzem esse problema de maneira confiável em um comentário anterior . Para registro, ao testar com o docker, posso reproduzir o problema incluindo apenas package.json , portanto, nenhum yarn.lock , nenhum .npmrc , nenhum node_modules . Ainda posso reproduzir esse problema em minha máquina local, em uma instância do GCE e com o CI do Gitlab.com. Nem --network-concurrency=1 nem --skip-integrity-check parecem resolver o problema para mim. Portanto, eu hesitaria em recomendar o encerramento deste problema, especialmente porque todos os testes mencionados acima funcionam usando npm install , assumindo que yarn install deve ser uma substituição imediata para npm install dado o mesmo package.json .

O problema é que o registro npm geralmente é instável e retorna erros (em uma taxa mais alta quando várias solicitações estão sendo disparadas aparentemente - talvez algum tipo de limitação por ip?). Por alguma razão, eles não são capturados corretamente pelo Yarn, que tenta cegamente fazer o hash deles e compará-los ao hash esperado - o que falha.

Portanto, há um bug no Yarn (devemos imprimir um erro mais útil), mas dado que o verdadeiro problema é o quão instável o registro do npm é, não é minha prioridade no momento (eu definitivamente revisaria um PR!) .

Por que isso não acontece com o npm: eles repetem suas solicitações até que funcionem. O Yarn tem um mecanismo para fazer isso, mas não na parte que calcula especificamente o hash.

Eu sugiro usar um espelho offline para parar de depender do registro npm para suas instalações.

https://github.com/yarnpkg/yarn/pull/6817 irá "consertar" isso, mostrando o código de status real retornado pelo registro. Eu prefiro que seja estável em vez de tentar novamente às cegas até que funcione, então não adicionei o código de nova tentativa, mas se não houver melhorias no horizonte, talvez tenhamos que fazer isso.

Nesse ínterim, fecharei esta discussão, pois as mensagens de erro serão alteradas e este tópico cresceu bastante (podemos abrir novos para discutir cada código de status individualmente).

Não há ~/.npmrc criado no meu caso. Mas regenerar yarn.lock funcionou para mim.

Simplesmente,

$ rm yarn.lock && yarn

obrigado,
rm -rf ./yarn.lock && yarn
é trabalho para mim!

no caso de ajudar alguém:

  • este mesmo erro ocorreu comigo, quando esqueci de fazer login no npm (doh!)

Para mim, o problema foi resolvido com service docker restart (Ubuntu 18.04).

Tenho experimentado erros intermitentes e não determinísticos como este. Eu reinicio minha construção, nada mais mudou e funciona. Alguém tem alguma alternativa para o fio?

Estou começando a receber o mesmo erro em cada compilação (erros em um módulo npm diferente a cada vez) depois de fazer um PR para atualizar nossa imagem docker base de node:8.12.0 para node:8.13.0 . Inspecionei essas imagens do docker de nó e descobri que a versão pré-instalada do yarn foi alterada de v1.9.4 para v1.12.3 . Veja: commit git associado . Tentei algumas das correções sugeridas neste tópico, sem sorte em resolver o erro. Consegui corrigir o problema simplesmente fazendo o downgrade da versão do yarn no meu Dockerfile para v1.9.4 . Sei que esta versão do fio tem sido problemática para outros, mas para mim a versão mais recente do fio está provocando o problema. Vou observar que estou usando um arquivo .npmrc que fornece credenciais para acessar módulos privados via jfrog artifactory e temos o artifactory configurado para espelhar / proxy todos os módulos npm.

Por que está fechado? Ainda quebrando CI

Nesse ínterim, fecharei esta discussão, pois as mensagens de erro serão alteradas e este tópico cresceu bastante (podemos abrir novos para discutir cada código de status individualmente).

Vou prosseguir e bloquear este tópico, pois me parece que sua utilidade ultrapassou o limite. Como um lembrete:

  • Se você tem essa mensagem de erro, você está muito provavelmente a utilizar uma versão antiga. Atualize para 1.13+ para obter a verdadeira mensagem de erro. Provavelmente, o registro está retornando um HTTP 500 por algum motivo.

  • Se você ainda receber erros que parecem vir do próprio Yarn, abra um novo tópico e explique como reproduzir o problema. Se você não fornecer uma reprodução, não poderemos fornecer uma correção e provavelmente teremos que pedir que você faça uma investigação.

Esta página foi útil?
5 / 5 - 1 avaliações