Yarn: Das Extrahieren des Teergehalts von undefined ist fehlgeschlagen

Das gleiche Problem, es blockiert auch mein CI. Wir haben kürzlich auf Garn 1.9.2 aktualisiert

@opiation Der Fehler ist in der Tat zufällig, aber ich habe möglicherweise die Ursache gefunden: Haben Sie entfernte Git-URLs in Ihrer package.json ohne .git am Ende? Wir hatten zwei davon und das Hinzufügen von .git das Problem behoben. Ich bin mir nicht sicher, warum die Fehlermeldung nicht direkt angibt, dass dies das Problem ist.

Vielleicht auch verwandt: https://github.com/yarnpkg/yarn/issues/5536

@adrienharnay , kannst du definieren, was du mit _distant_ meinst? Für die Aufzeichnung ist hier das package.json ich verwendet habe . Es gibt nur eine Github-Abhängigkeit und ich bekomme immer noch Fehler ohne sie. Ich bin mir nicht sicher, wie ich .git an Nicht-Git-Abhängigkeiten anhängen würde, es sei denn, ich habe Ihren Vorschlag falsch verstanden.

Fern war nicht das richtige Wort, ich meinte nur Pakete, die von Git installed installiert wurden

Könnten Sie das versuchen?

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

Gemäß meinem vorherigen Kommentar stoße ich immer noch auf das Problem ohne Abhängigkeit von storybook-addon-markdown . Daher glaube ich nicht, dass dieses Problem darauf zurückzuführen ist, dass Garn Git-URLs nicht ordnungsgemäß behandelt.

In der Tat lese ich zu schnell. Nun, das hat unseren Fehler behoben, aber ich habe keine Ahnung von deinem 😕 Entschuldigung

@opiation Hast du auch deine yarn.lock-Datei aktualisiert? Weil ich das tun musste

@Titozzz , ich yarn.lock . Ich habe die Sperrdatei mehrmals ohne Erfolg gelöscht und neu erstellt.

Ich bekomme das auch und ich habe keine Pakete von Git.

Ich wollte dieses Problem umgehen (https://github.com/yarnpkg/yarn/issues/6256), indem ich die Tarball-Versionen der Pakete verwendete, aber der obige Fehler wird tatsächlich für Tarball-URLs auf selbst gehosteten Github-Unternehmen ausgegeben.

Von github.com gehostete Tarballs haben irgendwie funktioniert. z.B
https://github.com/luwes/chameleon/archive/grasshopper-v0.0.1-beta.4.tar.gz

Ich sehe das gleiche Problem bei einem Projekt, das wir haben. Wenn ich jedoch die Deps entferne, die ein prepare -Skript als Teil der Installation ausführen (da es sich um Git-URLs handelt), funktioniert es. Diese zeigen zufällig auf Git-URLs, aber ich denke, es sind tatsächlich die prepare , die mehr yarn install -Prozesse auslösen, die aus irgendeinem Grund das Mutex-Flag zu untergraben scheinen. Ich frage mich, ob das daran liegt, dass die anderen Prozesse eher vom Root-Prozess als von anderen Root-Prozessen ausgelöst werden. Ich weiß nicht, ob diese Informationen helfen oder ob sie tatsächlich von der Basis abweichen. Aber ich dachte, ich würde teilen, was ich gefunden habe, unabhängig davon.

@khendry Ich habe das Problem wieder, und Sie haben Recht, es kommt von Git-Abhängigkeiten, die ein prepare -Skript in ihrer package.json haben! : +1:

Ich habe dies mit einem Projekt aufgespürt, das wir haben, und es bisher auf die gleichzeitige Installation eingegrenzt, die der Git-Fetcher hier startet. Wenn das Paket, das vom Git-Fetcher installiert wird, die gleichen Abhängigkeiten wie das aktuell installierte Paket aufweist, wird eine Race-Bedingung erstellt, bei der die duplizierten Pakete gleichzeitig nicht im Offline-Cache geteert werden.

Ich habe nicht genug von der Codebasis gesehen, um zu verstehen, wo / was die richtige Lösung ist, aber das ist der Anfang des Problems.

Gibt es darüber irgendwelche Neuigkeiten? Wir stehen auch vor diesem Problem.

Gleiches Problem. Es ist unmöglich, Garn mit CI zu verwenden. Jeder 2. Build ist mit diesem Fehler fehlgeschlagen 😞

Versuchen Sie, node_modules zu löschen.

yarn cache clean
yarn install --network-concurrency 1

Vielen Dank für das Teilen. Es ist zumindest eine Problemumgehung, aber keine wirkliche Lösung, wenn Sie eine relativ schnelle Erstellungszeit wünschen

Wir haben versucht, das Flag --network-concurrency ohne Erfolg zu verwenden. Das löst dieses spezielle Problem also nicht wirklich. Das Flag adressiert die Parallelität auf einer höheren Ebene als dort, wo das Problem auftritt.

Für mich löst --network-concurrency 1 das Problem. Ich weiß, dass es vorübergehend behoben wird, aber es funktioniert. Der Wert muss jedoch genau 1 .

Ich habe zu früh gesprochen. Ich hatte meinen Teamkollegen gefragt, ob wir das versucht hätten, anstatt mich selbst zu versuchen, und er war sehr zuversichtlich, dass wir ... er hatte sich geirrt und den vorherigen Beitrag falsch gelesen, weil er dachte, er habe mit der Mutex-Flagge zu tun, nicht mit dem Netzwerk Parallelität. Wir haben es seitdem erneut versucht und können bestätigen, dass dies anscheinend auch das Problem für uns angeht.

Das Setzen von --network-concurrency 1 funktioniert bei mir nicht.

Im Moment besteht die einzige Problemumgehung darin, yarn.lock vollständig neu zu generieren. Der Fehler, den ich bekomme, ist:

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)

