Yarn: Échec de l'extraction du contenu tar d'undefined

Même problème, ça bloque aussi mon CI, nous avons récemment mis à jour vers le fil 1.9.2

@opiation L'erreur est en effet aléatoire mais j'ai peut-être trouvé la cause: avez-vous des URL git distantes dans votre package.json sans .git à la fin? Nous en avons eu deux et l'ajout de .git résolu le problème. Vous ne savez pas pourquoi le message d'erreur n'indique pas directement que c'est le problème.

Aussi, peut-être lié: https://github.com/yarnpkg/yarn/issues/5536

@adrienharnay , pouvez-vous définir ce que vous entendez par _distant_? Pour mémoire, voici le package.json j'ai utilisé . Il n'y a qu'une seule dépendance github et j'obtiens toujours des erreurs sans elle. Je ne sais pas comment ajouter .git aux dépendances non git, sauf si j'ai mal compris votre suggestion.

Distant n'était pas le bon mot, je voulais juste dire les paquets installés depuis Git 🙂

Pouvez-vous essayer ça?

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

Selon mon commentaire précédent, je rencontre toujours le problème sans dépendance storybook-addon-markdown . Par conséquent, je ne pense pas que ce problème découle du fait que le fil ne gère pas correctement les URL git.

En effet, j'ai lu trop vite. Eh bien, cela a corrigé notre bug, mais je n'ai aucune idée du vôtre 😕 Désolé

@opiation Avez-vous également mis à jour votre fichier yarn.lock? Parce que je devais faire ça

@Titozzz , je rencontre cette erreur avec et sans le fichier yarn.lock . J'ai supprimé et recréé le fichier de verrouillage plusieurs fois en vain.

Je comprends cela aussi et je n'ai aucun paquet de git.

Je voulais contourner ce problème (https://github.com/yarnpkg/yarn/issues/6256) en utilisant les versions tarball des packages, mais en effet l'erreur ci-dessus est générée pour les URL de tarball sur une entreprise Github auto-hébergée.

Les archives tar hébergées sur github.com ont en quelque sorte fonctionné. par exemple
https://github.com/luwes/chameleon/archive/grasshopper-v0.0.1-beta.4.tar.gz

Je vois le même problème avec un projet que nous avons. Cependant, lorsque je supprime les deps qui exécutent un script prepare dans le cadre de l'installation (en raison du fait qu'il s'agit d'URL git), cela fonctionne. Celles-ci pointent vers des URL git, mais je pense que ce sont en fait les prepare qui semblent lancer plus yarn install processus

@khendry J'ai encore eu le problème, et vous avez raison, il vient de dépendances git qui ont un script prepare dans leur package.json! : +1:

J'ai suivi cela avec un projet que nous avons et jusqu'à présent je l'ai réduit à l'installation simultanée que git-fetcher commence ici . Si le package en cours d'installation par git-fetcher a l'une des mêmes dépendances du package en cours d'installation, une condition de concurrence est créée dans laquelle les packages dupliqués ne seront pas enregistrés dans le cache hors ligne en même temps.

Je n'ai pas suffisamment vu la base de code pour comprendre où / quel est le correctif correct, mais c'est le début du problème.

des nouvelles à ce sujet? Nous sommes également confrontés à ce problème.

Même problème. Il est impossible d'utiliser du fil avec CI. Chaque 2ème build a échoué avec cette erreur 😞

essayez de supprimer node_modules,

yarn cache clean
yarn install --network-concurrency 1

Merci d'avoir partagé ça. C'est au moins une solution de contournement 🤗, mais pas de vraie solution si vous voulez que votre temps de construction soit raisonnable et rapide 😅

Nous avons essayé d'utiliser l'indicateur --network-concurrency sans succès. Cela ne résout donc pas vraiment ce problème particulier. L'indicateur traite la concurrence à un niveau supérieur à celui où le problème se produit.

