Yarn: Error al extraer el contenido de alquitrán de indefinido

El mismo problema, también está bloqueando mi CI, actualizamos recientemente a yarn 1.9.2

@opiation El error es de hecho aleatorio, pero es posible que haya encontrado la causa: ¿tiene URL de git distantes en su package.json sin .git al final? Tuvimos dos de esos y agregar .git solucionó el problema. Sin embargo, no estoy seguro de por qué el mensaje de error no indica directamente que este es el problema.

Además, tal vez relacionado: https://github.com/yarnpkg/yarn/issues/5536

@adrienharnay , ¿puedes definir qué quieres decir con _distante_? Para que conste, aquí está el package.json que utilicé . Solo hay una dependencia de github y todavía obtengo errores sin ella. No estoy seguro de cómo agregaría .git a dependencias que no sean de git, a menos que no haya entendido mal tu sugerencia.

Distant no era la palabra correcta, solo me refería a paquetes instalados desde Git 🙂

¿Podrías probar esto?

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

Según mi comentario anterior, todavía encuentro el problema sin la dependencia storybook-addon-markdown . Por lo tanto, no creo que este problema se deba a que el hilo maneja incorrectamente las URL de git.

De hecho, leo demasiado rápido. Bueno, eso solucionó nuestro error, pero no tengo idea sobre el tuyo 😕 Lo siento

@opiation ¿También actualizaste tu archivo yarn.lock? Porque tuve que hacer eso

@Titozzz , encuentro este error con y sin el archivo yarn.lock . He eliminado y recreado el archivo de bloqueo varias veces sin éxito.

También obtengo esto y no tengo ningún paquete de git.

Quería solucionar este problema (https://github.com/yarnpkg/yarn/issues/6256) utilizando las versiones tarball de los paquetes, pero de hecho el error anterior se produce para las URL tarball en la empresa Github autohospedada.

Los archivos tar alojados en github.com de alguna manera funcionaron. p.ej
https://github.com/luwes/chameleon/archive/grasshopper-v0.0.1-beta.4.tar.gz

Veo el mismo problema con un proyecto que tenemos. Sin embargo, cuando elimino los departamentos que ejecutan un script prepare como parte de la instalación (debido a que son URL de git), entonces funciona. Resulta que estas direcciones URL de git apuntan, pero creo que en realidad son las prepare que parecen iniciar más procesos yarn install que parecen subvertir la bandera mutex por alguna razón. Me pregunto si eso se debe a que los otros procesos son iniciados por el proceso raíz en lugar de por diferentes procesos raíz. No sé si esta información ayuda o si en realidad está fuera de lugar. Pero pensé que compartiría lo que encontré independientemente.

@khendry Tengo el problema nuevamente, y tienes razón, ¡proviene de dependencias de git que tienen un script prepare en su package.json! : +1:

He estado rastreando esto con un proyecto que tenemos y hasta ahora lo he reducido a la instalación simultánea que comienza aquí . Si el paquete que está siendo instalado por git-fetcher tiene alguna de las mismas dependencias del paquete que se está instalando actualmente, se crea una condición de carrera en la que los paquetes duplicados se desvincularán al caché sin conexión al mismo tiempo.

No he visto lo suficiente del código base para comprender dónde / cuál es la solución correcta, pero ese es el comienzo del problema.

¿Alguna noticia sobre esto? También nos enfrentamos a este problema.

El mismo problema. Es imposible usar hilo con CI. Cada segunda compilación falló con este error 😞

intente eliminar node_modules,

yarn cache clean
yarn install --network-concurrency 1

Gracias por compartir esto. Es al menos una solución alternativa 🤗, pero no una solución real si desea que su tiempo de compilación sea razonablemente rápido 😅

Intentamos usar la bandera --network-concurrency sin éxito. Así que eso no resuelve realmente este problema en particular. La bandera aborda la simultaneidad a un nivel más alto que donde ocurre el problema.

Para mí --network-concurrency 1 resuelve el problema. Sé que es una solución temporal, pero funciona. Pero el valor debe ser exactamente 1 .

Hablé demasiado pronto. Le pregunté a mi compañero de equipo si habíamos intentado esto, en lugar de intentarlo yo mismo y estaba _mu_ seguro de que lo habíamos hecho ... estaba equivocado y leyó mal la publicación anterior pensando que estaba relacionada con la bandera mutex, no con la red concurrencia. Desde entonces, lo hemos vuelto a intentar y podemos confirmar que esto también parece abordar el problema para nosotros.

establecer --network-concurrency 1 realidad no me funciona.

En este momento, la única solución que he encontrado implica la regeneración completa de yarn.lock . El error que obtengo es:

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)