Update: Ich habe gerade festgestellt, dass ich mit --skip-integrity-check diesen Fehler umgehen kann. Das ist natürlich wirklich eine Lösung. Dies scheint ein wichtiger Fehler in der Integritätsprüfungslogik zu sein.

Ich benutze [email protected] , [email protected]

@arcanis @ Rally25rs Weitere Details zu diesem Fehler:

Daher erscheint mir dies ziemlich seltsam, dass die Integritätsprüfsumme fehlschlägt, wenn man bedenkt, dass die sha1s gleich sind:

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)

Update: Nachdem ich oben gesehen habe, habe ich bestätigt, dass --skip-integrity-check diesen Fehler umgeht. Sieht nach einem schwerwiegenderen Fehler in der Integritätsprüfungslogik aus.

@opiation aus Neugier, können Sie Ihre package.json einfügen? Verwenden Sie irgendwo die folgende "Override" -Technik?

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

Zum Beispiel benutze ich es:

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

Und dies ist das Paket, für das ich den Fehler sehe . Also frage ich mich, ob dies damit zusammenhängt?

@hulkish , gemäß meinem ersten Beitrag, hier ist der Kern, den ich mit meinem package.json , yarn.lock und allen Tests erstellt habe, die ich ausgeführt habe und die alle den beschriebenen Fehler verursacht haben. Zur Verdeutlichung kann jede Zeile in failing_test.sh auf diesen Fehler stoßen, jedoch nicht konsistent. Sie müssen möglicherweise mehrmals versucht werden, um den Fehler zu finden. Um es in diesem Thread zu haben, fasse ich jeden Test unten zusammen:

Fehlgeschlagene Tests

• yarn install
• yarn install --frozen-lockfile
• yarn install --pure-lockfile
• yarn install --mutex network
• yarn install --network-concurrency 1
• Alle oben genannten Tests mit rm yarn.lock Voraus
• Alle oben genannten Tests in einem node:alpine Container mit git installiert (alpin zum Zeitpunkt der Erstellung dieses Threads)
• Alle oben genannten Tests in einem node:8-alpine Container mit git installiert