Pour moi, --network-concurrency 1 résout le problème. Je sais que c'est une solution temporaire, mais cela fonctionne. Mais la valeur doit être exactement 1 .

J'ai parlé trop tôt. J'avais demandé à mon coéquipier si nous avions essayé cela, plutôt que d'essayer moi-même et il était _très_ convaincu que nous l'avions fait ... il s'était trompé et avait mal lu le message précédent en pensant qu'il était lié au drapeau mutex, pas au réseau concurrence. Depuis, nous avons réessayé et pouvons confirmer que cela semble également résoudre le problème pour nous.

définir --network-concurrency 1 ne fonctionne pas vraiment pour moi.

à l'heure actuelle, la seule solution de contournement que j'ai rencontrée consiste à régénérer complètement yarn.lock . L'erreur que j'obtiens est:

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)

Mise à jour: je viens de découvrir que l'utilisation de --skip-integrity-check me permet de contourner cette erreur. Bien évidemment, c'est vraiment une solution. Cela ressemble à une sorte de bogue important dans la logique de vérification d'intégrité.

J'utilise [email protected] , [email protected]

@arcanis @ rally25rs plus de détails sur cette erreur:

Donc, cela me semble assez étrange que la somme de contrôle d'intégrité échoue, étant donné que les sha1 sont les mêmes:

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)

Mise à jour: après avoir vu ci-dessus, j'ai confirmé que --skip-integrity-check contourne cette erreur. On dirait un bogue plus sérieux dans la logique de vérification d'intégrité.

@opiation par curiosité, pouvez-vous coller votre package.json? Utilisez-vous la technique de «remplacement» suivante n'importe où?

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

Par exemple, je l'utilise:

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

Et, c'est le package pour lequel je vois l'erreur .. Donc, je me demande si cela est lié?

@hulkish , selon mon message initial, voici l'essentiel que j'ai créé avec mes package.json , yarn.lock et tous les tests que j'ai exécutés qui ont tous produit l'erreur décrite. Pour clarifier, chaque ligne de failing_test.sh peut rencontrer cette erreur mais pas systématiquement. Ils devront peut-être être essayés plus d'une fois pour rencontrer l'erreur. Juste pour l'avoir dans ce fil, je résumerai chaque test ci-dessous:

Échec des tests

• yarn install
• yarn install --frozen-lockfile
• yarn install --pure-lockfile
• yarn install --mutex network
• yarn install --network-concurrency 1
• Tous les tests ci-dessus avec rm yarn.lock au préalable
• Tous les tests ci-dessus dans un conteneur node:alpine avec git installé (alpin au moment de la création de ce fil)
• Tous les tests ci-dessus dans un conteneur node:8-alpine avec git installé

Quant à la technique du «remplacement», je ne sais pas ce que vous voulez dire. Si vous faites référence au préfixe de type _protocol_ dans la valeur de la dépendance (comme npm: dans votre exemple), alors oui, une dépendance de développement utilise un package github :

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

Les erreurs sont toujours rencontrées cependant même lorsque je supprime la dépendance dev, donc cela ne semble pas lié.

Criez à @holyxiaoxin - l'ajout de --network-concurrency 1 résolu ce problème pour mon CI 👍

ping @imsnif ? Cela semble lié au contrôle d'intégrité, selon le commentaire de @hulkish

@khendry Le fait de ne plus utiliser prepare sur nos dépendances git a résolu ce problème pour notre ci, alors que --network-concurrency 1, --child-concurrency 1 et --skip-integrity-check n'étaient pas suffisants

Nous avons pu résoudre ce problème avec npm config set always-auth true (comme documenté ici ). Pour autant que je sache, npm par défaut fournira vos informations d'identification _uniquement_ pour la publication de packages, pas pour les récupérer. Pour une raison quelconque, le fil ne respectait pas ce réglage auparavant, mais c'est maintenant le cas.