Actualización: Acabo de descubrir que usar --skip-integrity-check me permite evitar este error. Aunque obviamente esa es realmente una solución. Esto parece una especie de error importante en la lógica de verificación de integridad.

Estoy usando [email protected] , [email protected]

@arcanis @ rally25rs más detalles sobre este error:

Entonces, esto me parece bastante extraño que esté fallando en la suma de verificación de integridad, considerando que los sha1 son los mismos:

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)

Actualización: después de ver arriba, confirmé que --skip-integrity-check evita este error. Parece un error más grave en la lógica de verificación de integridad.

@opiation por curiosidad, ¿puedes pegar tu package.json? ¿Está utilizando la siguiente técnica de "anulación" en algún lugar?

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

Por ejemplo, lo estoy usando:

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

Y, este es el paquete para el que veo el error .. Entonces, me pregunto si esto está relacionado.

@hulkish , según mi publicación inicial, aquí está la esencia que creé con mi package.json , yarn.lock y todas las pruebas que ejecuté que produjeron el error descrito. Para aclarar, cada línea en failing_test.sh puede encontrar este error, pero no de forma constante. Es posible que deban probarse más de una vez para encontrar el error. Solo para tenerlo en este hilo, resumiré cada prueba a continuación:

Pruebas fallidas

• yarn install
• yarn install --frozen-lockfile
• yarn install --pure-lockfile
• yarn install --mutex network
• yarn install --network-concurrency 1
• Todas las pruebas anteriores con rm yarn.lock antemano
• Todas las pruebas anteriores en un contenedor node:alpine con git instalado (alpine en el momento en que se creó este hilo)
• Todas las pruebas anteriores en un contenedor node:8-alpine con git instalado

En cuanto a la técnica de "anulación", no estoy seguro de lo que quiere decir. Si se refiere al prefijo similar a _protocol_ en el valor de dependencia (como npm: en su ejemplo), entonces sí, una dependencia de desarrollo usa un paquete github :

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

Sin embargo, los errores aún se encuentran incluso cuando elimino la dependencia de desarrollo, por lo que esto no parece estar relacionado.

Grita a @holyxiaoxin : agregar --network-concurrency 1 resolvió esto para mi CI 👍

ping @imsnif ? Parece relacionado con la verificación de integridad, según el comentario de @hulkish

@khendry No usar más prepare en nuestras dependencias de git resolvió esto para nuestro ci, mientras que --network-concurrency 1, --child-concurrency 1 y --skip-integration-check no fueron suficientes

Pudimos arreglar esto con npm config set always-auth true (como se documenta aquí ). Lo mejor que puedo decir es que npm de forma predeterminada proporcionará sus credenciales _sólo_ para publicar paquetes, no para recuperarlos. Por alguna razón, el hilo anteriormente no respetaba esa configuración, pero ahora lo hace.

Recientemente tuve este problema, usando yarn 1.12.3 y node 10.13.0 . Después de probar muchas de las soluciones anteriores, sin éxito, la eliminación / regeneración del archivo yarn.lock funcionó.

He tenido un problema similar. Eliminar el yarn.lock como sugirió @mvonballmo fue lo único que lo hizo funcionar. Sin embargo, todavía no funciona del todo.

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.

Hola amigos,

Entonces, a juzgar por los diferentes errores reportados aquí, esto en realidad parece que puede ser potencialmente varios problemas diferentes:
ENOSPC: no space left on device, write ,
wanted sha1-Sl7Hxk364iw6FBJNus3uhG2Ay8Q= but got sha1-AHoWKXweP+Pg9aZkGBsAjFruGaM= (por cierto, echa un vistazo, pero no son lo mismo),
the file appears to be corrupt: "Unexpected end of data" , etc.