Was die "Override" -Technik betrifft, bin ich mir nicht sicher, was Sie meinen. Wenn Sie sich im Abhängigkeitswert auf das _protocol_-ähnliche Präfix beziehen (wie in Ihrem Beispiel npm: ), verwendet eine Entwicklerabhängigkeit ein github -Paket:

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

Die Fehler treten jedoch auch dann noch auf, wenn ich die Dev-Abhängigkeit entferne, sodass dies nicht verwandt zu sein scheint.

Rufen Sie @holyxiaoxin an - das Hinzufügen von --network-concurrency 1 dies für mein CI 👍 behoben

ping @imsnif ? Es scheint im Zusammenhang mit der Integritätsprüfung zu stehen, wie aus dem Kommentar von

@khendry Die Verwendung von prepare für unsere Git-Abhängigkeiten wurde nicht mehr für unser ci behoben, während --network-concurrency 1, --child-concurrency 1 und --skip-Integritätsprüfung nicht ausreichten

Wir konnten dies mit npm config set always-auth true beheben (wie hier dokumentiert). Wie ich am besten beurteilen kann, stellt npm Ihre Anmeldeinformationen standardmäßig nur zum Veröffentlichen von Paketen bereit, nicht zum Abrufen. Aus irgendeinem Grund hat Garn diese Einstellung bisher nicht beachtet, jetzt jedoch.

Ich hatte kürzlich dieses Problem mit yarn 1.12.3 und node 10.13.0 . Nachdem Sie viele der oben genannten Lösungen ohne Erfolg ausprobiert hatten, funktionierte das Löschen / Regenerieren der yarn.lock -Datei.

Ich habe ein ähnliches Problem bekommen. Das Entfernen von yarn.lock wie von @mvonballmo vorgeschlagen war das einzige, was es zum Laufen brachte. Es funktioniert immer noch nicht voll.

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.

Hallo Freunde,

Gemessen an den verschiedenen hier gemeldeten Fehlern scheint dies tatsächlich mehrere verschiedene Probleme zu sein:
ENOSPC: no space left on device, write ,
wanted sha1-Sl7Hxk364iw6FBJNus3uhG2Ay8Q= but got sha1-AHoWKXweP+Pg9aZkGBsAjFruGaM= (übrigens, sieht genau hin, aber diese sind nicht gleich),
the file appears to be corrupt: "Unexpected end of data" usw.

Ich schätze zwar, dass diese an einem ähnlichen Ort auftreten können, sie können jedoch durch völlig unterschiedliche Probleme und / oder Umgebungen verursacht werden. Die Integritätsprüfung (insbesondere der Rückruf von untarStream bei Fehlern - danke für das detaillierte Debugging @hulkish!) Ist ein Trichter, der viele Fehler erfassen kann, und es ist ein wenig schwierig, dem Benutzer über den tatsächlichen Fehler hinaus Feedback zu geben.

Dies gilt insbesondere für die Integritätsmigration (Auffüllen eines alten yarn.lock mit den neuen Integritätsfeldern), da dieser einmalige Prozess (einmal unter der Annahme, dass er erfolgreich ist) netzwerkintensiver ist als eine normale Installation (Es durchläuft alle Pakete ohne ein integrity -Feld und ruft ihr Registrierungsmanifest ab.)

Die Theorien über eine Rennbedingung sind interessant und definitiv eine Möglichkeit, ich würde sie gerne weiter untersuchen. Ich befürchte jedoch, dass die Reproduktion von @opiation bei mir nicht funktioniert hat. Ich führe jetzt meine 7. lokale Installation davon aus und es funktioniert immer noch ohne Probleme (ich habe das Skript nicht ausgeführt, sondern nur yarn , um es mit diesem package.json und yarn.lock zu installieren - ich verstehe das hat das Problem immer noch für dich verursacht?)

@opiation - können Sie dieses Problem trotzdem reproduzieren? Unter den gleichen Bedingungen? Vielleicht können wir eine Auflösungsstufe verringern und Sie können mir alles, was Sie tun, bis auf die Befehle sagen, um dies zu erreichen?