J'ai récemment eu ce problème, en utilisant yarn 1.12.3 et node 10.13.0 . Après avoir essayé plusieurs des solutions ci-dessus, en vain, la suppression / régénération du fichier yarn.lock fonctionné.

J'ai eu un problème similaire. Supprimer le yarn.lock comme @mvonballmo suggéré était la seule chose qui l'a fait fonctionner. Cela ne fonctionne toujours pas complètement cependant.

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.

Salut les amis,

Donc, à en juger par les différentes erreurs signalées ici, cela semble en fait qu'il peut s'agir de plusieurs problèmes différents:
ENOSPC: no space left on device, write ,
wanted sha1-Sl7Hxk364iw6FBJNus3uhG2Ay8Q= but got sha1-AHoWKXweP+Pg9aZkGBsAjFruGaM= (btw, regarde attentivement, mais ce ne sont pas les mêmes),
the file appears to be corrupt: "Unexpected end of data" , etc.

Bien que j'apprécie que cela puisse se produire dans un endroit similaire, ils peuvent être causés par des problèmes et / ou des environnements totalement différents. Le contrôle d'intégrité (en particulier le untarStream sur le rappel d'erreur - merci pour le débogage détaillé @hulkish!) Est un entonnoir qui peut recueillir de nombreuses erreurs, et il est un peu difficile de donner des commentaires au-delà de l'erreur réelle à l'utilisateur.

Ce qui précède est particulièrement vrai pour la migration d'intégrité (remplissant un yarn.lock à l'ancienne avec les nouveaux champs d'intégrité), car ce processus unique (une fois en supposant qu'il réussit ofc) est plus intensif en réseau qu'une installation normale (il parcourt tous les packages sans champ integrity et récupère leur manifeste de registre).

Les théories sur une condition de course sont intéressantes et très certainement une possibilité, je serais heureux de les approfondir. J'ai bien peur que la reproduction de @opiation n'ait pas fonctionné pour moi. J'exécute maintenant ma 7ème installation locale de celui-ci et cela fonctionne toujours sans problème (je n'ai pas exécuté le script, j'ai plutôt exécuté yarn pour l'installer avec ce package.json et yarn.lock - je comprends cela a toujours causé le problème pour vous?)

@opiation - pouvez-vous toujours reproduire ce problème? Dans les mêmes conditions? Peut-être que nous pouvons descendre un niveau de résolution et vous pouvez me dire tout ce que vous faites jusqu'aux commandes pour que cela se produise?

Quelqu'un d'autre sur ce fil a une configuration qu'il peut partager qui reproduit ce problème même partiellement de manière cohérente? Je serais très heureux d'aller au fond des choses.

J'ai rencontré le même message d'erreur dans mon système 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.

J'ai réussi à comprendre mon problème particulier. Je pensais que je laisserais une note ici pour quiconque rencontre quelque chose de similaire:

Cause

J'ai appelé yarn install sur ma machine locale après avoir ajouté une nouvelle dépendance à mon projet ([email protected]). En raison d'un .npmrc local, yarn a restauré la dépendance à partir d'un de mes registres privés. Le yarn.lock généré contenait les lignes suivantes:

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

Notez comment le package a été résolu à partir d'un référentiel privé. Sur ma machine CI, je n'avais pas de .npmrc avec les informations d'identification pour le registre privé. C'était la cause du message d'erreur:

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"

J'ai corrigé mon .npmrc local et régénéré mon yarn.lock :

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

Notez comment le package est désormais résolu à partir du registre NPM par défaut. L'erreur a cessé de se produire une fois que j'ai fait cela.

Réparer

Si la cause de votre problème est la même que la mienne, vous pouvez:

• Ajoutez les informations d'identification requises à votre machine CI ou
• Ajustez votre .npmrc ( yarn config list imprimera le registre à partir duquel le fil restaure), puis régénérez yarn.lock .

Remarques

Peut-être que le message d'erreur pourrait être plus précis.