Si bien aprecio que esto puede estar sucediendo en un lugar similar, pueden ser causados ​​por problemas y / o entornos completamente diferentes. La verificación de integridad (específicamente el untarStream en la devolución de llamada de error, ¡gracias por la depuración detallada @hulkish!) Es un embudo que puede recopilar muchos errores, y es un poco difícil dar retroalimentación al usuario más allá del error real.

Lo anterior es especialmente cierto para la migración de integridad (rellenando un yarn.lock estilo antiguo con los nuevos campos de integridad), ya que este proceso de una sola vez (una vez asumiendo que se realiza correctamente) es más intensivo en la red que una instalación normal (recorre todos los paquetes sin un campo integrity y recupera su manifiesto de registro).

Las teorías sobre una condición de carrera son interesantes y definitivamente una posibilidad, estaría feliz de investigarlas más a fondo. Sin embargo, me temo que la reproducción de @opiation no funcionó para mí. Ahora estoy ejecutando mi séptima instalación local y todavía funciona sin problemas (no ejecuté el script, sino que simplemente ejecuté yarn para instalarlo con ese package.json y yarn.lock, entiendo esto todavía le causó el problema?)

@opiation : ¿aún puedes reproducir este problema? ¿En las mismas condiciones? ¿Quizás podamos bajar un nivel de resolución y usted puede decirme todo lo que hace hasta los comandos para que esto suceda?

¿Alguien más en este hilo tiene una configuración que pueda compartir que reproduzca este problema incluso parcialmente de manera consistente? Estaría muy feliz de llegar al fondo de esto.

Encontré el mismo mensaje de error en mi sistema 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.

Sin embargo, me las arreglé para resolver mi problema particular. Pensé que dejaría una nota aquí para cualquiera que se encuentre con algo similar:

Porque

Llamé a yarn install en mi máquina local después de agregar una nueva dependencia a mi proyecto ([email protected]). Debido a un .npmrc local, el hilo restauró la dependencia de un registro privado mío. El yarn.lock generado contenía las siguientes líneas:

[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 cómo se resolvió el paquete desde un repositorio privado. En mi máquina de CI, no tenía un .npmrc con las credenciales para el registro privado. Esta fue la causa del mensaje de 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"

Arreglé mi .npmrc local y regeneré mi yarn.lock :

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

Observe cómo el paquete ahora se resuelve desde el registro NPM predeterminado. El error dejó de ocurrir una vez que hice esto.

Reparar

Si la causa de su problema es la misma que la mía, puede:

• Agregue las credenciales requeridas a su máquina CI o
• Modifique su .npmrc local ( yarn config list imprimirá el registro desde el que se restaura el hilo), luego regenere yarn.lock .

Notas

Quizás el mensaje de error podría ser más específico.

Editar: Inicialmente pensé que revertir Yarn resolvería el problema; vinculé accidentalmente mi compromiso defectuoso con este problema. El hilo no fue el problema al final.

TL; DR: intente eliminar su archivo yarn.lock y generarlo nuevamente.

Recibí un error al intentar construir en Netlify: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"

Eliminar la carpeta node_modules y el archivo yarn.lock y luego generarlos nuevamente a través de yarn install me dio un nuevo archivo yarn.lock con diferentes dependencias. Con este nuevo archivo, Netlify construyó con éxito mi proyecto.

@imsnif estuvo de acuerdo en que aparentemente se informan varios problemas diferentes aquí. Creo que tengo un caso de reproducción de un proyecto en el que estoy trabajando que desencadena el problema descrito por @khendry aquí

Veo el mismo problema con un proyecto que tenemos. Sin embargo, cuando elimino los departamentos que ejecutan un script prepare como parte de la instalación (debido a que son URL de git), entonces funciona. Resulta que estas direcciones URL de git apuntan, pero creo que en realidad son las prepare que parecen iniciar más procesos yarn install que parecen subvertir la bandera mutex por alguna razón. Me pregunto si eso se debe a que los otros procesos son iniciados por el proceso raíz en lugar de por diferentes procesos raíz.

Compartir los pasos de reproducción a continuación con la esperanza de que le permita reproducir el problema. Déjeme saber si usted necesita más información.

Pasos de reproducción

1. Con el nodo v10.3.0 y el hilo v1.12.3 , en una nueva carpeta de prueba, descargue package.json y yarn.lock de esta esencia
2. ejecute rm -rf ~/.cache/yarn* node_modules/ && yarn install --frozen-lockfile --network-concurrency 16 (borre el caché e instale previamente los módulos de nodo para un entorno confiable. Establezca la concurrencia alta para aumentar las posibilidades de encontrar un problema)
3. observe la salida como la siguiente:

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.

Otras notas

Probé una variedad de cosas, aquí están mis notas:

1. El problema no se reproduce el 100% del tiempo para mí. Como se señaló anteriormente, el aumento de la concurrencia de la red utilizada parece aumentar la probabilidad de que ocurra el problema.
2. El uso de una versión de react-textarea-autosize publicada en el registro del paquete hace que el problema desaparezca (parece confirmar lo que @khendry informó anteriormente)
3. Establecer --mutex file no parece ayudar en absoluto aquí
4. Como se informó anteriormente, si limito la concurrencia de la red a 1 (a través del argumento --network-concurrency 1 ), todo se instala correctamente, aunque más lento.
5. Reproduje esto en el nodo v8.12.0, tanto con yarn v1.9.4 como con v1.12.3. Esto se estaba ejecutando en la imagen de la ventana acoplable circleci/node:8-stretch ejecuta en Circle CI 2.0.

Comienzo a ver este error recientemente después de actualizar el hilo a 1.12.3 .
Vea mi falla de compilación de 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 .

Está sucediendo solo con [email protected] .
Volveré a publicar si tengo éxito de alguna manera.
PD.
Era específico del paquete har-validator.

Yo tambien 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"
con curl obtuve 404 para https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.2.tgz
pero en mi navegador puedo descargarlo.
Uno de mis servidores, si degrado el hilo a 1.12.1, comienza a funcionar, pero en el otro servidor, incluso si degrado, el error sigue siendo el mismo (elimino el directorio de caché de hilo en ambos casos).
¿Es posible que sea algún tipo de problema de cloudflare (config)?

No, esta instancia específica (la tuya y la de @ ankurk91) se debe a que har-validator no se ha publicado (cf # 6694).

Recibo este error solo en mi entorno de CI, después de haber agregado otro repositorio como dependencia ( "@team/myproject": "git+ssh://[email protected]/team/myproject.git#master", ). puedo confirmar eso

• agregar --network-concurrency 1 a mi script CI resuelve el problema, pero por supuesto hace que la compilación sea muy lenta
• ejecutar yarn install --network-concurrency 16 provoca el error localmente también

Ni limpiar la caché ni restablecer yarn.lock hicieron una diferencia para mí

EDITAR: Parece que la solución --network-concurrency 1 no es consistente, desafortunadamente 😢

mismo error aquí,
fácil de reproducir:
yarn upgrade typescript@^2.8

luego:
yarn upgrade [email protected]

Hice ctrl + c mientras instalaba este último paquete ... y cuando intento 'actualizar hilo' de nuevo obtengo:

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.

ACTUALIZACIÓN: Lo siguiente se debió a metadatos corruptos en nuestra instalación de Sonatype Nexus y, por lo tanto, no es un problema de Yarn. Dejando el contexto.

Viendo esto para múltiples paquetes en nuestro entorno de CI. Hilo 1.12.3 y Nodo 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?"

Tuve un problema similar pero obtengo .... el archivo parece estar dañado: "EBUSY: ...".
Borré todo mi caché de hilo y lo volví a ejecutar y todavía recibí el mismo error, por lo que parece que el hilo está creando archivos y bloqueándolos por sí mismo.

Esto está en 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.

Hice una solución al ejecutar "yarn --pnp" que funcionó. Es extraño, ya que debería ser un código más nuevo y probablemente más inestable.

Eliminar yarn.lock fue lo que hizo que me funcionara.

Hola a todos, simplemente tuve el mismo problema. Se resuelve eliminando .npmrc del directorio de inicio.

rm ~/.npmrc

@binchik : esto es lo único que funcionó para mí.

Gracias @binchik , eso funcionó para mí. 👍

Entonces, después de retroceder a la serie de eventos que condujeron a la falla de yarn , creo que ejecuté un script npm en un package.json que era algo como esto:

"audit": "npm audit"

Lo cual es totalmente tonto, porque nunca uso npm en ese proyecto. Después de este comando, todo (incluido npm) comenzaría a tener fallas aleatorias y nunca se completaría, en línea con la experiencia de otros en este hilo.

Si alguien que reproduce el error pudiera investigar y averiguar exactamente qué está causando el problema, ¡sería muy útil! Lo intenté pero no puedo reproducirlo 🙁

Algunos consejos:

• Necesitamos averiguar qué entra en untarStream cuando falla; mi hipótesis es que tal vez estamos tratando de procesar una respuesta json como un tarball (https://github.com/yarnpkg/yarn/blob/master /src/fetchers/tarball-fetcher.js#L146-L150)

• lo único que creo que podría importar en el .npmrc es el token de autenticación. Agradecería que alguien pudiera confirmar que el problema desaparece simplemente eliminando la línea del token de autenticación de .npmrc (en lugar de todo el archivo)

FWIW, encontré este problema hoy. Unas pocas cosas:

• La eliminación de .npmrc solucionó. Lo único en el archivo tenía que ver con el token de autenticación.
• npm install también falló y registró un error 401 no autorizado.
• Después de eliminar el archivo .npmrc , npm install funcionó de nuevo.

@deleteme según mis hallazgos, esto suena más como un subproducto del error, en lugar de la causa.

Me he encontrado con y sin .npmrc o .yarnrc

Dado que este problema de repente aparece mucho más de lo habitual y que es durante el registro npm que es especialmente inestable , es muy probable que mi hipótesis no esté muy lejos

@arcanis acaba de empezar a tener este problema hoy. Puedo confirmar que al eliminar esa línea de token de autenticación npmrc, el problema se resolvió.

No hay ~/.npmrc creado en mi caso. Pero regenerar yarn.lock funcionó para mí.

Simplemente,

$ rm yarn.lock && yarn

EDITAR: Enfrenté este problema dos veces solo para terminar aterrizando aquí. :sonreír:

En mi caso, uso CircleCI, circleci/node:10.11.0 docker image y [email protected] , y no hay ~/.npmrc . Gracias @achillesrasquinha. Esto funciona para mi.

Me he enfrentado a este problema durante una semana. yarn install --network-concurrency 1 problema resuelto pero es muy, muy lento.

Por cierto, esta información podría ser útil para cualquiera.
Estaba usando un paquete npm personalizado (en casa) en mi proyecto. Siempre tengo el mismo problema como .cache/v4 pero mostrando diferentes nombres de paquetes en cada falla. Después de pasar mucho tiempo, encuentro una observación al azar.
Mi proyecto y el paquete npm personalizado están usando el mismo yarn build para construir el paquete. He actualizado el nombre del script de compilación de mi paquete personalizado a otro nombre como yarn build:p . Entonces empieza a funcionar. Corrí a construir muchas veces. No falló. No estoy seguro de cómo estos 2 son dependientes, pero funcionó para mí.

Eliminar .npmrc solo no lo hizo por mí. También tuve que eliminar mi archivo yarn.lock como mencionó @davidalee . No sé por qué está rechazando eso 🤷‍♂️

No estoy seguro de si eliminar .npmrc tuvo algún efecto para mí.

No soy realmente fanático de eliminar el archivo yarn.lock , así que lo que hice fue eliminar el paquete har-validator del yarn.lock y luego volver a ejecutar yarn que solucionó el problema para mí.

Sí rm yarn.lock trabaja para mí. Enfrentando un problema con el paquete 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"

Hola, har-validator-5.1.2 no se publicó de npm como se indica aquí https://github.com/ahmadnassri/node-har-validator/issues/112#issuecomment -437378269, por lo que debe actualizar sus dependencias a través de yarn upgrade (esto probablemente tenga el mismo efecto que eliminar yarn.lock recomendado por los demás).

Supongo que este problema se puede cerrar.

Eliminar yarn.lock no funcionó para mí, como se menciona en mi informe de problemas inicial. Tampoco la eliminación de .npmrc . Además, hasta donde yo sé, la imagen de la ventana acoplable node:10-alpine no tiene ni crea un archivo .npmrc .

Por último, el error no se limita al paquete har-validator . De hecho, nunca lo he encontrado con ese paquete. Lo encontré con los paquetes lodash , fbjs , react , y muchos otros.

Resumí mis intentos que aún reproducen de manera confiable este problema en un comentario anterior . Para que conste, al probar con la ventana acoplable, puedo reproducir el problema incluyendo solo package.json , por lo tanto, no yarn.lock , no .npmrc , no node_modules . Todavía puedo reproducir este problema en mi máquina local, en una instancia de GCE y con CI de Gitlab.com. Ni --network-concurrency=1 ni --skip-integrity-check parecen resolver el problema por mí. Por lo tanto, dudaría en recomendar cerrar este problema, especialmente porque todas las pruebas mencionadas anteriormente funcionan usando npm install , asumiendo que yarn install debería ser un reemplazo directo de npm install dado el mismo package.json .

El problema es que el registro npm es generalmente inestable y devuelve errores (a un ritmo más alto cuando se disparan varias solicitudes aparentemente, ¿tal vez algún tipo de limitación por IP?). Por alguna razón, Yarn no los captura correctamente, que ciegamente intenta hacer un hash y compararlos con el hash esperado, lo que falla.

Entonces hay un error en Yarn (deberíamos imprimir un error más útil), pero dado que el problema real es cuán inestable es el registro npm, no es mi prioridad en este momento (¡definitivamente revisaría un PR, sin embargo!) .

En cuanto a por qué no sucede con npm: vuelven a intentar sus solicitudes hasta que funcionan. Yarn tiene un mecanismo para hacer eso, pero no en la parte que calcula específicamente el hash.

Sugeriría usar un espejo fuera de línea para dejar de confiar en el registro npm para sus instalaciones.

https://github.com/yarnpkg/yarn/pull/6817 "arreglará" eso mostrando el código de estado real devuelto por el registro. Preferiría que sea estable en lugar de reintentar a ciegas hasta que funcione, así que no agregué el código de reintento, pero si no hay mejoras en el horizonte, es posible que tengamos que hacerlo.

Mientras tanto, cerraré esta discusión, ya que los mensajes de error cambiarán y este hilo crecerá bastante (podemos abrir otros nuevos para discutir cada código de estado individualmente).

No hay ~/.npmrc creado en mi caso. Pero regenerar yarn.lock funcionó para mí.

Simplemente,

$ rm yarn.lock && yarn

gracias,
rm -rf ./yarn.lock && yarn
es trabajo para mi!

en caso de que ayude a alguien:

• este mismo error ocurrió para mí, cuando olvidé iniciar sesión en npm (¡doh!)

Para mí, el problema se resolvió con service docker restart (Ubuntu 18.04).

He estado experimentando errores intermitentes y no deterministas como este. Reinicio mi compilación, nada más ha cambiado y funciona. ¿Alguien tiene alguna alternativa al hilo?

Empiezo a recibir este mismo error en cada compilación (errores en un módulo npm diferente cada vez) después de hacer un PR para actualizar nuestra imagen base de la ventana acoplable de node:8.12.0 a node:8.13.0 . Inspeccioné estas imágenes de la ventana acoplable de nodos y descubrí que la versión de hilo preinstalada se cambió de v1.9.4 a v1.12.3 . Ver: git commit asociado . Probé algunas de las correcciones sugeridas en este hilo sin suerte para resolver el error. Pude solucionar el problema simplemente degradando la versión de hilo en mi Dockerfile a v1.9.4 . Sé que esta versión de hilo ha sido problemática para otros, pero para mí la versión más reciente de hilo está provocando el problema. Notaré que estoy usando un archivo .npmrc que proporciona credenciales para acceder a módulos privados a través del artefactor jfrog y tenemos el artefactorio configurado para reflejar / proxy todos los módulos npm.

¿Por qué esta cerrado? Todavía rompiendo CI

Mientras tanto, cerraré esta discusión, ya que los mensajes de error cambiarán y este hilo crecerá bastante (podemos abrir otros nuevos para discutir cada código de estado individualmente).

Seguiré adelante y bloquearé este hilo, ya que me parece que ha superado su utilidad. Como recordatorio:

• Si tiene este mensaje de error, es muy probable que esté utilizando una versión anterior. Actualice a 1.13+ para obtener el verdadero mensaje de error. Es probable que el registro devuelva un HTTP 500 por alguna razón.

• Si aún recibe errores que parecen provenir del propio Yarn, abra un nuevo hilo y detalle cómo reproducir el problema. Si no proporciona una reproducción, no podremos proporcionar una solución y es probable que tengamos que pedirle que investigue usted mismo.