Hat noch jemand in diesem Thread ein Setup, das er teilen kann und das dieses Problem sogar teilweise konsistent reproduziert? Ich würde mich sehr freuen, dem auf den Grund zu gehen.

In meinem CI-System ist dieselbe Fehlermeldung aufgetreten:

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.

Es gelang mir jedoch, mein spezielles Problem herauszufinden. Ich dachte, ich würde hier eine Notiz für jeden hinterlassen, der auf etwas Ähnliches stößt:

Ursache

Ich habe yarn install auf meinem lokalen Computer aufgerufen, nachdem ich meinem Projekt eine neue Abhängigkeit hinzugefügt habe ([email protected]). Aufgrund eines lokalen .npmrc stellte Garn die Abhängigkeit von einer privaten Registrierung von mir wieder her. Das generierte yarn.lock enthielt die folgenden Zeilen:

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

Beachten Sie, wie das Paket aus einem privaten Repository aufgelöst wurde. Auf meinem CI-Computer hatte ich kein .npmrc mit den Anmeldeinformationen für die private Registrierung. Dies war die Ursache für die Fehlermeldung:

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"

Ich habe meine lokalen .npmrc repariert und meine yarn.lock :

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

Beachten Sie, wie das Paket jetzt aus der Standard-NPM-Registrierung aufgelöst wird. Der Fehler trat nicht mehr auf, sobald ich dies tat.

Fix

Wenn die Ursache Ihres Problems dieselbe ist wie meine, können Sie:

• Fügen Sie Ihrem CI-Computer oder die erforderlichen Anmeldeinformationen hinzu
• Passen Sie Ihre lokalen .npmrc ( yarn config list druckt die Registrierung, aus der das Garn wiederhergestellt wird) und regenerieren Sie dann yarn.lock .

Anmerkungen

Möglicherweise könnte die Fehlermeldung spezifischer sein.

Bearbeiten: Anfangs dachte ich, dass das Zurückrollen von Garn das Problem lösen würde - ich habe versehentlich mein fehlerhaftes Commit mit diesem Problem verknüpft. Garn war am Ende nicht das Problem.

TL; DR: Versuchen Sie, Ihre Datei yarn.lock zu löschen und erneut zu generieren.

Beim Versuch, auf Netlify aufzubauen, ist ein Fehler aufgetreten: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"

Durch Löschen des Ordners node_modules und der Datei yarn.lock und anschließendes erneutes Generieren über yarn install habe ich eine neue Datei yarn.lock mit verschiedenen Abhängigkeiten erhalten. Mit dieser neuen Datei hat Netlify mein Projekt erfolgreich erstellt.

@imsnif stimmte zu, dass hier scheinbar mehrere verschiedene Probleme gemeldet werden. Ich glaube, ich habe einen Repro-Fall aus einem Projekt, an dem ich arbeite, der das von @khendry hier skizzierte Problem auslöst

Ich sehe das gleiche Problem bei einem Projekt, das wir haben. Wenn ich jedoch die Deps entferne, die ein prepare -Skript als Teil der Installation ausführen (da es sich um Git-URLs handelt), funktioniert es. Diese zeigen zufällig auf Git-URLs, aber ich denke, es sind tatsächlich die prepare , die mehr yarn install -Prozesse auslösen, die aus irgendeinem Grund das Mutex-Flag zu untergraben scheinen. Ich frage mich, ob das daran liegt, dass die anderen Prozesse eher vom Root-Prozess als von anderen Root-Prozessen ausgelöst werden.

Wenn Sie die folgenden Repro-Schritte in der Hoffnung teilen, können Sie das Problem reproduzieren. Lassen Sie mich wissen, wenn Sie weitere Informationen benötigen.

Repro Schritte