Edit: Au départ, je pensais que revenir en arrière Yarn résoudrait le problème - lié accidentellement mon engagement défectueux à ce problème. Le fil n'était pas le problème à la fin.

TL; DR: essayez de supprimer votre fichier yarn.lock et de le générer à nouveau.

J'ai eu une erreur en essayant de construire sur Netlify: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"

Supprimer le dossier node_modules et le fichier yarn.lock, puis les générer à nouveau via yarn install m'a donné un nouveau fichier yarn.lock avec différentes dépendances. Avec ce nouveau fichier, Netlify a construit avec succès mon projet.

@imsnif a convenu qu'il y avait apparemment plusieurs problèmes différents signalés ici. Je crois que j'ai un cas de repro d'un projet sur lequel je travaille qui déclenche le problème décrit par @khendry ici

Je vois le même problème avec un projet que nous avons. Cependant, lorsque je supprime les deps qui exécutent un script prepare dans le cadre de l'installation (en raison du fait qu'il s'agit d'URL git), cela fonctionne. Celles-ci pointent vers des URL git, mais je pense que ce sont en fait les prepare qui semblent lancer plus yarn install processus

Partager les étapes de repro ci-dessous dans l'espoir que cela vous permette de reproduire le problème. Faites-moi savoir si vous avez besoin de plus d'informations.

Repro étapes

1. Avec node v10.3.0 et yarn v1.12.3 , dans un nouveau dossier de test, téléchargez les package.json et yarn.lock partir de cet élément
2. run rm -rf ~/.cache/yarn* node_modules/ && yarn install --frozen-lockfile --network-concurrency 16 (vider le cache et installer auparavant les modules de nœuds pour un environnement fiable. Réglez la concurrence élevée pour augmenter les chances de problème)
3. observez la sortie comme suit:

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.

Autres notes

J'ai essayé une variété de choses, voici mes notes:

1. Le problème ne se reproduit pas à 100% pour moi. Comme indiqué ci-dessus, l'augmentation de la concurrence réseau utilisée semble rendre le problème plus susceptible de se produire.
2. L'utilisation d'une version de react-textarea-autosize publiée sur le registre des packages permet de résoudre le problème (semble confirmer ce que @khendry a rapporté ci-dessus)
3. Définir --mutex file ne semble pas du tout aider ici
4. Comme indiqué ci-dessus, si je limite la concurrence réseau à 1 (via l'argument --network-concurrency 1 ), tout s'installe correctement, bien que plus lentement.
5. J'ai reproduit ceci sur le nœud v8.12.0, avec les fils v1.9.4 et v1.12.3. Cela fonctionnait sur l'image docker circleci/node:8-stretch fonctionnant sur Circle CI 2.0.

Je commence à voir cette erreur récemment après avoir mis à jour le fil vers 1.12.3 .
Voir mon échec de compilation 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 .

Cela se produit uniquement avec [email protected] .
Je posterai si j'ai réussi d'une manière ou d'une autre.
PS.
C'était spécifique au package har-validator.

Je reçois aussi
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"
avec curl j'ai obtenu 404 pour https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.2.tgz
mais dans mon navigateur, je peux le télécharger.
Un de mes serveurs si je rétrograde le fil à 1.12.1, il commence à fonctionner mais sur l'autre serveur, même si je rétrograde, l'erreur reste la même (je supprime le répertoire de cache de fil dans les deux cas).
Est-ce possible qu'il s'agisse d'une sorte de problème de cloudflare (config)?

Non, cette instance spécifique (la vôtre et celle de @ ankurk91) est due au fait que har-validator n'a pas été publié (cf # 6694).

J'obtiens cette erreur dans mon environnement CI uniquement, après avoir ajouté un autre dépôt en tant que dépendance ( "@team/myproject": "git+ssh://[email protected]/team/myproject.git#master", ). Je peux confirmer que

• ajouter --network-concurrency 1 à mon script CI résout le problème, mais rend bien sûr la construction très lente
• l'exécution de yarn install --network-concurrency 16 provoque également l'erreur localement

Ni le nettoyage du cache ni la réinitialisation de yarn.lock n'ont fait de différence pour moi

EDIT: Il semble que le correctif --network-concurrency 1 n'est pas cohérent, malheureusement 😢

même erreur ici,
facile à reproduire:
yarn upgrade typescript@^2.8

puis:
yarn upgrade [email protected]

J'ai fait ctrl + c lors de l'installation de ce dernier paquet .. et quand j'essaye à nouveau de 'yarn upgrade' j'obtiens:

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.

MISE À JOUR: Ce qui suit était dû à des métadonnées corrompues dans notre installation de Sonatype Nexus, et n'est donc pas un problème de Yarn. Partir pour le contexte.

Voyant cela pour plusieurs packages dans notre environnement CI. Yarn 1.12.3 et Node 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?"

J'ai eu un problème similaire mais j'obtiens .... le fichier semble corrompu: "EBUSY: ...".
J'ai effacé tout mon cache de fil et l'ai relancé et j'ai toujours eu la même erreur, il semble donc que le fil crée des fichiers et les verrouille pour lui-même.

C'est sur 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.

J'ai fait une solution de contournement en exécutant "yarn --pnp" qui a fonctionné. Etrange car cela devrait être du code plus récent et probablement plus instable.

La suppression de yarn.lock été ce qui a fait que cela fonctionne pour moi.

Salut tout le monde, j'ai juste eu le même problème. Résolu en supprimant .npmrc du répertoire personnel.

rm ~/.npmrc

@binchik - c'est la seule chose qui a fonctionné pour moi.

Merci @binchik , cela a fait l'affaire pour moi. 👍

Donc, après être revenu à la série d'événements menant à l'échec de yarn , je crois que j'ai exécuté un script npm dans un package.json qui ressemblait à ceci:

"audit": "npm audit"

Ce qui est totalement idiot, car je n'utilise jamais npm dans ce projet. Après cette commande, tout (y compris npm) commencerait juste à avoir des fautes aléatoires et ne se terminerait jamais, conformément à l'expérience des autres dans ce fil.

Si quelqu'un reproduisant l'erreur pouvait enquêter et déterminer la cause exacte du problème, ce serait très utile! J'ai essayé mais je ne peux pas le reproduire 🙁

Quelques conseils:

• Nous devons comprendre ce qui entre dans untarStream quand il échoue - mon hypothèse est que nous essayons peut-être de traiter une réponse json comme une archive tar (https://github.com/yarnpkg/yarn/blob/master /src/fetchers/tarball-fetcher.js#L146-L150)

• la seule chose que je pense qui pourrait avoir de l'importance dans le .npmrc est le jeton d'authentification. J'apprécierais que quelqu'un puisse confirmer que le problème disparaît simplement en supprimant la ligne de jeton d'authentification du .npmrc (plutôt que du fichier entier)

FWIW, j'ai rencontré ce problème aujourd'hui. Quelques choses:

• La suppression de .npmrc corrigé. La seule chose dans le fichier avait à voir avec le jeton d'authentification.
• npm install également échoué et a enregistré une erreur 401 non autorisée.
• Après avoir supprimé le fichier .npmrc , npm install a de nouveau fonctionné.

@deleteme d'après mes conclusions, cela ressemble plus à un sous-produit du bogue qu'à sa cause.

J'ai rencontré avec et sans .npmrc ou .yarnrc

Étant donné que ce problème apparaît soudainement beaucoup plus que d'habitude et que c'est pendant que le registre npm est particulièrement floconneux , il est fort probable que mon hypothèse ne soit pas loin

@arcanis vient de commencer à avoir ce problème aujourd'hui. Je peux confirmer qu'en supprimant cette ligne de jeton d'authentification npmrc, le problème a été résolu.

Il n'y a pas de ~/.npmrc créé dans mon cas. Mais régénérer yarn.lock fonctionné pour moi.

Simplement,

$ rm yarn.lock && yarn

EDIT: J'ai fait face à ce problème deux fois pour finir par atterrir ici. :sourire:

Dans mon cas, j'utilise CircleCI, circleci/node:10.11.0 image docker et [email protected] , et il n'y a pas de ~/.npmrc . Merci @achillesrasquinha. Ça marche pour moi.

Je suis confronté à ce problème depuis une semaine. yarn install --network-concurrency 1 résolu le problème mais il est très très lent.

En btw, cette information pourrait être utile à n'importe qui.
J'utilisais un package npm personnalisé (en interne) dans mon projet. J'obtiens toujours le même problème comme .cache/v4 mais affichant des noms de paquet différents à chaque échec. Après avoir passé beaucoup de temps, je trouve une observation aléatoire.
Mon projet et mon package npm personnalisé utilisent le même yarn build pour créer le bundle. J'ai mis à jour le nom du script de construction de mon package personnalisé vers un autre nom sous la forme yarn build:p . Ensuite, il commence à fonctionner. J'ai couru build plusieurs fois. Cela n'a pas échoué. Je ne sais pas comment ces 2 sont dépendants mais ont fonctionné pour moi.

La suppression de .npmrc ne l'a pas fait pour moi. J'ai également dû supprimer mon fichier yarn.lock comme @davidalee mentionné. Je ne sais pas pourquoi il baisse les pouces pour ça 🤷‍♂️

Je ne sais pas si la suppression de .npmrc eu un effet sur moi.

Je ne suis pas vraiment fan de la suppression du fichier yarn.lock , donc ce que j'ai fait, c'est simplement supprimer le package har-validator du yarn.lock , puis réexécuter yarn qui a résolu le problème pour moi.

Oui rm yarn.lock travaille pour moi. Problème avec le package 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"

Salut, har-validator-5.1.2 n'a pas été publié de npm comme indiqué ici https://github.com/ahmadnassri/node-har-validator/issues/112#issuecomment -437378269, vous devez donc mettre à niveau vos dépendances via yarn upgrade (cela a probablement le même effet que la suppression de yarn.lock qui a été recommandée par les autres).

Je suppose que ce problème peut être résolu.

La suppression de yarn.lock n'a pas fonctionné pour moi, comme indiqué dans mon rapport de problème initial. La suppression de .npmrc n'a pas non plus été effectuée. En outre, pour autant que je sache, l'image docker node:10-alpine n'a pas ou ne crée pas .npmrc fichier

Enfin, l'erreur ne se limite pas au package har-validator . En fait, je ne l'ai jamais rencontré avec ce package. Je l'ai rencontré avec les packages lodash , fbjs , react , et une foule d'autres.

J'ai résumé mes tentatives qui reproduisent toujours de manière fiable ce problème dans un commentaire précédent . Pour mémoire, lors du test avec docker, je peux reproduire le problème en incluant uniquement le package.json donc, non yarn.lock , non .npmrc , non node_modules . Je peux toujours reproduire ce problème sur ma machine locale, sur une instance GCE et avec le CI de Gitlab.com. Ni --network-concurrency=1 ni --skip-integrity-check semblent résoudre le problème pour moi. Ainsi, j'hésiterais à recommander de fermer ce problème, d'autant plus que tous les tests mentionnés ci-dessus fonctionnent avec npm install , en supposant que yarn install devrait être un remplacement instantané de npm install étant donné le même package.json .

Le problème est que le registre npm est généralement instable et renvoie des erreurs (à un taux plus élevé lorsque plusieurs requêtes se déclenchent apparemment - peut-être une sorte de limitation par ip?). Pour une raison quelconque, ils ne sont pas correctement capturés par Yarn, qui essaie aveuglément de les hacher et de les comparer au hachage attendu - ce qui échoue.

Il y a donc un bug dans Yarn (nous devrions imprimer une erreur plus utile), mais étant donné que le vrai problème est à quel point le registre npm est floconneux, ce n'est pas ma priorité pour le moment (je passerais certainement en revue un PR, cependant!) .

Quant à savoir pourquoi cela ne se produit pas avec npm: ils réessayent leurs demandes jusqu'à ce qu'ils fonctionnent. Yarn a un mécanisme pour faire cela, mais pas sur la partie qui calcule spécifiquement le hachage.

Je suggère d'utiliser un miroir hors ligne pour cesser de compter sur le registre npm pour vos installations.

https://github.com/yarnpkg/yarn/pull/6817 "corrigera" cela en affichant le code d'état réel renvoyé par le registre. Je préférerais qu'il soit stable plutôt que de réessayer aveuglément jusqu'à ce que cela fonctionne, donc je n'ai pas ajouté le code de nouvelle tentative, mais s'il n'y a pas d'améliorations à l'horizon, nous devrons peut-être le faire.

En attendant, je fermerai cette discussion, car les messages d'erreur vont changer et ce fil est devenu assez volumineux (nous pouvons en ouvrir de nouveaux pour discuter de chaque code d'état individuellement).

Il n'y a pas de ~/.npmrc créé dans mon cas. Mais régénérer yarn.lock fonctionné pour moi.

Simplement,

$ rm yarn.lock && yarn

Je vous remercie,
rm -rf ./yarn.lock && yarn
ça marche pour moi!

au cas où cela aiderait quelqu'un:

• cette même erreur s'est produite pour moi, quand j'avais oublié de me connecter à npm (doh!)

Pour moi, le problème a été résolu avec service docker restart (Ubuntu 18.04).

J'ai connu des erreurs intermittentes et non déterministes comme celle-ci. Je redémarre ma compilation, rien d'autre n'a changé et ça marche. Quelqu'un at-il des alternatives au fil?

Je commence à avoir cette même erreur sur chaque build (erreurs sur un module npm différent à chaque fois) après avoir fait un PR pour mettre à jour notre image docker de base de node:8.12.0 à node:8.13.0 . J'ai inspecté ces images de docker de nœuds et j'ai découvert que la version de fil préinstallée était passée de v1.9.4 à v1.12.3 . Voir: git commit associé . J'ai essayé certaines des corrections suggérées dans ce fil sans avoir de chance de résoudre l'erreur. J'ai pu résoudre le problème en rétrogradant simplement v1.9.4 . Je sais que cette version de fil a posé problème pour d'autres, mais pour moi, la version de fil la plus récente est à l'origine du problème. Je noterai que j'utilise un fichier .npmrc qui fournit des informations d'identification pour accéder aux modules privés via l'artéfactif jfrog et que nous avons configuré un artificiel pour mettre en miroir / proxy tous les modules npm.

Pourquoi est-ce fermé? Toujours en rupture de CI

En attendant, je fermerai cette discussion, car les messages d'erreur vont changer et ce fil est devenu assez volumineux (nous pouvons en ouvrir de nouveaux pour discuter de chaque code d'état individuellement).

Je vais aller de l'avant et verrouiller ce fil puisqu'il me semble qu'il a dépassé son utilité. Pour rappel:

• Si vous avez ce message d'erreur, vous utilisez très probablement une ancienne version. Passez à la version 1.13+ pour obtenir le vrai message d'erreur. Il est probable que le registre renvoie un HTTP 500 pour une raison quelconque.

• Si vous obtenez toujours des erreurs qui semblent provenir de Yarn lui-même, ouvrez un nouveau fil et détaillez comment reproduire le problème. Si vous ne fournissez pas de reproduction, nous ne serons pas en mesure de fournir un correctif et nous devrons probablement vous demander de vous enquêter.