1. Laden Sie mit dem Knoten v10.3.0 und dem Garn v1.12.3 in einem neuen Testordner die package.json und yarn.lock aus dieser Übersicht herunter
2. Führen Sie rm -rf ~/.cache/yarn* node_modules/ && yarn install --frozen-lockfile --network-concurrency 16 (leeren Sie den Cache und installieren Sie zuvor Knotenmodule für eine zuverlässige Umgebung. Stellen Sie die Parallelität hoch ein, um die Wahrscheinlichkeit eines Problems zu erhöhen.)
3. Beobachten Sie die Ausgabe wie folgt:

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.

Weitere Hinweise

Ich habe verschiedene Dinge ausprobiert, hier sind meine Notizen:

1. Das Problem wird für mich nicht zu 100% reproduziert. Wie oben erwähnt, scheint die Erhöhung der verwendeten Netzwerk-Parallelität das Auftreten des Problems wahrscheinlicher zu machen.
2. Die Verwendung einer Version von react-textarea-autosize die in der Paketregistrierung veröffentlicht wurde , lässt das Problem @khendry oben berichtet hat).
3. Das Setzen von --mutex file scheint hier überhaupt nicht zu helfen
4. Wie oben berichtet, wird alles ordnungsgemäß installiert, wenn ich die Netzwerk-Parallelität auf 1 (über das Argument --network-concurrency 1 ), wenn auch langsamer.
5. Ich habe dies auf Knoten v8.12.0 mit Garn v1.9.4 und v1.12.3 reproduziert. Dies lief auf dem Docker-Image circleci/node:8-stretch , das auf Circle CI 2.0 ausgeführt wurde.

Ich sehe diesen Fehler vor kurzem, nachdem ich das Garn auf 1.12.3 aktualisiert habe.
Siehe mein travis-ci Build-Fehler 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 .

Es passiert nur mit [email protected] .
Ich werde zurückschreiben, wenn ich irgendwie Erfolg habe.
PS.
Es war spezifisch für das Har-Validator-Paket.

Ich verstehe auch
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"
Mit Curl bekam ich 404 für https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.2.tgz
aber in meinem Browser kann ich es herunterladen.
Einer meiner Server, wenn ich das Garn auf 1.12.1 herunterstufte, funktioniert, aber auf dem anderen Server bleibt der Fehler gleich, auch wenn ich das Downgrade heruntergefahren habe (ich entferne in beiden Fällen das Garn-Cache-Verzeichnis).
Ist das möglich, dass es sich um ein Cloudflare-Problem handelt?

Nein, diese spezielle Instanz (Ihre und die von @ ankurk91) wird dadurch verursacht, dass har-validator nicht veröffentlicht wurde (vgl. # 6694).

Ich erhalte diesen Fehler nur in meiner CI-Umgebung, nachdem ich ein weiteres Repo als Abhängigkeit hinzugefügt habe ( "@team/myproject": "git+ssh://[email protected]/team/myproject.git#master", ). das kann ich bestätigen

• Das Hinzufügen von --network-concurrency 1 zu meinem CI-Skript löst das Problem, macht den Build aber natürlich sehr langsam
• Das Ausführen von yarn install --network-concurrency 16 provoziert den Fehler auch lokal

Weder das Reinigen des Caches noch das Zurücksetzen von yarn.lock machten einen Unterschied für mich

EDIT: Es scheint, dass der --network-concurrency 1 Fix nicht konsistent ist, leider 😢

gleicher Fehler hier,
leicht zu reproduzieren:
yarn upgrade typescript@^2.8

dann:
yarn upgrade [email protected]

Ich habe bei der Installation dieses letzten Pakets Strg + C gedrückt. Wenn ich erneut 'Garn-Upgrade' versuche, erhalte ich Folgendes:

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.

UPDATE: Das Folgende war auf beschädigte Metadaten in unserer Sonatype Nexus-Installation zurückzuführen und ist daher kein Garnproblem. Auf dem Weg zum Kontext.

Dies wird für mehrere Pakete in unserer CI-Umgebung angezeigt. Garn 1.12.3 und Knoten 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?"

Ich hatte ein ähnliches Problem, aber ich bekomme ... die Datei scheint beschädigt zu sein: "EBUSY: ...".
Ich habe meinen gesamten Garn-Cache geleert und erneut ausgeführt und immer noch den gleichen Fehler erhalten. Es scheint also, als würde Garn Dateien erstellen und für sich selbst sperren.

Dies ist unter 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.

Ich habe eine Problemumgehung durchgeführt, indem ich "yarn --pnp" ausgeführt habe, was funktioniert hat. Seltsam, da dies neuer und wahrscheinlich instabiler Code sein sollte.

Das Entfernen von yarn.lock hat es für mich zum Laufen gebracht.

Hallo allerseits, hatte gerade das gleiche Problem. Behebung durch Entfernen von .npmrc aus dem Ausgangsverzeichnis.

rm ~/.npmrc

@binchik - das ist das einzige, was für mich funktioniert hat.

Danke @binchik , das hat den Trick für mich getan. 👍

Nachdem ich zu der Reihe von Ereignissen zurückgespult habe, die dazu geführt haben, dass yarn fehlgeschlagen ist, habe ich ein npm-Skript in einer package.json ausgeführt, das ungefähr so ​​aussah:

"audit": "npm audit"

Was total albern ist, weil ich in diesem Projekt niemals npm . Nach diesem Befehl würde alles (einschließlich npm) nur zufällige Fehler aufweisen und niemals vollständig sein, entsprechend der Erfahrung anderer in diesem Thread.

Wenn jemand, der den Fehler reproduziert, untersuchen und herausfinden könnte, was genau das Problem verursacht, wäre dies sehr hilfreich! Ich habe es versucht, aber ich kann es nicht reproduzieren 🙁

Einige Hinweise:

• Wir müssen herausfinden, was in untarStream fließt, wenn es fehlschlägt. Meine Hypothese lautet, dass wir möglicherweise versuchen, eine JSON-Antwort als Tarball zu verarbeiten (https://github.com/yarnpkg/yarn/blob/master) /src/fetchers/tarball-fetcher.js#L146-L150)

• Das einzige, was meiner Meinung nach für .npmrc ist das Authentifizierungstoken. Ich würde mich freuen, wenn jemand bestätigen könnte, dass das Problem einfach durch Entfernen der Auth-Token-Zeile aus .npmrc (und nicht aus der gesamten Datei) verschwindet.

FWIW, ich bin heute auf dieses Problem gestoßen. Ein paar Dinge:

• Das Entfernen von .npmrc Problem behoben. Das einzige, was in der Datei enthalten war, hatte mit dem Authentifizierungstoken zu tun.
• npm install fehlgeschlagen und es wurde ein nicht autorisierter 401-Fehler protokolliert.
• Nach dem Entfernen der .npmrc Datei npm install wieder gearbeitet.

@deleteme Nach meinen Erkenntnissen klingt dies eher nach einem Nebenprodukt des Fehlers als nach der Ursache.

Ich habe mit und ohne .npmrc oder .yarnrc begegnet

Angesichts der Tatsache, dass dieses Problem plötzlich viel häufiger auftritt als gewöhnlich und dass es während der npm-Registrierung besonders schuppig ist , ist es sehr wahrscheinlich, dass meine Hypothese nicht weit entfernt ist

@arcanis hat gerade angefangen, dieses Problem heute zu haben. Ich kann bestätigen, dass das Problem behoben wurde, indem diese npmrc-Authentifizierungstokenzeile entfernt wurde.

In meinem Fall wurde kein ~/.npmrc erstellt. Aber das Regenerieren von yarn.lock hat bei mir funktioniert.

Einfach,

$ rm yarn.lock && yarn

BEARBEITEN: Dieses Problem zweimal angegangen, nur um hier zu landen. :Lächeln:

In meinem Fall verwende ich CircleCI, circleci/node:10.11.0 Docker-Image und [email protected] , und es gibt kein ~/.npmrc . Vielen Dank, dass Sie @achillesrasquinha. Für mich geht das.

Ich bin seit über einer Woche mit diesem Problem konfrontiert. yarn install --network-concurrency 1 Problem gelöst, aber es ist sehr sehr langsam.

Übrigens könnten diese Informationen für jeden hilfreich sein.
Ich habe in meinem Projekt ein benutzerdefiniertes npm-Paket (intern) verwendet. Ich bekomme immer das gleiche Problem wie .cache/v4 , zeige aber bei jedem Fehler unterschiedliche Paketnamen. Nachdem ich viel Zeit verbracht habe, finde ich eine zufällige Beobachtung.
Mein Projekt und mein benutzerdefiniertes npm-Paket verwenden dasselbe yarn build zum Erstellen des Bundles. Ich habe den Namen meines benutzerdefinierten Paketerstellungsskripts auf einen anderen Namen als yarn build:p aktualisiert. Dann geht es los. Ich bin viele Male gebaut worden. Es ist nicht gescheitert. Nicht sicher, wie diese 2 abhängig sind, aber für mich gearbeitet.

Das Entfernen von .npmrc nur nicht für mich getan. Ich musste auch meine yarn.lock -Datei entfernen, wie

Ich bin mir nicht sicher, ob das Entfernen von .npmrc Auswirkungen auf mich hatte.

Ich bin nicht wirklich ein Fan des Löschens der yarn.lock -Datei. Ich habe also einfach das har-validator -Paket aus dem yarn.lock und dann yarn das hat das Problem für mich behoben.

Ja, rm yarn.lock arbeiten für mich. Problem mit Paket 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"

Hallo, har-validator-5.1.2 wurde von npm nicht veröffentlicht, wie hier angegeben. Https://github.com/ahmadnassri/node-har-validator/issues/112#issuecomment -437378269, daher müssen Sie Ihre Abhängigkeiten über yarn upgrade aktualisieren yarn.lock , das von den anderen empfohlen wurde).

Ich nehme an, dieses Problem kann geschlossen werden.

Das Entfernen von yarn.lock hat bei mir nicht funktioniert, wie in meinem ersten Problembericht erwähnt. Auch das Entfernen von .npmrc . Außerdem hat das Docker-Image node:10-alpine meines Wissens keine .npmrc -Datei oder erstellt diese.

Schließlich ist der Fehler nicht auf das Paket har-validator . Tatsächlich bin ich mit diesem Paket noch nie darauf gestoßen. Ich habe es mit Paketen lodash , fbjs , react und vielen anderen erlebt.

Ich habe meine Versuche, die dieses Problem noch zuverlässig reproduzieren, in einem früheren Kommentar zusammengefasst . Wenn ich mit Docker teste, kann ich das Problem reproduzieren, einschließlich nur der package.json also keine yarn.lock , keine .npmrc , keine node_modules . Ich kann dieses Problem weiterhin auf meinem lokalen Computer, auf einer GCE-Instanz und mit dem CI von Gitlab.com reproduzieren. Weder --network-concurrency=1 noch --skip-integrity-check scheinen das Problem für mich zu lösen. Daher würde ich zögern, das Schließen dieses Problems zu empfehlen, insbesondere da alle oben genannten Tests mit npm install funktionieren, vorausgesetzt, dass yarn install ein Ersatz für npm install gegeben die gleichen package.json .

Das Problem ist, dass die npm-Registrierung im Allgemeinen instabil ist und Fehler zurückgibt (mit einer höheren Rate, wenn anscheinend mehrere Anforderungen ausgelöst werden - möglicherweise eine Art Drosselung pro IP?). Aus irgendeinem Grund werden sie nicht richtig von Yarn gefangen, das blind versucht, sie zu hashen und mit dem erwarteten Hash zu vergleichen - was fehlschlägt.

Es gibt also einen Fehler in Yarn (wir sollten einen hilfreicheren Fehler drucken), aber da das eigentliche Problem darin besteht, wie flockig die npm-Registrierung ist, ist dies im Moment nicht meine Priorität (ich würde jedoch definitiv eine PR überprüfen!). .

Warum es bei npm nicht passiert: Sie wiederholen ihre Anfragen, bis sie arbeiten. Garn hat einen Mechanismus, um dies zu tun, aber nicht den Teil, der speziell den Hash berechnet.

Ich würde vorschlagen, einen Offline-Spiegel zu verwenden, um sich bei Ihren Installationen nicht mehr auf die npm-Registrierung zu verlassen.

https://github.com/yarnpkg/yarn/pull/6817 "behebt" dies, indem der tatsächliche Statuscode angezeigt wird, der von der Registrierung zurückgegeben wird. Ich würde es vorziehen, stabil zu sein, anstatt es blind zu wiederholen, bis es funktioniert, also habe ich den Wiederholungscode nicht hinzugefügt, aber wenn es keine Verbesserungen am Horizont gibt, müssen wir das möglicherweise tun.

In der Zwischenzeit werde ich diese Diskussion schließen, da sich die Fehlermeldungen ändern und dieser Thread ziemlich groß wird (wir können neue öffnen, um jeden Statuscode einzeln zu diskutieren).

In meinem Fall wurde kein ~/.npmrc erstellt. Aber das Regenerieren von yarn.lock hat bei mir funktioniert.

Einfach,

$ rm yarn.lock && yarn

Dankeschön,
rm -rf ./yarn.lock && yarn
Es ist Arbeit für mich!

falls es jemandem hilft:

• Der gleiche Fehler trat bei mir auf, als ich vergessen hatte, mich bei npm anzumelden (doh!)

Für mich wurde das Problem mit service docker restart (Ubuntu 18.04) behoben.

Ich habe zeitweise und nicht deterministische Fehler wie diesen erlebt. Ich starte meinen Build neu, nichts anderes hat sich geändert und es funktioniert. Hat jemand Alternativen zu Garn?

Ich bekomme bei jedem Build denselben Fehler (jedes Mal Fehler bei einem anderen npm-Modul), nachdem ich eine PR erstellt habe, um unser Basis-Docker-Image von node:8.12.0 auf node:8.13.0 zu aktualisieren. Ich habe diese Knoten-Docker-Bilder überprüft und festgestellt, dass die vorinstallierte Garnversion von v1.9.4 auf v1.12.3 geändert wurde. Siehe: zugehöriges Git-Commit . Ich habe einige der vorgeschlagenen Korrekturen in diesem Thread ausprobiert, ohne das Problem zu beheben. Ich konnte das Problem beheben, indem ich einfach die Garnversion in meiner Docker-Datei auf v1.9.4 herunterstufte . Ich weiß, dass diese Garnversion für andere problematisch war, aber für mich löst die neuere Garnversion das Problem aus. Ich werde bemerken, dass ich eine .npmrc -Datei verwende, die Anmeldeinformationen für den Zugriff auf private Module über jfrog artifactory bereitstellt, und wir haben artifactory so eingerichtet, dass alle npm-Module gespiegelt / vertreten werden.

Warum ist das geschlossen? Immer noch CI brechen

In der Zwischenzeit werde ich diese Diskussion schließen, da sich die Fehlermeldungen ändern und dieser Thread ziemlich groß wird (wir können neue öffnen, um jeden Statuscode einzeln zu diskutieren).

Ich werde fortfahren und diesen Thread sperren, da es mir so scheint, als hätte er seine Nützlichkeit überschritten. Als eine Erinnerung:

• Wenn Sie diese Fehlermeldung haben, verwenden Sie sehr wahrscheinlich eine alte Version. Aktualisieren Sie auf 1.13+, um die wahre Fehlermeldung zu erhalten. Möglicherweise gibt die Registrierung aus irgendeinem Grund einen HTTP 500 zurück.

• Wenn Sie immer noch Fehler erhalten, die anscheinend von Yarn selbst stammen, öffnen Sie einen neuen Thread und erläutern Sie, wie das Problem reproduziert werden kann. Wenn Sie keine Reproduktion bereitstellen, können wir keine Lösung bereitstellen und müssen Sie wahrscheinlich bitten, sich selbst zu untersuchen.