<p>Die Garninstallation schlägt gelegentlich mit "ENOENT: Keine solche Datei oder kein solches Verzeichnis" fehl</p>

Interessant, also scheitert es nur bei Travis, funktioniert aber beim Testen vor Ort? Das ist sehr seltsam, da Docker sicherstellen soll, dass die Umgebung konsistent ist.

@ Daniel15 Ich weiß richtig ...

Ich habe den Knoten auf Version 6 herabgestuft und er schlägt bei Travis immer noch fehl. Ich habe die Flagge --verbose zu yarn install hinzugefügt und alles, was ich bekam, war

verbose Performing "GET" request to "https://registry.yarnpkg.com/spawn-wrap/-/spawn-wrap-1.3.4.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/yargs/-/yargs-6.6.0.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/yargs-parser/-/yargs-parser-4.2.1.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/fibers/-/fibers-1.0.15.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/selenium-standalone/-/selenium-standalone-5.11.2.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/tcp-port-used/-/tcp-port-used-0.1.2.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/babel-runtime/-/babel-runtime-5.8.38.tgz".
verbose Error: ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol'
    at Error (native)
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol'".

Ich bin offen für Ideen, wie man dies debuggt.

Ein Downgrade auf Garn 0.18.1 schien dies für mich zu beheben. Es scheint, als ob 0,19 eine Regression haben könnte; siehe # 1834

Ich habe auch dieses Problem mit Garn 0.23.3, es passiert nicht beim Erstellen eines Bildes, sondern einfach beim Ausführen eines CI.
Der Fehler ist folgender:

$ time yarn --frozen-lockfile
yarn install v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/builds/linagora/petals-cockpit/yarncache/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/src'".
info If you think this is a bug, please open a bug report with the information provided in "/builds/linagora/petals-cockpit/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

real    0m9.812s
user    0m7.596s
sys 0m0.932s

Ich denke, es gibt eine seltsame Möglichkeit, Dateien zu entfernen ...

Wichtiger Punkt: Der Cache war leer!

Und auf meinem Computer bekomme ich Folgendes, wenn ich versuche zu repro:

yarn install v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-beta.8.tgz: EEXIST: file already exists, mkdir '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/src/metadata'".
info If you think this is a bug, please open a bug report with the information provided in "/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Und mit Garn 0.21.2:

yarn install v0.21.2
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-beta.8.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/bundles/core.umd.js'".
info If you think this is a bug, please open a bug report with the information provided in "/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Das ist furchtbar!

Und ich stimme @twooster zu, dass 0.18.1 in Ordnung ist!

@ Daniel15 es funktioniert auch lokal nicht. Eigentlich funktioniert es NIE, wenn der Cache für mich leer ist!

@victornoel Der letzte Fehler könnte https://github.com/yarnpkg/yarn/issues/2714 sein

@bestander Ich habe damals 0.19.1 ausprobiert und es hat nicht funktioniert…

Ich habe es erneut versucht und jetzt der Fehler:

• wird nicht mit einem leeren Cache angezeigt, sondern im folgenden Fall (ich hoffe wirklich, dass es reproduzierbar ist…):
  
  
  
  • rm -rf der Garncache
  
  
  • Klon https://gitlab.com/linagora/petals-cockpit.git
  
  
  • Kasse 5f31ccb4b2357201baa50539b30702cffceb6992
  
  
  • Führen Sie das Garn im Verzeichnis frontend
  
  
  • Kasse Master
  
  
  • Führen Sie das Garn erneut im Verzeichnis frontend
  
  
  • Ich bekomme: error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, utime '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core/testing.js'". (Ich verwende meine eigene Registrierung, aber das gleiche passiert ohne sie)
  
  
• erscheint mit Garn 0.21.2, 0.19.1, aber nicht mit 0.18.2

Ich denke also nicht, dass es dasselbe ist, hoffen wir, dass Sie es zumindest reproduzieren können ...

(Eigentlich habe ich es einfach noch einmal versucht und den Fehler mit einem leeren Cache und Garn 0.21.2 reproduziert, obwohl dies vorher nicht der Fall war. Vielleicht gibt es irgendwo anders eine andere Datei, die die Ursache für dieses Problem ist, und die nicht in der Zwischenspeicher?)

@bestander Ich werde immer noch Garn testen, sobald # 2744 als nächtlicher Build verfügbar ist :)

Ping mich an, wenn ich helfen kann.
Die beste Aktion ist, eine PR mit einem fehlerhaften (und übersprungenen) e2e-Test zu senden.

@bestander gut, nein, ich bekomme immer noch Fehler wie:

➜  frontend git:(master) ✗ yarn
yarn install v0.22.0-20170227.1509
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/facade/lang.d.ts'".

oder:

➜  frontend git:(master) ✗ yarn
yarn install v0.22.0-20170227.1509
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/typescript/-/typescript-2.2.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-typescript-2.2.1-4862b662b988a4c8ff691cc7969622d24db76ae9/lib/typescriptServices.js'".

Ich werde sehen, ob ich einen e2e-Test machen kann.

@bestander trotzdem kann ich eine vollständige Stacktrace des Fehlers bekommen?

Ich sehe das nur im yarn-error.log:

Trace: 
  Error: http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.es5.js'
      at Error (native)

Das ist ein bisschen nutzlos :)

Der detaillierte Fehler ist:

{ Error: http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js'
    at Error (native)
  errno: -2,
  code: 'ENOENT',
  syscall: 'lstat',
  path: '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js',
  fstream_type: 'File',
  fstream_path: '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js',
  fstream_class: 'FileWriter',
  fstream_stack: 
   [ '/home/vnoel/Linagora/Petals/dev/git/yarn/node_modules/fstream/lib/writer.js:285:28',
     '/home/vnoel/Linagora/Petals/dev/git/yarn/node_modules/graceful-fs/polyfills.js:284:29',
     'FSReqWrap.oncomplete (fs.js:123:15)' ] }

Ich weiß nicht genau, was ich damit anfangen soll ... es passiert bei package-fetcher.js , Zeile 56 genau, ich habe jedoch Probleme, die Quelle zu finden ...

Es scheint dumm zu sein, aber ich habe das Gefühl, dass es nur dann fehlschlägt, wenn mein vernetzter npm-Spiegel (ein Sonatyp-Nexus in meiner Firma) das Artefakt @angular/core gespiegelt hat. Wenn dies nicht der Fall ist, laufen die Dinge gut und es schlägt bei einem anderen Artefakt fehl, das bereits gespiegelt ist (in diesem Fall typescript ).

Wenn ich das Artefakt von Hand aus dem Nexus-Spiegel entferne, funktioniert es!

Also… es ist ein bisschen so, als ob Garn nicht mithalten kann, wenn die Dinge zu schnell ankommen ^^, denn wenn ich die normale npm-Registrierung ohne Verwendung meines Spiegels verwende, läuft es normalerweise gut (wir haben eine langsame Internetverbindung).
Und es würde erklären, warum es auf CI-Systemen oft ausfällt, weil sie normalerweise sehr schnelle Internetverbindungen haben…

Das ist ein bisschen langwierig, um daraus zu schließen, aber es könnte helfen, den Ursprung des Problems zu finden.
WDYT @bestander?

Für die Aufzeichnung denke ich, dass der Fehler von tar.Extract Schritt in der Abruf-Pipeline ausgeht, aber ich bin nicht ganz sicher ^^

Vielen Dank, dass Sie mehr recherchiert haben,

Ich kann das Szenario von https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 wiederholen.
Etwas nachgehen.

Ich bekomme

error An unexpected error occurred: "https://registry.yarnpkg.com/typescript/-/typescript-2.2.1.tgz: ENOENT: no such file or directory, lstat '/Users/bestander/Library/Caches/Yarn/npm-typescript-2.2.1-4862b662b988a4c8ff691cc7969622d24db76ae9/lib/typescriptServices.js'".

Wenn ich jedoch immer wieder yarn install versuche, wird die Installation schließlich abgeschlossen.
Das Explodieren der .tgz-Datei endet mit einem Fehler.

Aktualisieren:

• Die .tgz scheint in Ordnung zu sein. Ich kann diejenige, die während der Abrufphase fehlschlägt, manuell entpacken
• Ich frage mich, ob das Paket tar diesen Fehler aus irgendeinem Grund auslöst. Könnte es sich um eine Parallelität handeln?

Einige Hilfestellungen bei der Untersuchung, warum das Aufheben dieser wenigen Abhängigkeiten (in meinem Fall Typoskript und Winkelkern) Fehler verursacht, sind willkommen.
Parallelität? Fehler in https://github.com/npm/node-tar?

@victornoel , kannst du den Fehler mit yarn install --network-concurrency 1 reproduzieren?

@bestander mit --network-concurrency 1 Der Fehler tritt nicht auf (ohne ihn erscheint er jedes Mal).
Aber was ist der Standardwert dieses Parameters? Welchen Wert ich auch wähle (1, 2, 4, 8), es funktioniert, und wenn ich es überhaupt nicht sage, schlägt es fehl ...

Der Standardwert ist 15, ich kann das Problem mit Parallelität 15 mit einem sauberen Checkout von https://gitlab.com/linagora/petals-cockpit.git#075bac4c54fee466568c000c7ffe8025f593e212 .

Hervorragende Nachrichten! Ein Schritt weiter in Richtung einer Lösung UND einer Problemumgehung :)

Einige Ergebnisse.

TL; DR Ich habe keine Ideen, wie ich es endgültig beheben kann. Dies erfordert etwas tieferes Wissen über Node.j.

1. Das Netzwerk kann aus möglichen Problemen entfernt werden.
   Ich habe den Offline-Spiegel für die .tgz-Dateien in yarn.lock eingerichtet und kann das Problem mit Paketen reproduzieren, die von der Festplatte installiert wurden.

Das Problem liegt im unzip / untar-Stream im Tarball-Fetcher-Code.

1. Ich habe eine andere Bibliothek ausprobiert, die tar extrahiert - https://github.com/mafintosh/tar-fs vs aktuelle https://github.com/npm/node-tar/. Sie scheitern beide auf die gleiche Weise.
   Etwas tiefer gehen - Ausnahmen treten im Knoten auf, wenn mehrere mkdirp-Operationen ausgeführt werden

Error: ENOENT: no such file or directory, chmod '/Users/bestander/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/di/injector.d.ts'
  errno: -2,
  code: 'ENOENT',
  syscall: 'chmod',
  path: '/Users/bestander/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/di/injector.d.ts' }

Ich denke, Core-4.0.0 und Typoskript-2.2.1 schlagen fehl, weil sie einige Dateien und tiefe Ordnerstrukturen haben und nicht installiert werden können, während viele gleichzeitige mkdir / Kopiervorgänge ausgeführt werden.

Jedes Mal, wenn ein anderer Systemaufruf fehlschlägt: chmod, rmdir, mkdir, lstat, utime.

Und es ist im Code der Bibliotheken nicht offensichtlich.

1. Schlägt auf Knoten 4, 6 und 7 nicht fehl.

2. Ich konnte den Fehler bei einer auf 8 eingestellten Parallelität nicht reproduzieren, daher sende ich eine PR, um die Standard-Netzwerk-Parallelität zu verringern.

1. Ich habe mich gefragt, wie sich die Parallelität auf die Installationsgeschwindigkeit auswirkt.

5.1. Reinigen Sie den Cache mit Offline-Mirror (kein Download) auf meinem MBPro 13 "und entpacken Sie Dateien mit node-tar .
Parallelität 12 - schlägt fehl
Parallelität 8 - 18 Sekunden
Parallelität 4 - 18 Sekunden
Parallelität 2 - 21 Sekunden

5.2. Reinigen Sie den Cache mit Offline-Mirror (kein Download) auf meinem MBPro 13 "und entpacken Sie Dateien mit tar-fs .
Parallelität 12 - 15 Sekunden
Parallelität 8 - 15 Sekunden
Parallelität 4 - 17 Sekunden
Parallelität 2 - 18 Sekunden

5.3. Laden Sie Pakete aus dem Internet auf meinen MBPro 13 "herunter, leeren Sie den Cache und verwenden Sie tar-fs , um Dateien zu entpacken.
Parallelität 12 - einmal fehlgeschlagen
Parallelität 8 - 21 Sekunden
Parallelität 4 - 23 Sekunden
Parallelität 2 - 34 Sekunden

Es scheint sicher genug zu sein, die Parallelität auf 8 zu setzen. Außerdem ist es sinnvoll, die Tar-Bibliothek zu wechseln.
Ich werde mit einer PR folgen.

Ein geeigneter Weg, dies zu beheben, wäre, https://github.com/mafintosh/tar-fs zu forken und intelligentere fs-Operationen durchzuführen, z. B. mkdir für jeden Ordner nur einmal zu verwenden

tar-fs Betreuer scheint aktiv zu sein, vielleicht könnten wir dort ein Problem eröffnen und sehen, was sie darüber wissen / vorschlagen?

@ Victorornoel , würdest du das bitte tun?

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

Ich bin in einem ähnlichen Szenario auf diese Fehlermeldung gestoßen, als ich yarn auf den Build-Agenten meiner Jenkins getestet habe.

Wissen Sie, welche Bedingungen erforderlich sind, um diesen Fehler auszulösen? Ich möchte die npm -Anrufe meines Build-Systems aus Geschwindigkeitsgründen durch yarn ersetzen, aber wenn ich die Parallelität deaktivieren muss, befürchte ich, dass dadurch ein Bonus negiert wird.

@ProdigySim , wie in # 2829 (das im

@ Victorornoel Danke für die Information. Ich bin mir nicht sicher, ob es in meinem Fall ausreicht, nur --network-concurrency zu reduzieren, da wir auch mehrere Garninstanzen parallel ausführen würden.

Ich kann dieses Problem sogar mit --network-concurrency 1 wiederholen, aber vielleicht sollte ich dafür ein separates Problem eröffnen?

Verwenden Sie das gleiche Test-Repo, das Sie oben angegeben haben:

#!/bin/bash
set -x # echo commands

# Clear yarn cache
rm -rf $(yarn cache dir)

# Clone the repo into two separate spots
git clone https://gitlab.com/linagora/petals-cockpit.git repo1
git clone https://gitlab.com/linagora/petals-cockpit.git repo2

# Run yarn on both in parallel
cd repo1/frontend && yarn --network-concurrency 1 &
cd repo2/frontend && yarn --network-concurrency 1 &

Dies bringt mir jedes Mal den Fehler ein (4 für 4 bisher)

error An unexpected error occurred: "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.2.tgz: 
ENOENT: no such file or directory, lstat '/Users/<snip>/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.2-59535050e5d0e6141417186eee571296f8e9c3d0/@angular/core.es5.js'".

Auf Garn 0.21.3, Knoten v4.5.0, OSX 10.11.6

Bisher konnte ich dieses Problem umgehen, indem ich nur Garn in Build-Jobs einbezog, die niemals parallel ausgeführt werden, oder völlig andere Paketsätze verwendete, aber selbst dann bin ich mir nicht sicher, ob es sicher ist - daher frage ich über Root-Bedingungen für diesen Fehler.

@ProdigySim
Dies ist ein separates, aber verwandtes Problem, das durch den globalen Download-Cache von Yarn verursacht wird. Eine Problemumgehung besteht darin, für jedes Verzeichnis einen anderen Cache zu erstellen.

Sie können immer noch mit --network-concurrency 8 laufen. (Ich habe eigentlich keine Probleme mit unbegrenzter Netzwerk-Parallelität.)

Mehr Kontext hier .

@bestander überraschenderweise ist heute das Problem erneut
Wir scheinen keine Rückmeldungen vom tar-fs-Projekt zu erhalten. An wen können wir uns sonst noch wenden, um Hilfe zu erhalten?

Dieses Problem tritt auch bei meinen Travis-Builds für OS X auf. Ich habe den Cache gelöscht und die Netzwerk-Parallelität festgelegt, aber nichts hat geholfen.

@kevingelion Auf welchen Wert haben Sie die Netzwerk-Parallelität eingestellt? Sei drastisch und setze so etwas wie 2, um zu sehen, ob das Problem dieses ist :)

@victornoel Ich habe es auf 1 und 2 gesetzt, und beide Optionen führten zu einem Fehler. Ich habe yarn --mutex network und auch keine Würfel.

@bestander der folgende Hack behebt (edit: NOT) das Problem:

diff --git a/src/util/request-manager.js b/src/util/request-manager.js
index e0e134a2..995dac69 100644
--- a/src/util/request-manager.js
+++ b/src/util/request-manager.js
@@ -214,8 +214,7 @@ export default class RequestManager {
     }, params.headers);

     const promise = new Promise((resolve, reject) => {
-      this.queue.push({params, resolve, reject});
-      this.shiftQueue();
+      this.execute({params, resolve, reject});
     });

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

Offensichtlich ist es kein Fix, es umgeht den Anforderungsmanager und sein Warteschlangensystem vollständig, aber es zeigt, dass das Problem von diesem Subsystem kommt.

Danke, Victor!

Am 24. März 2017 um 18:07 schrieb Victor Noël [email protected] :

@bestander https://github.com/bestander Der folgende Hack behebt das Problem
Problem:

diff --git a / src / util / request-manager.js b / src / util / request-manager.js
Index e0e134a2..995dac69 100644
--- a / src / util / request-manager.js
+++ b / src / util / request-manager.js
@@ -214,8 +214,7 @@ Standardklasse exportieren RequestManager {
}, params.headers);

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

• this.queue.push ({params, auflösen, ablehnen});
• this.shiftQueue ();
• this.execute ({params, auflösen, ablehnen});
  });

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

Offensichtlich ist es kein Fix, es umgeht den Anforderungsmanager vollständig und
sein Warteschlangensystem, aber es zeigt, dass das Problem daraus resultiert
Teilsystem.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-289102067 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/ACBdWF66L-NzAInx7Bhs6V7s7LKahxxUks5rpAZ1gaJpZM4L3JbX
.

peitscht nicht, tut es nicht: D aber es verbessert die Dinge ein bisschen

Entschuldigung für das falsche Positiv, ich war zu eifrig, meine Ergebnisse zu melden :)

Es ändert die Dinge, weil es mir nie gelingen würde, die Winkelkernabhängigkeit oder das Typoskript (immer diese) herunterzuladen, bevor ich das Garn viele Male ausführen konnte, aber dort schlug es beim ersten Mal fehl und beim zweiten Mal erfolgreich, und ich vergaß zu entfernen Der Cache zwischen meinen Versuchen, also dachte ich, es würde funktionieren.

Nun, es kommt darauf an, jetzt funktioniert es manchmal, manchmal nicht (mit dem Hack, also ist es kein totaler Fehler oder meine Internetverbindung ist momentan zu langsam ...)

Ich stoße auch in unseren CI-Builds darauf. Nach vielen Tests konnte ich mich endlich auch lokal reproduzieren.

Wiederum funktioniert es manchmal, aber es schlägt häufig mit einem der folgenden Fehler fehl (was den Anschein erweckt, dass irgendwo eine Art Rennbedingung vorliegt):

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

Ich habe es auf ein Paket isoliert, das wir direkt aus einem privaten Repository auf GitHub installieren. Interessanterweise ist das Paket, auf das in der Fehlermeldung verwiesen wird, immer eine Abhängigkeit von diesem Paket (und es ist immer ein anderes Paket, das wir direkt von GitHub installieren, jedoch kein privates Repository). Es scheint also, als würde ein Repro-Fall Pakete von privaten GitHub-URLs installieren, deren Unterabhängigkeiten auch von GitHub-Repositorys installiert werden (nicht unbedingt privat).

Ich bin mir nicht sicher, ob das überhaupt hilft ... Ich versuche gerne, auf jede erdenkliche Weise zu helfen!

Bearbeiten: Nicht sicher, ob dies hilfreich ist oder nicht, aber das Paket der obersten Ebene wird im Format "git+ssh://[email protected]/org/package.git#v1.0.0" , und im Fehlerfall sieht die heruntergeladene Unterabhängigkeit so aus, als würde sie über https heruntergeladen mit einer URL von "https://codeload.github.com/org/package/tar.gz/ljasdf08i234098aifj" .

Ich untersuche das etwas genauer.
Ich habe versucht, ein eigenständiges Skript für gleichzeitige tar-fs-Extrakte zu erstellen, aber ich denke eher, dass das Problem darin besteht, dass die tar-Datei während des Downloads beschädigt wird.

Hab es gefunden, Doh.

Im Beispiel von https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 enthält Yarn doppelte Pakete, die parallel heruntergeladen und extrahiert werden.
Die duplizierten sind @angular/core/-/core-4.0.0-rc.1 und typescript/-/typescript-2.2.1.tgz .

Bei hoher Parallelität wird zufällig gleichzeitig in denselben Cache-Ordner extrahiert.
Ich werde untersuchen, warum Yarn diese beiden Pakete nicht dedupliziert, und einen Fix senden.

Keine Magie auf OS- oder Teerextraktionsstufe.

haha, gute arbeit @bestander , froh, dass wir endlich das problem gefunden haben!

Großartige Arbeit https://github.com/yarnpkg/yarn/pull/3090 als auch https://github.com/yarnpkg/yarn/pull/3106 haben uns daran gehindert, Yarn zu verwenden.

Vielen Dank!

Ich hatte dieses Problem bei der Installation des Prop-Typ-Moduls. Jedes Mal, wenn ich versuchte, es zu installieren, wurde ENOENT auf einem anderen Dateinamen ausgeführt. Für mich verschwand das Problem nach der Installation von npm 5.0.2

$ yarn add prop-types
yarn add v0.21.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/prop-types/-/prop-types-15.5.10.tgz: ENOENT: no such file or directory
....

$ npm -g install npm

# whoops, looks like npm installed itself to different location than apt-get did
$ npm -v 
3.5.2

# remove the cached link from shell so the right version can surface
$ hash -d npm
$ npm -v
5.0.2

$ yarn add prop-types
... properly installs prop-types as expected

@skylize Das ist wahrscheinlich zufällig - Yarn verwendet den npm-Client überhaupt nicht, sodass die Version von npm die Ausführung von Yarn überhaupt nicht beeinflusst.

Dies führt dazu, dass meine Travis-Builds fast jedes Mal mit ein paar verschiedenen Paketen fehlschlagen. Gibt es schon eine Lösung?
error An unexpected error occurred: "https://registry.yarnpkg.com/apollo-client/-/apollo-client-1.8.0.tgz: ENOENT: no such file or directory, utime '/var/lib/jenkins/.cache/yarn/v1/npm-apollo-client-1.8.0-3b5d1976a06a0f82b2fc66fe71754868193dadb9/flow-typed/npm/webpack_vx.x.x.js'".

@ Redmega
Das gleiche hier, aber das funktioniert:

yarn install --network-concurrency 1

Welche Version verwenden Sie? Dies soll schon behoben sein ...

Le 8 août 2017 6:37 PM, "Ben Merckx" [email protected] a écrit:

@ Redmega https://github.com/redmega
Das gleiche hier, aber das funktioniert:

Garn installieren --Netzwerk-Parallelität 1

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-321011749 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AAJ0z5qFb7gSW4w14_RbFNjsn4sRYV78ks5sWI7hgaJpZM4L3JbX
.

@victornoel Ich verwende v0.27.5 auf der Jenkins-Maschine, genau wie meine lokale.

Bitte versuchen Sie es mit den Nightlies: https://yarnpkg.com/en/docs/nightly

Das Entfernen der Datei yarn.lock und yarn install das Problem für mich behoben.

Dies führt auch dazu, dass meine Jenkins-Builds gelegentlich fehlschlagen. Normalerweise funktioniert es nach einem zweiten Versuch, schlägt aber später erneut fehl.

@ajcrites @Redmega @headione @benmerckx Sie sollten ein anderes Problem öffnen, wenn Sie diese Art von Problem haben. Dieses Problem wurde mit Sicherheit behoben, daher muss Ihr Problem ein anderes sein, auch wenn es ähnliche Symptome aufweist.
Ich bin mir ziemlich sicher, dass Ihr Problem besser gelöst werden kann, wenn Sie ein anderes Problem öffnen :)

Wir haben das gleiche Problem, parallele Builds von Paketen in Jenkins mit Node 8.5 durchzuführen. Wir müssen uns derzeit an 0.27.5 halten, bis 1.0.2 veröffentlicht wird, um einen weiteren Fehler zu beheben. Aber danke für deine Unterstützung und Arbeit trotzdem :)

@floric Ich

Bearbeiten: Ich werde versuchen, 8.11.1 zu verwenden, um zu sehen, ob es eine neueste Version von Garn ohne den Fehler enthält.

@Niceplace möchten Sie möglicherweise die Option --mutex ausprobieren: https://yarnpkg.com/de/docs/cli#toc -concurrency-and-mutex

Wir haben Pläne, eine bessere Verriegelung pro Paket hinzuzufügen, um dies bald zu vermeiden.

Ich habe zeitweise Fehler, bei denen sowohl ENOENT: no such file or directory, chmod als auch ENOENT: no such file or directory, lstat versuchen, yarn --mutex=network auf der Wurzel eines Monorepo mit aktiviertem Garnarbeitsbereich auszuführen ...

Es scheint nicht konsistent zu sein, ich bekomme entweder das eine oder das andere zufällig. (1.6.0 und Knoten 8.11.1 und 9.11.1)

Insbesondere sind die Fehler:

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

und

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

Ich verwende Yarn 1.7.0 und habe einen ähnlichen Fehler. Yarn schafft es schließlich, das Paket nach mehreren Läufen zu installieren.

An unexpected error occurred: "ENOENT: no such file or directory, lstat '/home/nieltg/.cache/yarn/v1/npm-npm-registry-client-8.5.1-8115809c0a4b40938b8a109b8ea74d26c6f5d7f1/lib/dist-tags/fetch.js'".

BEARBEITEN:
Ich habe yarn --network-concurrency 1 aber der Fehler tritt immer noch bei mir auf. Hier ist ein weiteres Beispiel für die Datei error und yarn-error.log .

An unexpected error occurred: "ENOENT: no such file or directory, copyfile '/home/nieltg/.cache/yarn/v1/npm-core-js-2.5.7-f972608ff0cead68b841a16a932d0b183791814e/library/fn/date/now.js' -> '/mnt/c/Users/nieltg/Projects/React/React-16-Demo/node_modules/core-js/library/fn/date/now.js'".

Ich benutze Garn 1.7.0. Und ich kann das gleiche Verhalten bestätigen, das mir immer noch passiert.

Es ist völlig zufällig. Manchmal passiert es, manchmal nicht.

Das letzte, was ich erhielt, war:

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

Ich sehe diesen Fehler ziemlich häufig bei Yarn 1.9.2 unter Windows Subsystem für Linux.

Heute haben wir ähnliche Probleme mit kaputten Paketen auf Jenkins CI, wo die Pipeline parallel yarn install läuft. Es hat vor ein paar Tagen gut funktioniert.
Behoben mit yarn install --network-concurrency 1 (wie in einem Kommentar erwähnt ). Die Leistung verschlechterte sich nicht wesentlich: ~ 7 Sek. -> ~ 8 Sek.

Warum war das geschlossen? Es passiert immer noch:

Toms-MacBook-Pro-2:design-to-code tommedema$ yarn install
yarn install v1.9.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/Users/tommedema/projects/vg/design-to-code/packages/vgcli/node_modules/fs-extra'".
info If you think this is a bug, please open a bug report with the information provided in "/Users/tommedema/projects/vg/design-to-code/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Toms-MacBook-Pro-2:design-to-code tommedema$ yarn install --network-concurrency 1
yarn install v1.9.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 24.85s.

Beachten Sie, dass es in meinem Fall verschwunden ist, nachdem yarn remove fs-extra und yarn add fs-extra in zwei Paketen ausgeführt wurden, wodurch diese Abhängigkeit effektiv aktualisiert wurde.

Hallo, ich glaube ich habe etwas gefunden.

Ich habe mich mit einem Code beschäftigt, der Dateien in einem bestimmten Verzeichnis rekursiv mit fs und rxjs und festgestellt, dass es wahrscheinlich fehlschlägt, wenn ich nicht auf lstat warte lstat angerufen wird.

Ich habe ein einfaches NPM-Paket erstellt, Async-Dirtree-Test , um zu testen, ob Ihre Umgebung davon betroffen ist oder nicht. Ich verwende WSL und habe festgestellt, dass es wahrscheinlich fehlschlägt, wenn ein Verzeichnis mit vielen untergeordneten Verzeichnissen wie node_modules , selbst bei einer geringen Anzahl von Parallelitäten.

Nun, ich weiß immer noch nicht, ob dieses Problem WSL-spezifisch ist oder nicht. Im Moment kann ich es nicht in einer anderen Umgebung wie Linux, Mac usw. testen.

@nieltg Ich wollte eine Beobachtung teilen, die helfen könnte, einige der anderen zu formen. Ich verwende Docker CE in WSL und Docker für Windows als Host. Wenn ich also mit Docker in WSL arbeite, fühlt es sich nativ an, aber in Wirklichkeit arbeitet der Host nativ in der Windows-Welt (also lösen meine Docker-Dateien / c / foobar tatsächlich auf c: / foobar in der Docker-Engine). Dies ist unglaublich relevant, wenn ich Bindungen verwende (in meinem Container mounte ich meine lokalen Ordner so, dass sich / usr / src im Container letztendlich in c: / src / foobar befindet (obwohl meine Docker-Datei die Bindung als / c / anzeigen würde) src / foobar: / usr / src (siehe die automatische Übersetzung im Pfad?)

Diese Unterscheidung ist wichtig, da ich, wenn ich yarn install in einem dieser lokalen Ordner in meinem Container habe, dieselben Fehler erhalte, die ich direkt in der WSL mache (kein Docker beteiligt).

Auf der anderen Seite ... wenn ich nur mkdir /tmp/src && cp ./package.json /tmp/src/ && cd /tmp/src && yarn install , ist alles perfekt und ich kann nur mv /tmp/src/node_modules /c/src/foobar/ und ich bin gut, also ist das meine derzeitige Problemumgehung. Beachten Sie jedoch, dass /tmp als Docker-Speicher vorhanden ist (alle E / A-Vorgänge sehen für das Betriebssystem wie eine einzelne Datei aus, da es sich effektiv um eine Partition in einer Datei handelt).

Ich weiß, dass die Einbindung von Docker hier nicht ideal ist, aber es scheint darauf hinzudeuten, dass schnelle Dateihandles ein Problem sein könnten, da IO selbst dies nicht ist und anderen helfen könnte, dies zu umgehen.

... wurde abgelenkt und zu früh eingereicht. Wie auch immer, mein Gehirn ist im Moment woanders, aber ich werde später zurückkommen und sehen, ob ich mit Ihrem Ansatz und Docker einen Test entwickeln kann, um weitere Schlussfolgerungen zu ziehen.

WIEDER ÖFFNEN

Vor kurzem wurde bei der Ausführung eines CI-Builds in Azure Devops (ehemals Visual Studio Team Services) die gleiche Art von Fehler bei Verwendung von Garn 1.10.1 festgestellt.

Die tatsächliche Abhängigkeit, die fehlschlägt, scheint am besten zufällig zu sein, aber yarn install fällt zeitweise mit dem Fehler ENOENT: no such file or directory, open '/usr/local/share/.cache/yarn........ . Einmal funktioniert der Build, das nächste Mal schlägt er fehl.

Die Problemumgehung von yarn install --network-concurrency 1 scheint für uns zu funktionieren.

@ Marclev78 gleicher Fehler, aber yarn install --network-concurrency 1 scheint bei mir nicht zu funktionieren

@ Marclev78 hier dasselbe, Garn 1.10.1 in Azure Devops verwenden und den Fehler erhalten:

Error: https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz: ENOENT: no such file or directory, utime 'C:\Users\grpsshagent\AppData\Local\Yarn\Cache\v1\npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636\fn\string\pad-left.js'

Vor Ort funktioniert alles wie erwartet.

Ich bin hier, um einfach zu sagen, dass auch ich diesen Fehler sehe.

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

Leider denke ich, dass ich das Garn für meine globalen Knoten-Binärdateien aufgeben und zu npm zurückkehren muss, bis dies behoben ist.

Leider hat dieses Problem kürzlich auch unsere CI-Builds geplagt.

@rainabba Vorschlag funktionierte für mich auf WSL

Ich denke, dass sich Schreib- und Leseoperationen auch unterschiedlich verhalten. Selbst bei meinen Hacks werden beim Aufrufen von fs.writeFile des Knotens häufig Fehler angezeigt (allerdings mit Bluebird Promisify umwickelt). In jedem einzelnen Fall kann ich sofort nach Erhalt des Schreibfehlers bestätigen, dass die Datei vorhanden ist.

Ich sende eine Zeichenfolge (XML-Dateiinhalt) an fs.writeFile (), die letztendlich Folgendes aufruft, bin mir jedoch nicht sicher, ob ich bereit bin, die Herausforderung anzunehmen, die zum Einrichten eines benutzerdefinierten Builds mit zusätzlichem Debugging erforderlich ist Ausgabe von diesem C ++ - Projekt, damit ich genau bestätigen kann, wo sich das Recht tatsächlich nach Knoten oder diesem C ++ - Modul anfühlt.

Fazit ist, dass die Schreibvorgänge nicht fehlschlagen, aber der Knoten glaubt, dass dies der Fall ist. Das für mich sinnvolle Szenario ist, dass das c + plus-Modul erfolgreich ist, aber intern nach der Datei sucht und fehlschlägt. Dann fühlen sich die Berichte nicht zurück zum Knoten und dann erfolgt das eigentliche Schreiben, so dass es dort ist, wenn ich nach der Datei suche, und der Fehler keinen Sinn ergibt.

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

@bestander eine Möglichkeit, dieses Problem wieder zu

Dies wird weiterhin mit Garn 1.12 und Azure Pipelines bestätigt.

Vielen Dank für die Bestätigung aller.
Es gibt anscheinend mehrere Gründe für diesen Fehler.
Ich werde das Problem erneut öffnen. Die Community-Hilfe zum Debuggen ist jedoch erforderlich.

passiert auch mit Garn 1.11, aber nicht mit 1.10

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

Wenn ja, gibt es einige gute Reproarbeiten

Ich bin auch von diesem Problem betroffen.

Windows 10 / WSL

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

@limonte WSL hatte eine Zeit lang den Fehler, dass beim Ausführen von npm install / yarn install zufällig ein ähnlicher Fehler ausgegeben wurde . Es geschah, als viele Dateien gleichzeitig auf die Festplatte kopiert wurden. Stellen Sie sicher, dass Sie die neueste Windows-Version (1809 oder höher) verwenden, da diese möglicherweise nicht durch das Garn selbst verursacht wird.

Wir sehen auch das Problem von Extracting tar content of undefined .

error https://registry.yarnpkg.com/eslint/-/eslint-4.19.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat '/tmp/yarncache.KTKNZ/v4/npm-eslint-4.19.1-32d1d653e1d90408854bfb296f076ec7e186a300/node_modules/eslint/lib/rules/no-compare-neg-zero.js'"

Bisher haben wir dies durch die Verwendung von nur einer gleichzeitigen Netzwerkverbindung mit der Option --network-concurrency 1 gemildert. Dies ist jedoch eher eine vorübergehende Lösung.

Ich kann das Problem auch bei node:11.5.0-alpine .

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

Ich bemerkte, dass die Probleme mit der Verknüpfung mit der Git-Repository-Version von Paketen zu tun zu haben schienen.

Reproduzieren

package.json

{
  "dependencies": {
    "react-navigation-core": "https://github.com/react-navigation/react-navigation-core",
    "react-navigation-hooks": "https://github.com/react-navigation/react-navigation-hooks"
  }
}

rm -rf node_modules && yarn cache clean && yarn

Problemumgehung

Das Setzen von network-concurrency 1 behebt das Problem jedes Mal für mich.

Das Ausführen von npm install funktioniert ebenfalls.

Anmerkungen

Das Entfernen eines Pakets aus der Abhängigkeitsliste verursacht weder den Fehler noch die Verwendung der veröffentlichten npm-Versionen dieser Pakete.

Es scheint jedes Mal einen anderen Fehler zu werfen. Es scheint zufällig mit verschiedenen Dateien und mit leicht unterschiedlichen Fehlern zu geschehen.

error https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod  '/home/cameron/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/library/modules/es6.reflect.apply.js'"

Variationen

• ENOENT: no such file or directory, chmod
• ENOENT: no such file or directory, stat
• ENOENT: no such file or directory, open
• EEXIST: file already exists, mkdir

Sonstige Mitteilungen

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

In der Tat habe ich gerade versucht, mit Ihrer package.json zu reproduzieren, und beim ersten Versuch ist ein Fehler aufgetreten.

Auf welcher Ebene interagiert das WSL-Dateisystem mit den bereits vorhandenen NTFS-Fs?

Sehen Sie diesen Fehler in einem gemounteten Laufwerk (/ c oder / mnt / c für allgemeine Beispiele) oder außerhalb eines dieser Mounts? Möchten Sie eine Alternative testen (z. B. ~ /.) Und einen Unterschied melden?

Meine Intuition nervt mich, aber ich kann Probleme mit meinen Docker-Erfahrungen verwechseln, und ich muss dies unabhängig überprüfen.

[2/4] Pakete holen ...
Fehler https://registry.yarnpkg.com/smartwrap/-/smartwrap-1.0.10.tgz : Das Extrahieren des Tar-Inhalts von undefined ist fehlgeschlagen. Die Datei scheint co zu sein
rrupt: "ENOENT: Keine solche Datei oder kein solches Verzeichnis. Öffnen Sie" C: \ Benutzer \ Administrator \ AppData \ Local \ Yarn \ Cache \ v4 \ npm-smartwrap-1.0.10-873ef350d "
4ee1262fed4a80a55634d86ae1faf48 \ node_modules \ smartwrap \ ejq '"
info Unter https://yarnpkg.com/de/docs/cli/global finden Sie eine Dokumentation zu diesem Befehl.

Sehen Sie diesen Fehler in einem gemounteten Laufwerk (/ c oder / mnt / c für allgemeine Beispiele) oder außerhalb eines dieser Mounts? Möchten Sie eine Alternative testen (z. B. ~ /.) Und einen Unterschied melden?

Gibt es einen durchweg reproduzierbaren Fall, in dem dies geschieht? Es war ziemlich zufällig für mich, aber ich mache alle meine yarn add -ing auf einem gemounteten Laufwerk und dies kommt häufig vor.

Ich konnte https://github.com/yarnpkg/yarn/issues/2629#issuecomment -451638917 sowohl in einem gemounteten Laufwerk als auch in ~ reproduzieren.

Ich habe auch versucht, https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 zu reproduzieren, aber es gelang mir immer wieder nicht, das letzte Paket abzurufen, von dem ich mir ziemlich sicher bin, dass es nichts damit zu tun hat.

Ich hatte das gleiche Problem in den letzten Stunden. Garn konnte nach dem Zufallsprinzip verschiedene Pakete nicht installieren, was die oben genannten Fehler zeigte.

Ich habe versucht, den Garncache zurückzusetzen und mit Netzwerk-Parallelität 1 neu zu installieren und auszuführen, was jedoch nicht funktioniert hat.

Was das Problem für mich löste, war der Wechsel zu einem anderen Netzwerk (ich habe nur meinen Telefon-AP anstelle von WiFi verwendet) und alles funktionierte wie von Zauberhand.

Ich habe die Vermutung, dass dieses Problem mit einer fehlerhaften Wiederherstellung einiger sehr spezifischer Netzwerkfehler zusammenhängt. Werde später darauf eingehen.

Ich kann den vorherigen Kommentar bestätigen. Das Setzen von network-concurrency hilft nicht. Der Wechsel zum Telefon-Hotspot hat das Problem für mich behoben. Meine Umgebung: Windows 10 (Linux-Subsystem - Ubuntu)

Ich bin in der WSL und habe dieses Problem mit dem Paket geo-tz , das eine (etwas merkwürdige) tief verschachtelte Ordnerstruktur aufweist. Ich habe einige --network-timeout und --network-concurrency Dinge ausprobiert, bin aber nicht weitergekommen. Wenn ich jedoch lange Pfade unter Windows aktiviert habe (siehe diesen SuperUser-Beitrag ), funktioniert dies Bearbeiten es sieht so aus, als hätte ich zu früh gesprochen. Es hat funktioniert und das Verknüpfen von Abhängigkeiten ist schneller, aber jetzt wird wieder der gleiche Fehler angezeigt.

Immer noch CI brechen ....

Wir haben das gleiche Problem mit Yarn 1.13.0, das auf einem Debian Linux-Computer ausgeführt wird, der als Jenkins-Slave-Knoten dient. Beachten Sie, dass wir einen lokalen Garn-Repository-Server haben, sodass während des Builds keine (oder nur sehr wenige) physischen Downloads von Repo-Servern im öffentlichen Internet stattfinden.

yarn install v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://sqrep01.rsint.net:4873/lodash/-/lodash-4.17.10.tgz: ENOENT: no such file or directory, open '/home/jenkins/.cache/yarn/v4/npm-lodash-4.17.10-1b7793cf7259ea38fb3661d4d38b3260af8ae4e7/node_modules/lodash/.yarn-tarball.tgz'".

Die eigentliche Datei ist sowohl auf unserem Repo-Server als auch im Dateisystem vorhanden.
Wenn wir den Build erneut starten, ist der Build möglicherweise erfolgreich oder schlägt mit einer anderen (zufälligen) Datei fehl.
Wir haben die Standardeinstellung für die Netzwerk-Parallelität nicht geändert.

Ditto - Dies ist immer noch ein Problem, selbst in 1.14

Arguments: 
  /home/jeff/n/bin/node /usr/share/yarn/bin/yarn.js install

PATH: 
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Windows/System32/OpenSSH:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Program Files/Git/cmd:/mnt/c/Users/jkono/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/jkono/AppData/Local/hyper/app-2.1.2/resources/bin:/mnt/c/Users/jkono/AppData/Local/Programs/Microsoft VS Code/bin:/home/jeff/n/bin

Yarn version: 
  1.14.0

Node version: 
  10.15.1

Platform: 
  linux x64

Trace: 
  Error: ENOENT: no such file or directory, scandir '/mnt/c/Users/jkono/dev/PROJECT/node_modules/@storybook/addon-links/src'

Ebenfalls:

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

Das ist ziemlich nervig, wir sehen das täglich auf lokalen und ci-Maschinen.

Die Bestätigung, dass dies auch für uns die ganze Zeit in CI geschieht

Hallo, ich bestätige, dass dieses Problem auf unserem CI auftritt.
Dies steht im Einklang mit dem Problem.

Fehler https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz : Das Extrahieren des Tar-Inhalts von undefined ist fehlgeschlagen. Die Datei scheint beschädigt zu sein: "ENOENT: Keine solche Datei oder kein solches Verzeichnis. chmod '/usr/local/share/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/es7/regexp.js' "
info Dokumentation zu diesem Befehl finden Sie unter https://yarnpkg.com/de/docs/cli/install .

Das gleiche Problem trat heute bei einem unserer Open-Source-Projekte auf.

Sie können hier einen fehlerhaften Build sehen:
https://travis-ci.com/quid/refraction/builds/103692106

Und eine, die hier erfolgreich ist (mit --network-concurrency 1 ):
https://travis-ci.com/quid/refraction/builds/103693682

Ich hoffe, es kann helfen, das Problem zu diagnostizieren!

Der Quellcode des Repositorys lautet:
https://github.com/quid/refraction

Vielleicht hilft das jemandem:
Auf unserem Jenkins CI bestand das Problem darin, dass Jenkins parallele Builds für unsere Apps auslöst, was bedeutet, dass zwei (oder mehr) Shell-Skripte gleichzeitig die "Garninstallation" ausgelöst haben, wobei einer der Build-Prozesse den Garn-Cache weiter entfernt hat vollständig_ (mit "Garn Cache sauber") vor dem Start von "Garninstallation". Dies war natürlich ein fatales Problem für die anderen Garnprozesse.
Wir haben dann die Cache-Reinigung entfernt und den Garnbefehl in geändert
yarn install --verbose --prefer-offline --mutex file:/tmp/.yarn-mutex --network-concurrency 1
(_-- verbose_ ist nicht wirklich notwendig) und eingefügt
child-concurrency 1
in .yarnrc.
Jetzt, da die parallelen Aufbauten ausgelöst werden, hat das Garn erkannt, dass ein anderer Garnprozess aktiv ist, und gewartet, bis es beendet ist. Dies löste die Probleme "keine solche Datei" auf unserem CI.

Ich erhalte dieses Problem auf meinem lokalen Computer, wenn ich eine Paketreferenz mit diesem Format verwende:

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

Bemerkenswerte Eigenschaften: privates Paket, Github-URL, Git + https, getaggte Git-Referenz

Schritte, die sich für mich reproduzieren:

1. Schiefer reinigen: Entfernen Sie alle derartigen Referenzen und führen Sie yarn install . Es funktioniert gut.
2. Fügen Sie alle diese Referenzen wieder zu meinem package.json und führen Sie yarn install erneut aus. Dies funktioniert auch beim ersten Durchlauf, nachdem diese Referenzen wieder hinzugefügt wurden.
3. Das weitere Ausführen von yarn install danach funktioniert, solange keine Änderungen vorgenommen wurden.
4. Ändern Sie jedoch alle Pakete und führen Sie yarn install und ich erhalte die Fehlermeldung.
5. Wenn ich dann alle diese Pakete entferne und yarn install ausführe, wird der Fehler nicht angezeigt. Das bringt uns zurück zu Schritt 1.

Fehler sieht so aus:

error An unexpected error occurred: "ENOENT: no such file or directory, open '/Users/jeremy/Library/Caches/Yarn/v4/npm-connect-js-adapter-tls-3.2.2-0c97726d92c21183a7fb7334344eb5047e8bc158/node_modules/connect-js-adapter-tls/.yarn-metadata.json'".

Wenn ich alle Git-Tag-Referenzen entferne, beobachte ich dasselbe Verhalten. Ich glaube, das kann nicht das Problem sein.
dh

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

Das Ausführen von npm install ebenfalls zu einem Fehler:

npm ERR! premature close

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/jeremy/.npm/_logs/2019-03-20T04_38_38_739Z-debug.log

npm-debug.log: https://gist.github.com/jeremyjs/e97381b16f46124ff7a9bd75ad79fd62

Als Folge habe ich eine Problemumgehung verwendet, um ein package.json -Skript zu erstellen, um diese Pakete vor der Installation aus meinem Cache zu bereinigen:

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

Gibt es noch eine Idee, was dieses Problem sein könnte?
In unserem Fall führen wir yarn install als Teil unseres CI (innerhalb des Docker-Containers) aus und erhalten dieselben Fehler. Wir haben yarn cache clean ausprobiert

Ich bin mir nicht sicher, was ich an diesem Punkt noch versuchen soll, und es stoppt unsere Builds. 😬

Dan, hast du versucht, mit --network-concurrency 1 zu laufen? Ich habe eine ähnliche
Szenario und das löste mein Problem.
Am 2. April 2019, 22:17 Uhr, schrieb "Dan Van Brunt" [email protected] :

Gibt es noch eine Idee, was dieses Problem sein könnte?
In unserem Fall führen wir die Garninstallation als Teil unseres CI (Inside Docker) aus
Container) und erhalten die gleichen Fehler. Wir haben versucht, den Garncache sauber zu halten

Ich bin mir nicht sicher, was ich an diesem Punkt noch versuchen soll, und es stoppt unsere Builds. 😬

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-479283590 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AFU4O1iKA-HBd62Hema1ETmuUlMro_GLks5vdAEOgaJpZM4L3JbX
.

@tevaum , der das Problem auch für unser CI gelöst hat. Es hat auch unsere Builds erheblich verlangsamt. So schrecklich und doch nur umgehbar.

Ja. Es ist ein schlechter Nachteil. Sie können es mit kleinen Zahlen wie 2 oder 4 versuchen
wird etwas schneller sein, aber für mich war der einzige Wert, der funktionierte, 1: /

Also müssen wir warten, bis der eigentliche Fix glücklich ist;)
Am 4. April 2019 00:26 schrieb "kunokdev" [email protected] :

@tevaum https://github.com/tevaum , der das Problem auch für unser CI gelöst hat.
Es hat auch unsere Builds erheblich verlangsamt. So schrecklich.

- -
Sie erhalten dies, weil Sie erwähnt wurden.

Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-479735791 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AFU4O1a9lHn41K0eEQT9zZZzOoATiT61ks5vdXD8gaJpZM4L3JbX
.

Wird dies jemals behoben werden? Dies hat Garn bei mehr als einem meiner Projekte unbrauchbar gemacht

Bitte verwenden Sie die hier dokumentierte Mutex-Option: https://yarnpkg.com/de/docs/cli/#toc -concurrency-and-mutex

Die Cache-Nutzung von Yarn ist nicht sicher für mehrere Prozesse, und dies ist der Grund für solche Fehler.

Alternativ können Sie einen Cache-Ordner pro Prozess mithilfe der hier dokumentierten Option --cache-folder festlegen: https://yarnpkg.com/de/docs/cli/cache#change -the-cache-path-for-yarn-

Der Nachteil der Verwendung der Mutex-Option besteht darin, dass nur eine Garninstanz in der gesamten Maschine vorhanden ist (andere warten, bis der aktive Prozess beendet ist), was bedeutet, dass bei CI-Jobs überhaupt keine Parallelität besteht.

Der Nachteil eines Cache-Ordners pro Prozess ist eine erhöhte E / A und ein gewisser Verlust an Potenzial aufgrund einer geringeren Wiederverwendung des Caches.

Die ideale Lösung wäre die Implementierung einer prozesssicheren Cache-Implementierung, die nicht einfach ist, da in Node keine Funktionen zum Sperren von Dateien vorhanden sind (die einzige zuverlässige Option scheint das Erstellen von Mutex-Verzeichnissen zu sein). Das zweitbeste ist die Verwendung eines Cache-Ordners pro parallelem Arm, der die gleichzeitige Verwendung und Wiederverwendung des Caches im selben Arm ermöglicht.

Ich denke nicht, dass es das Mutex-Zeug ist. Ich und einige andere führen während der Docker-Image-Erstellungsphase jeweils ein einzelnes Garn aus - in meinem Fall sind es nur RUN yarn install in einer Docker-Datei. Das macht es ziemlich sicher, dass in dieser Umgebung keine anderen Prozesse gleichzeitig ausgeführt werden.

Schauen Sie sich dieses Beispiel für minimale Reproduktion an (zumindest für mein OSX):

728 22:49:55 iMac ~/tmp/ynse$ ls
Dockerfile  package.json
729 22:49:58 iMac ~/tmp/ynse$ cat Dockerfile
FROM node
ADD . /app
WORKDIR /app
RUN yarn

730 22:50:00 iMac ~/tmp/ynse$ cat package.json
{
  "dependencies": {
    "react-navigation-core": "https://github.com/react-navigation/react-navigation-core",
    "react-navigation-hooks": "https://github.com/react-navigation/react-navigation-hooks"
  }
}
731 22:50:03 iMac ~/tmp/ynse$ docker build -t yt .
Sending build context to Docker daemon  15.87kB
Step 1/4 : FROM node
 ---> 39337023f8d4
Step 2/4 : ADD . /app
 ---> aa86b2d7f191
Step 3/4 : WORKDIR /app
 ---> Running in 83baa8603935
Removing intermediate container 83baa8603935
 ---> 80741f170292
Step 4/4 : RUN yarn
 ---> Running in 0718118bdcd6
yarn install v1.3.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
error An unexpected error occurred: "https://registry.yarnpkg.com/lodash/-/lodash-4.17.11.tgz: EEXIST: file already exists, mkdir '/usr/local/share/.cache/yarn/v1/npm-lodash-4.17.11-b39ea6229ef607ecd89e2c8df12536891cac9b8d'".
^C
732 22:50:23 iMac ~/tmp/ynse$

@nopik - Yarn 1.3.2 ist sehr alt und es gab zahlreiche Korrekturen nach dieser Version. Haben Sie versucht, eine der neuesten Versionen von Docker zu verwenden?

In der Tat war dieses Knotenbild ziemlich alt. Hier ist eine neue, die vor einigen Minuten vom Dockerhub- Knoten heruntergeladen wurde

Sending build context to Docker daemon  15.87kB
Step 1/4 : FROM node
 ---> a9c1445cbd52
Step 2/4 : ADD . /app
 ---> Using cache
 ---> 26ed37136c09
Step 3/4 : WORKDIR /app
 ---> Using cache
 ---> b2339e7d25af
Step 4/4 : RUN yarn
 ---> Running in cdbdfd9c373c
yarn install v1.15.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/v4/npm-lodash-4.17.11-b39ea6229ef607ecd89e2c8df12536891cac9b8d/node_modules/lodash'".
info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

@BYK Haben Sie versucht, diesen Docker selbst zu bauen?

Ich werde es in ein paar Tagen versuchen, sobald ich an meinem Computer bin (jetzt auf dem Handy). Sieht sehr seltsam aus, aber das Verzeichnis ist konsistent. Ich werde versuchen zu sehen, was los ist, danke für den Repro-Fall.

@nopik - Bei näherer Betrachtung des Protokolls werden tatsächlich mehrere

@BYK Ich sehe, dass eines dieser Pakete "scripts": { "build": "yarn babel --out-dir dist && del-cli 'dist/**/__tests__' && yarn tsc --emitDeclarationOnly", "prepare": "yarn build" } das andere andere Skripte, aber immer noch Garn in Vorbereitung läuft. Werden diese während der Installation von Garn gestartet?

@Nopik - glaube nicht, dass dies das Problem verursachen würde, da sie einfach Skripte yarn install Instanaces auslöst.

Ich bin damit einverstanden, dass wahrscheinlich mehrere Garn gleichzeitig laufen. Das Problem ist, dass dies bei einem einzelnen CLI-Aufruf von yarn geschieht. Für die Reproduktion ist kein Docker erforderlich.

Meine zugegebenermaßen unterinformierte Theorie besagt, dass dies etwas mit dem Vorbereitungsschritt zu tun hat und dass Garn möglicherweise eine zusätzliche Instanz zum "Erstellen" von Git-Paketen startet. Ich wette insbesondere, dass zwei Abhängigkeiten von einem gemeinsamen Paket abhängen, das ebenfalls erstellt werden muss. Yarn versucht, intelligent zu sein und jedes einzelne Paket parallel zu erstellen, schlägt jedoch fehl, wenn versucht wird, zwei Pakete am selben Cache-Speicherort zu erstellen.

In unserem Fall haben wir nicht mehrere Garninstanzen.

Unser System läuft in einem eigenen Docker-Image. Es hat einzelne _ Garninstallation _. Es hat sich plötzlich schlecht benommen und jetzt können wir nicht mehr arbeiten, ohne dass die Netzwerk-Parallelität auf 1 gesetzt ist.
Sofern sich das Garn selbst nicht über Nacht verändert hat, sehe ich kein anderes Problem als das, dass das Garn selbst Probleme mit bestimmten Bedingungen verursacht.

Wenn Sie versuchen, dieses Problem mit --mutex file oder sogar --mutex network zu lösen, werden Sie (wahrscheinlich) unweigerlich auf diesen Fehler stoßen: https://github.com/yarnpkg/yarn/issues/6650 (seit 6 Monaten offen / ungelöst) 😢

Das heißt, wenn Sie yarn install einmal ausgeführt haben, können Sie nie wieder einen Garnbefehl ausführen, obwohl dies erfolgreich sein wird

Dan, hast du versucht, mit --network-concurrency 1 zu laufen? Ich habe ein ähnliches Szenario und das hat mein Problem gelöst.

@tevaum - Das war genau das Problem. VIELEN DANK!
Ich hatte ein Skript, von dem ich nicht dachte, dass es jemals mehr als eine Instanz ausführen würde, aber es war. 🤦‍♂️

@tevaum auch für mich gelöst. Vielen Dank.

Wenn Sie versuchen, dieses Problem mit --mutex-Datei oder sogar --mutex-Netzwerk zu lösen, werden Sie (wahrscheinlich) unweigerlich auf diesen Fehler # 6650 stoßen (offen / ungelöst seit 6 Monaten).

@sarink - Ich bin auch auf den Mutex-Optionsfehler

yarn sagt, dass alles in Ordnung ist.

PS C:\Users\chtacklind\Desktop\git\Project> yarn --verbose
yarn install v1.10.1
verbose 0.282 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.284 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.285 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.286 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.288 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.289 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.29 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.npmrc".
verbose 0.291 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.npmrc".
verbose 0.295 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.297 Checking for configuration file "C:\\Users\\.npmrc".
verbose 0.3 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.301 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.302 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.309 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.312 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.317 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.318 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.319 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.yarnrc".
verbose 0.326 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.yarnrc".
verbose 0.327 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.333 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.336 Checking for configuration file "C:\\Users\\.yarnrc".
verbose 0.346 current time: 2019-05-12T11:56:12.800Z
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.33s.

Das Ausführen von yarn --check versucht zu erstellen, schlägt jedoch immer fehl.

Manchmal mit verstümmelten Fehlermeldungen am Ende:

PS C:\Users\chtacklind\Desktop\git\Project> yarn --check-files --network-concurrency 1 --mutex file:C:/.yarn-mutex --verbose
yarn install v1.10.1
verbose 0.286 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.288 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.289 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.29 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.291 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.292 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.293 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.npmrc".
verbose 0.294 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.npmrc".
verbose 0.295 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.296 Checking for configuration file "C:\\Users\\.npmrc".
verbose 0.302 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.304 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.305 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.306 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.307 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.308 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.311 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.313 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.yarnrc".
verbose 0.314 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.yarnrc".
verbose 0.315 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.316 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.317 Checking for configuration file "C:\\Users\\.yarnrc".
verbose 0.32 current time: 2019-05-12T11:56:20.033Z
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 2.344 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.npmrc".
verbose 2.344 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 2.345 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 2.345 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 2.348 Checking for configuration file "C:\\Users\\.npmrc".
verbose 2.348 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.yarnrc".
verbose 2.349 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.35 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.351 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 2.352 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.yarnrc".
verbose 2.353 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
verbose 2.358 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.yarnrc".
verbose 2.359 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
verbose 2.36 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.yarnrc".
verbose 2.361 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.yarnrc".
verbose 2.362 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.yarnrc".
verbose 2.363 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.364 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.366 Checking for configuration file "C:\\Users\\.yarnrc".
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 2.541 Performing "GET" request to "https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz".
verbose 3.263 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.264 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.265 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 3.266 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.268 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 3.27 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 3.271 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 3.273 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 3.278 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 3.279 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 3.28 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.281 Checking for configuration file "C:\\Users\\.npmrc".
verbose 3.283 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.285 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 5.007 Error: https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\lib\\tsserver.js'"nd\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc
    at MessageError.ExtendableBuiltin (C:\Program Files (x86)\Yarn\lib\cli.js:243:66)
    at new MessageError (C:\Program Files (x86)\Yarn\lib\cli.js:272:123)pData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
    at Extract.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:56849:14)a\\Local\\Yarn\\Cache\\v2\\.yarnrc".
    at Extract.emit (events.js:194:15)on file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
    at Extract.module.exports.Extract.destroy (C:\Program Files (x86)\Yarn\lib\cli.js:131115:17)nrc".
    at onunlock (C:\Program Files (x86)\Yarn\lib\cli.js:130992:26)nd\\AppData\\Local\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:43373:25rs\\chtacklind\\AppData\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:43339:23rs\\chtacklind\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:56799:13acklind\\.yarnrc".
    at FSReqWrap.oncomplete (fs.js:153:21)ile "C:\\Users\\.yarnrc".
error https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\lib\\tsserver.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\Users\chtacklind\Desktop\git\Project>

Manchmal mit unterschiedlichen Fehlern:

...
[2/4] Fetching packages...
verbose 2.635 Performing "GET" request to "https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz".
verbose 3.465 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.466 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.467 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 3.468 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.469 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 3.47 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 3.471 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 3.473 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 3.474 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 3.48 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 3.481 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.482 Checking for configuration file "C:\\Users\\.npmrc".
verbose 3.483 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.485 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.486 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.49 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 3.492 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.493 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
verbose 3.494 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.yarnrc".
verbose 3.495 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
verbose 3.496 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.yarnrc".
verbose 3.497 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.yarnrc".
verbose 3.501 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.yarnrc".
verbose 3.503 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.504 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.505 Checking for configuration file "C:\\Users\\.yarnrc".
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 4.608 Error: EPERM: operation not permitted, unlink 'C:\Users\chtacklind\AppData\Local\Yarn\Cache\v2\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\.yarn-tarball.tgz'
error An unexpected error occurred: "EPERM: operation not permitted, unlink 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\.yarn-tarball.tgz'".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\chtacklind\\Desktop\\git\\Project\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\Users\chtacklind\Desktop\git\Project>

Beachten Sie, dass zwei Garnprozesse ausgeführt werden, obwohl --mutex angegeben ist.

Bemerkenswert ist, dass dieses Paket eine Git-Abhängigkeit hat, die einen Schritt tsc prepare , der ausgeführt werden muss. Dieses Paket hat auch eine Git-Abhängigkeit, die den gleichen Prozess erfordert. Es ist klar, dass Garn versucht, dasselbe Paket an denselben Ort auszupacken, und wir bekommen eine Rennbedingung.

Warum läuft Garn mehrere Male, auch wenn es nicht angewiesen wird?

Als Update scheint die Verwendung von yarn install --network-concurrency 1 --mutex network jedes Mal zu funktionieren, wenn die Verwendung der einen oder anderen Option nur teilweise erfolgreich ist.

Wie lautet die Lösung für dieses Problem?
Ich benutze Garn 1.16 unter Ubuntu Linux 18.04
Und ich bekomme immer noch diese Fehlermeldung:

Fehler Ein unerwarteter Fehler ist aufgetreten: "ENOENT: Keine solche Datei oder kein solches Verzeichnis, lstat '/ home / user / workspace / project / packages / components / node_modules / source-map-support'".

Mein Befehl lautet:

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

Und ich bekomme diesen Fehler alle zwei Male: ((
PS: Ich arbeite in Monorepo, also habe ich Garnarbeitsbereiche aktiviert
PPS:
Ich habe es noch einmal überprüft
Das Hinzufügen einer --mutex-Datei oder eines --mutex-Netzwerks hilft nicht.

Die einzige Lösung, die ich bestätigen kann, ist das Einfügen eines Skripts

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

:(

Fwiw, ich konnte zu npm wechseln, indem ich nur yarn durch npm fand / ersetzte und mit synp yarn.lock in package-lock.json konvertierte und npm install . Ich dachte, das wäre ein schmerzhafter Prozess, aber npm hat sich sehr weiterentwickelt und ich habe nur etwa 30 Minuten gebraucht und jetzt funktioniert es einfach überall

Das Problem hier scheint zu sein, dass es kein wirklich einfaches Beispiel dafür gibt, was falsch läuft. Ich habe ein triviales package.json gepostet, das das Problem für mich zuverlässig reproduziert, aber die enthaltenen Pakete sind etwas kompliziert.

Ich vermute, dass das Problem darin besteht, dass Sie einen Abhängigkeitsbaum mit gemeinsam genutzten "Blättern" / Tipps haben, deren Kompilieren / Installieren (Vorbereiten) einige Zeit in Anspruch nimmt, und Garn versucht, dies zweimal gleichzeitig vorzubereiten. Jede Instanz wird an einem gemeinsam genutzten vorhersehbaren Speicherort "vorbereitet" und sie können nicht beide gleichzeitig an denselben Speicherort "schreiben" (einer löscht eine Datei, während der andere erwartet, dass sie noch vorhanden ist).

Ich wollte einige einfache Proof-of-Concept-Pakete mit aufgeblasenen "Vorbereitungs" -Schritten erstellen, um diese Theorie zu testen, hatte aber keine Zeit dafür. Vielleicht kann jemand anderes diese Theorie testen, bevor ich dazu komme?

Dies geschieht, wenn mehrere Garninstanzen gleichzeitig ausgeführt werden. Sie können die hier dokumentierte Option --mutex : https://yarnpkg.com/de/docs/cli/#toc -concurrency-and-mutex

@ BYK Es scheint, dass es viele Fälle gibt, in denen dies nicht das Problem ist. Andere haben sogar angegeben, dass diese Option andere Probleme für sie verursacht.

@cinderblock # 6650 scheint ein --ignore-scripts vermieden werden, was ebenfalls empfohlen wird.

Wenn Sie andere Leads haben, teilen Sie diese bitte mit, damit jemand hoffentlich mehr Zeit für das Debuggen aufwenden kann.

@BYK Ich habe noch niemanden gesehen, der absichtlich yarn install in einem install -Skript verwendet hat. Haben Sie dieses triviale package.json , das dieses Problem verursacht? Zugegeben, es ist etwas in den abhängigen Paketen, das diesen Fehler hervorruft, und vielleicht haben sie ein vergrabenes install , auf das Sie sich beziehen. Allerdings funktioniert package.json gut mit npm ...

Wie / wo wird --ignore-scripts empfohlen? Viele Pakete basieren auf Skripten nach der Installation, um zu funktionieren.

Wie / wo werden --ignore-scripts empfohlen? Viele Pakete basieren auf Skripten nach der Installation, um zu funktionieren.

Oh, ich habe es hier nur empfohlen und ich denke, viele Mitglieder von Yarn haben darüber gesprochen. 😀 Die meisten Pakete sind in Ordnung, aber es gibt tatsächlich einige Pakete, die auf Scrpits nach der Installation basieren.

Haben Sie dieses triviale package.json gesehen?

Ja, aber selbst eine "triviale" package.json -Datei kann einem sehr großen Abhängigkeitsbaum nachgeben. Wenn Sie also sagen, dass sie trivial ist, ändert sich nicht viel, außer dass ich sie auf eine der folgenden Arten interpretiere:

• Garn ist zu beschissen, so dass es nicht einmal mit dieser _trivial_ package.json-Datei umgehen kann
• Dieses Problem kann mit einer _trivial_ package.json-Datei reproduziert werden, Sie können es jedoch immer noch nicht beheben

wo keines davon hilfreich ist, neige ich dazu, Ihren Kommentar zu ignorieren.

Damit das eigentliche Problem mit dem Mutex ausgeführt werden kann, müssen alle Garninstanzen mit dem Flag --mutex aufgerufen werden. Der beste Weg, um festzustellen, ob das Problem dadurch behoben wird, besteht darin, --install.mutex network zu Ihrem hinzuzufügen .yarnrc Datei (siehe https://yarnpkg.com/de/docs/yarnrc#toc-cli-arguments). Dies kann jedoch zu einem Deadlock führen, wenn die Erstinstallation eine weitere Installation auslöst, bei der die zweite Installation auf den Abschluss der Hauptinstallation wartet und die Hauptinstallation auf diesem vom Skript aufgerufenen Garn zum Abschluss blockiert wird, daher weiß ich das nicht wirklich Sie wissen, wie Sie dieses Problem beheben können, außer ein thread- / prozesssicheres Cache-System zu implementieren, das mit den von node bereitgestellten Sperrprimitiven nahezu unmöglich ist. Das Nächste scheint dieses richtige Paket zu sein, aber keiner von uns hatte die Zeit, es auszuprobieren. Ich kann Ihnen helfen, wenn Sie daran interessiert sind, dies in den Cache-Schreib- / Lesecode zu implementieren.

@BYK Oh, ich entschuldige mich, wenn ich so

Verzeihen Sie meine Beharrlichkeit, aber ich sehe immer noch nicht, wie die Mutex-Option eine Lösung ist. Ich habe versucht, mit Mutex zu laufen, und es lief immer noch gleichzeitig Garn. Vielleicht habe ich bei meinen Tests einen Fehler gemacht? Ich hatte erwartet, dass das Ausführen von yarn --mutex ... diese Option an untergeordnete Instanzen weitergeben würde (wie beispielsweise make ). Ich habe auch Ihren Vorschlag ausprobiert, --install.mutex network zu meiner .yarnrc -Datei ohne Erfolg hinzuzufügen (gleiche Fehler). --verbose bestätigt, dass die Optionen geladen werden.

Vielleicht könnten wir dies aus einer anderen Richtung erreichen? Was macht Garn, was npm nicht macht? Warum hat npm nicht das gleiche Problem?

@BYK , die Verwendung des mutex ist völlig inakzeptabel, da es einen zusätzlichen Garnfehler gibt, der Sie daran hindert, jemals einen anderen Garnbefehl auszuführen. Dies ist so, als ob Ihre Lösung für "Ich habe meine Schlüssel gesperrt" Mein Auto "war", keine Sorge, daran habe ich gedacht! Verwenden Sie einfach dieses praktische Werkzeug, um alle Ihre Fenster und Türschlösser einzuschlagen, jetzt können Sie Ihr Auto nie wieder abschließen! " 🙄

Trivial package.json oder nicht, dies ist ein großes Problem ohne Lösung oder Problemumgehung, das Garn für viele Menschen völlig unbrauchbar macht. Es sollte mehr Aufmerksamkeit bekommen. Besonders wenn man bedenkt, dass es seit zwei Jahren geöffnet ist.

@sarink

@BYK , die Verwendung des Mutex-Flags ist völlig inakzeptabel, da es einen zusätzlichen

Mir ist ein solcher Fehler nicht bekannt. Können Sie mich darauf hinweisen, wenn er bereits gemeldet wurde? Die Funktionsweise von --mutex besteht darin, zu verhindern, dass eine andere yarn -Instanz, die denselben Mutex verwendet, ausgeführt wird, bis die erste beendet ist. Was Sie also sagen (nicht Ihre Darstellung), klingt für mich wie "funktioniert wie erwartet".

Trivial package.json oder nicht, dies ist ein großes Problem ohne Lösung oder Problemumgehung, das Garn für viele Menschen völlig unbrauchbar macht. Es sollte mehr Aufmerksamkeit bekommen. Besonders wenn man bedenkt, dass es seit zwei Jahren geöffnet ist.

Vielleicht sollten Sie sich eine Minute Zeit nehmen, um über den inneren Widerspruch Ihres eigenen Satzes nachzudenken: "macht Garn für viele Menschen völlig unbrauchbar" und "es ist seit zwei Jahren offen". Es gibt nur 56 Teilnehmer in dieser Ausgabe, darunter ~ 5 Garnpfleger und insgesamt 138 Kommentare, von denen die meisten um die gleichen Dinge kreisen. Dies sind nicht "viele Leute", dies sind einige Leute und sicher ist es ihnen wichtig, aber ich sehe, dass keiner von ihnen dies als wichtig erachtet, um eine einzelne Zeile Code-Fix zu senden und einfach Fixes für eine Software zu fordern, die vollständig bereitgestellt wird frei für sie.

@ Cinderblock

Verzeihen Sie meine Beharrlichkeit, aber ich sehe immer noch nicht, wie die Mutex-Option eine Lösung ist.

In Bezug auf die Beharrlichkeit gibt es nichts zu verzeihen, es ist eigentlich zu feiern, wenn Sie versuchen, das Problem zu lösen :)

Ich hatte erwartet, dass das Ausführen von Garn --mutex ... diese Option an untergeordnete Instanzen weitergibt (wie zum Beispiel make).

Ich bin mir ziemlich sicher, dass es nicht weitergegeben wird.

Ich habe auch Ihren Vorschlag ausprobiert, --install.mutex network ohne Erfolg zu meiner .yarnrc-Datei hinzuzufügen (gleiche Fehler). --verbose bestätigt, dass die Optionen geladen werden.

Das ist ziemlich interessant. Möglicherweise, weil die neue Garninstanz aus einem anderen Verzeichnis ausgelöst wird und Ihre .yarnrc -Datei ignoriert wird. Ich kann vorschlagen, eine globale .yarnrc -Datei mit dieser Option zu verwenden, die besagt, dass ich dies nicht für eine richtige Lösung halte. Wir sollten dies nur versuchen, um festzustellen, ob die Installation tatsächlich blockiert wird, wie wir es zuvor erwartet hatten.

Vielleicht könnten wir dies aus einer anderen Richtung erreichen? Was macht Garn, was npm nicht macht? Warum hat npm nicht das gleiche Problem?

Ich schätze das vielfältige Denken, dass Yarn und npm so unterschiedlich funktionieren, dass ich glaube, dass dies hier nicht wirklich zutrifft. Wenn wir feststellen können, welches Paket eine Garninstallation als Teil ihrer eigenen Installation auslöst, können wir eine Lösung finden. Vielleicht können Sie die ausführbare Datei yarn durch ein Bash-Skript ersetzen, das die Aufrufquelle, cwd und alle übergebenen Argumente protokolliert und dann wie gewohnt Garn ausführt, um nützliche Debug-Informationen zu erhalten und von dort aus fortzufahren?

Die ultimative Lösung wäre eine Parallelitäts-freundliche Cache-Implementierung, wie ich bereits erwähnt habe. Mit mehr Debugging-Informationen können wir jedoch möglicherweise eine günstigere Problemumgehung finden.

Vielen Dank für Ihre Zusammenarbeit mit diesem @cinderblock , sehr geschätzt.

Die ultimative Lösung wäre eine Parallelitäts-freundliche Cache-Implementierung, wie ich bereits erwähnt habe. Mit mehr Debugging-Informationen können wir jedoch möglicherweise eine günstigere Problemumgehung finden.

Ich denke, es sollte möglich sein, eine vereinfachte Parallelitätsbehandlung bereitzustellen - z. B. wenn andere Garninstanzen während des Erstellungsschritts aufgerufen werden, sollte es nur sehr wenige Cache-Operationen durch den Top-Garnprozess geben. Zumindest würde ich das erwarten. Stellen Sie sicher, dass der Cache auf die Festplatte geleert wird, bevor Sie mögliche Skripte aufrufen. Ich bin mir nicht sicher, wie komplex die Implementierung ist.

@ BYK Oh! Ich hatte nicht in Betracht gezogen, dass ein Unterpaket in einem Skript yarn ... aufruft. Denken Sie, dass der Grund, warum npm install nicht fehlschlägt, darin besteht, dass nur eine Instanz ausgeführt wird, wenn die Abhängigkeiten yarn ... ausgeführt werden?

Ich habe es geschafft, das Problem mit dem Laufen zu lösen

yarn cache clean
rm ./yarn.lock
yarn install

Dieser Vorgang dauert jedoch ewig, da alle Pakete erneut heruntergeladen werden, da Sie a) keinen Cache mehr haben und Ihre Sperrdatei entfernt wurde.

Dies kann auf Ihrem lokalen Computer behoben werden, aber das Problem mit dem Garn bleibt bestehen, falls es bei Bitrise verwendet wird. Es ist ein sauberes Bild von Grund auf neu. Netzwerk-Parallelität ist in jedem Fall erforderlich, selbst wenn ein einzelner Garnprozess ausgeführt wird.

@ BYK

Es gibt nur 56 Teilnehmer in dieser Ausgabe, darunter ~ 5 Garnpfleger und insgesamt 138 Kommentare, von denen die meisten um die gleichen Dinge kreisen.

Das scheint eine ziemlich hohe Zahl für dieses Repo zu sein. Es ist die höchste Kommentarsumme unter allen offenen und geschlossenen Ausgaben und die höchste Teilnehmerzahl.

Was mehr ist, als ich ein (wahrscheinlich) verwandtes Problem recherchierte, sah ich einige Leute mit Problemen, die wahrscheinlich verwandt waren. Das Unglückliche ist, dass viele dieser Leute entweder das Garn als Ganzes aufgegeben haben oder die Kosten für --network-cocurrency 1 verschluckt haben, wenn sich die Garnsperrdatei geändert hat. Genau das habe ich für eines meiner Projekte getan, bis ich endlich herausgefunden habe, dass es sich um ein Subskript handelt.

Dies sind nicht "viele Leute", dies sind einige Leute und sicher ist es ihnen wichtig, aber ich sehe, dass keiner von ihnen dies als wichtig erachtet, um eine einzelne Zeile Code-Fix zu senden und einfach Fixes für eine Software zu fordern, die vollständig bereitgestellt wird frei für sie.

Garn ist nicht die Art von Projekt, in die Menschen leicht springen können. Es ist ein komplexes System, das eine Menge Dinge auf asynchrone Weise erledigt, was bedeutet, dass Sie nicht einfach einen Debugger plumpsen und den Stapel hochgehen können, um zu sehen, was los ist. Daher ist es keineswegs einfach, diese Codebasis zu verstehen, und es ist noch schwieriger, sie zu ändern. Zur Hölle, zu diesem Zeitpunkt habe ich bereits einige Tage Zeit damit verbracht, den Code durchzulesen, und ich bin immer noch nicht sicher genug, um auch nur einen einfachen Patch mit relevanten Tests einzureichen. Angesichts der Tatsache, dass ich über zwei Jahrzehnte Erfahrung habe und das Lesen von Code eine meiner Spezialitäten ist, würde ich einem durchschnittlichen Entwickler nicht die größten Chancen geben.

Mit anderen Worten, was eine schnelle, einfache einzeilige Lösung für Sie sein kann, kann ein großes mehrtägiges Projekt für jemanden sein, der mit dem Innenleben des Projekts nicht vertraut ist. Dies ist, bevor ich die impliziten Richtlinien erwähne, die in verschiedenen Gemeinschaften existieren. Ich habe mindestens ein paar PRs in verschiedenen Open-Source-Projekten abgelehnt bekommen, weil ich kein Protokoll befolgt oder den richtigen Test geschrieben, die richtige Spezifikation eingehalten oder sogar nur eine Lösung gefunden habe, die einigen undokumentierten Codierungsstandards nicht entspricht. Es kann eine Herausforderung sein, als Außenseiter einen bedeutenden Beitrag zu großen Projekten zu leisten.

Wenn dies wirklich ein einzeiliger Fix für Sie ist, wäre es dann nicht schneller, diesen Fix zu schreiben, als einen langen Beitrag zu schreiben, in dem andere dafür kritisiert werden, dass sie es nicht tun?

Wenn wir feststellen können, welches Paket eine Garninstallation als Teil ihrer eigenen Installation auslöst, können wir eine Lösung finden.

Ich habe ein Beispiel für ein Paket, das diese Art von Verhalten hier zeigt , obwohl ich dort kein yarn install sehe (es sei denn, das bob build tut es, obwohl es dieses Problem auch damals zeigte, als Der Befehl war "prepare": "node ./scripts/generate-mappings", ).

Die ultimative Lösung wäre eine Parallelitäts-freundliche Cache-Implementierung, wie ich bereits erwähnt habe. Mit mehr Debugging-Informationen können wir jedoch möglicherweise eine günstigere Problemumgehung finden.

Ein guter Ausgangspunkt wäre eine Warnung, wenn eine solche Situation erkannt wird (vorausgesetzt, sie ist erkennbar). Ein paralleler Cache scheint eine konzentrierte Anstrengung von mindestens einem Mitglied der Garngemeinschaft zu sein.

Update hat eine Problemumgehung gefunden, die funktioniert .... ein Git-Submodul und dann muss der Speicherort des Pakets der lokale Ordner sein. Nicht ideal, aber es funktioniert.

Wir haben dieses Problem auch in CircleCI und es ist ein großes Problem. Das Problem scheint mit der Verwendung eines auf github.com und möglicherweise Linux gehosteten Pakets zu zusammenhängen (es funktioniert unter OSX). mutex Optionen network-concurrency bewirken nichts.

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

Wenn ich das entferne, funktioniert es in CircleCI. Lokal funktioniert es damit unter OSX mit Garn 1.17.0.

Auf CircleCI mit Knoten 12.8.1 und Garn 1.17.3 funktioniert es jedoch nicht (Kreisbild Kreisci / Knoten: Neueste)

Oder mit Knoten 8.15.0 und Garn 1.12.3 (Kreisbild Kreisci / Knoten: 8.15.0)

#!/bin/bash -eo pipefail
yarn install --mutex network --network-concurrency 1
yarn install v1.12.3
[1/4] Resolving packages...
warning Resolution field "[email protected]" is incompatible with requested version "mixin-deep@^1.2.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^0.4.3"
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
$ cd functions && yarn install
yarn install v1.12.3
[1/5] Validating package.json...
[2/5] Resolving packages...
warning Resolution field "[email protected]" is incompatible with requested version "mixin-deep@^1.2.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.1"
[3/5] Fetching packages...
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error https://registry.yarnpkg.com/lodash/-/lodash-4.17.15.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/home/circleci/.cache/yarn/v4/npm-lodash-4.17.15-b447f6670a0455bbfeedd11392eff330ea097548/node_modules/lodash/_arrayReduceRight.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
info There appears to be trouble with your network connection. Retrying...
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Exited with code 1

--network-concurrency 1 ist erfolgreich, --network-concurrency 8 schlägt fehl, auf circleCI / node: 10

Darf mir jemand helfen zu verstehen, warum Garn bei EEXIST und EOENT versagen muss?

Im Falle von EEXIST würde ich erwarten, dass Yarn davor warnt und dann die Datei überschreibt.
Im Falle von EOENT würde ich erwarten, dass Yarn den fehlenden Ordner erstellt (was normalerweise die Ursache des Problems ist).

Ich verstehe, dass es Nebenwirkungen haben kann, daher könnte dieses Verhalten möglicherweise mit einer Flagge verschärft werden (oder umgekehrt).

Aber was bringt es, diese Fehler beizubehalten? Sie sind für niemanden nützlich.

@BYK Sorry, ich habe gerade deinen Kommentar gesehen

Mir ist ein solcher Fehler nicht bekannt. Können Sie mich darauf hinweisen, wenn er bereits gemeldet wurde? Die Funktionsweise von --mutex besteht darin, zu verhindern, dass eine andere yarn -Instanz, die denselben Mutex verwendet, ausgeführt wird, bis die erste beendet ist. Was Sie also sagen (nicht Ihre Darstellung), klingt für mich wie "funktioniert wie erwartet".

Dies ist der Fehler: https://github.com/yarnpkg/yarn/issues/6650, wie in https://github.com/yarnpkg/yarn/issues/2629#issuecomment -481297806 erwähnt (unter dem ich glaube, dass er jetzt begraben ist das "mehr Geschichte zeigen" in diesem Thread)

Es gibt nur 56 Teilnehmer in dieser Ausgabe

Nun, ich denke, das ist ein fairer Punkt

Dieser Fehler ist noch in Garn v1.19.1. Ich verstehe nicht, warum Yarn Team diesen sehr lästigen Fehler nicht repariert.
Hier ist mein .yarnrc und es hilft nicht:

save-prefix ""
--install.check-files true
--add.check-files true
--remove.check-files true
--install.frozen-lockfile true
--add.frozen-lockfile true
--remove.frozen-lockfile true
--install.mutex network
--install.mutex file

Was ich gerade entdeckt habe, dass das Ausführen von npx lerna clean && ./yarn-install-in-loop.sh hilft.
Das Reinigen (Entfernen) aller node_modules -Verzeichnisse in meinem Monorepo hilft.

@ Gitowiec kann bestätigen. Meine containerisierten yarn install -Aufrufe sind Daten, die etwas im Dateisystem rasen, und jeder Versuch, yarn auf eine einzelne .yarnrc -Datei zu beschränken, schlägt fehl. Ich gebe auf und gehe zurück zu npm .

Ich habe festgestellt, dass mein Problem darin bestand, Paketabhängigkeiten von Git-Repositorys über mehrere Ebenen hinweg zu haben (dh mein Paket -> Git-Paket -> Git-Paket -> Git-Paket). Außerdem funktionierte der Cache während der Installation im Vergleich zu npm nicht gut (npm nur einmal auschecken, aber Garn mehrmals während derselben Installation auschecken).
Ich gehe zurück zu npm. Es funktioniert gut seit v6.

Wie oben erwähnt, besteht dieses Problem weiterhin. Folgendes haben wir zu unserem config.yml für circleci hinzugefügt, damit unsere Tests bestehen:
- run: name: Yarn Install source ~/setyarnpath.sh i=5; until yarn; do echo "Yarn failed. Retrying..."; ((i--)); if [[ "$i" == '0' ]]; then break; fi; done

Ich hatte das gleiche Problem. Verwenden von macOS und Docker-Compose mit einem Host [1] -Volume, in dem sich mein Code UND die Knotenmodule befanden.

Node_modules wurde so geändert, dass es sich in einem anonymen Volume befindet, aber ich denke, ein benanntes Volume würde auch funktionieren. Und es scheint jetzt gut zu funktionieren und die Abhängigkeiten VIEL schneller zu installieren.

Meine Docker-Compose-Datei wurde geändert von:

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

Zu:

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

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

Ich sehe einen neuen Fehler mit yarn , der meiner Meinung nach ein neues Symptom für dieses Problem ist.

yarn stdout [1/4] Resolving packages...
yarn stdout [2/4] Fetching packages...
yarn stderr error https://registry.yarnpkg.com/prettier/-/prettier-1.19.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "EEXIST: file already exists, mkdir '/home/pi/.cache/yarn/v6/npm-prettier-1.19.1-f7d7f5ff8a9cd872a7be4ca142095956a60797cb-integrity/node_modules/prettier'"
yarn stdout info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn stderr Process stalled
yarn stderr Active handles:
yarn stderr   - Socket
yarn stderr   - Socket
yarn stderr   - Socket
yarn stderr   - TLSSocket
yarn stderr   - TLSSocket
yarn stderr   - TLSSocket

Hinweis: yarn stderr/out sind das Präfix, das mein Programm der Garnausgabe in meiner Umgebung gibt

Ich glaube, dies ist das gleiche Problem, da mein Projekt die alten Symptome ziemlich konsistent auf die gleiche Weise erzeugen könnte, wie diese neuen Symptome auftreten (und die alten Symptome aufgehört haben).

Als Referenz geschieht dies bei der Installation, nachdem ich den Garncache und node_modules geleert oder eine bestimmte Git-Paketabhängigkeit aktualisiert habe.

Die bestimmte Paketabhängigkeit ist eine Abhängigkeit von einem anderen Git-Paket, von dem ich tatsächlich abhängig bin (beide haben ähnliche prepare -Schritte, die auf TypeScript basieren). Wenn ich Änderungen an diesen Abhängigkeiten von #master vornehme und yarn upgrade --latest mache, tritt das Problem auf (und bei nachfolgenden yarn install .

Wenn ich dieses Unterpaket manuell aktualisiere (in einen vollständig separaten Ordner node_modules !), Funktioniert yarn install wieder. Dies lässt mich denken, dass Garn versehentlich den Cache durch zwei Prozesse gleichzeitig verwendet, und dies verursacht die Probleme, die wir in dieser Ausgabe sehen.

Dies passiert mir, wenn ich zwei oder mehr Pakete verwende, die durch Git-Abhängigkeit installiert wurden. Irgendwie gibt es mehrere Prozesse für dasselbe Paket, auf denen das Skript prepare . Außerdem schlägt es mit npm auch in den letzten Versionen fehl.

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

Dies hat sich seit Jahren geöffnet und geschieht immer noch mit Garn 1.22.0.
Ich habe nur Stunden damit verbracht, ohne Glück zu debuggen, was los war, und es scheint, dass ich nicht der einzige war.

Die einzige Lösung, die ich jetzt sehe, ist, zu npm zu wechseln.

@gregory In meinem Fall erinnere ich mich, dass Garn im Juni 2019 immer die benötigten Pakete installiert hat, selbst wenn 2-4 Wiederholungen erforderlich waren, um dorthin zu gelangen. Darüber hinaus war das Garn trotz dieser Wiederholungen immer

Ich würde es erneut ausführen, bis das Garn mit den folgenden Befehlen fertig ist:

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

Die einfache Lösung für uns bestand darin, ein privates Paket zu veröffentlichen und es anstelle eines Git-Links zu verwenden. Trotzdem nervig

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

Wirklich traurig, dass die einzige Lösung Brute Force ist ... unglaublich, dass dies noch niemand behoben hat.

cc @arcanis

Der Versuch, zwei Garne nacheinander zu installieren, funktioniert beim ersten Mal und schlägt dann fehl.

Schnelles, zuverlässiges und sicheres Abhängigkeitsmanagement.

Das ist unzuverlässig.
`` `[3/5] Pakete holen ...
Fehler https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Das Extrahieren des Tar-Inhalts von undefined ist fehlgeschlagen. Die Datei scheint beschädigt zu sein: "ENOENT: Keine solche Datei oder kein solches Verzeichnis, Link '/ App / /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-Integrität / Knotenmodule / lz4 / build / Release / obj.target / lz4.node '"
info Dokumentation zu diesem Befehl finden Sie unter https://yarnpkg.com/de/docs/cli/install .
[1/5] Paket validieren.json ...
[2/5] Auflösen von Paketen ...
[3/5] Pakete holen ...
info Es scheint Probleme mit Ihrer Netzwerkverbindung zu geben. Wiederholen ...
info [email protected] : Die Plattform "Linux" ist mit diesem Modul nicht kompatibel.
info " [email protected] " ist eine optionale Abhängigkeits- und fehlgeschlagene Kompatibilitätsprüfung. Ausschluss von der Installation.
info [email protected] : Die Plattform "Linux" ist mit diesem Modul nicht kompatibel.
info " [email protected] " ist eine optionale Abhängigkeits- und fehlgeschlagene Kompatibilitätsprüfung. Ausschluss von der Installation.
[4/5] Abhängigkeiten verknüpfen ...
[5/5] Neue Pakete bauen ...
$ npm run vorbereiten: mjs && npm run vorbereiten: js

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

39 Dateien mit Babel erfolgreich kompiliert.

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

39 Dateien mit Babel erfolgreich kompiliert.

[3/5] Pakete holen ...
Fehler https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Das Extrahieren des Tar-Inhalts von undefined ist fehlgeschlagen. Die Datei scheint beschädigt zu sein: "ENOENT: Keine solche Datei oder kein solches Verzeichnis, Link '/ App / /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-Integrität / Knotenmodule / lz4 / build / Release / obj.target / lz4.node '"
info Dokumentation zu diesem Befehl finden Sie unter https://yarnpkg.com/de/docs/cli/install .
info Es scheint Probleme mit Ihrer Netzwerkverbindung zu geben. Wiederholen ...

`` `

Jeder hat eine Idee, warum Garn anrufen würde

error https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, link '/app/.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lz4.node' -> '/app/.cache/yarn/v6/npm-lz4-0.6.3-
  df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/lz4.node'"

wenn der richtige Weg hätte sein sollen:

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

es scheint, dass Garn aus irgendeinem Grund obj.target/build/Release/ hinzufügt. Könnte mit https://github.com/yarnpkg/yarn/commit/0e7133ca28618513503b4e1d9063f1c18ea318e5 zusammenhängen

Ich bekam den gleichen frustrierenden und schwer zu debuggenden Fehler. Das Problem in meinem Fall schien das Verhalten von yarn workspace zu sein, das durch verschiedene Versionen derselben Abhängigkeit in verschiedenen Paketen verursacht wurde (insbesondere ava Versionen 2 und 3). Erst als ich alle Vorkommen von ava auf den neuesten Stand gebracht hatte, wurde dieser Fehler nicht mehr angezeigt.

Ich habe 1.22.4 und war stundenlang mit diesem Problem beschäftigt. Unser Monorepo hat mehrere Module mit denselben Paketen. Schließlich wurde es sortiert, indem Folgendes angewendet wurde:
1) Stellen Sie sicher, dass Sie für alle Module dieselbe Version eines Pakets verwenden - dies führt mit Sicherheit zu einem Absturz, selbst bei devDependencies .
2) Pin alle Versionen in der Monorepo in allen package.json Dateien.

Kann immer noch ein Problem auf 1.22.4 . Ursprünglich war es mocha , und nachdem ich sichergestellt habe, dass alle Pakete dieselbe Version verwenden, werden jetzt Fehler aus camelcase generiert, die ich anscheinend nicht einmal in meinem Projekt verwende Es ist von yargs , möglicherweise von Lerna.

Fehler Ein unerwarteter Fehler ist aufgetreten: "ENOENT: Keine solche Datei oder kein solches Verzeichnis, lstat '/ code / project / src / packages / private-package / node_modules / camelcase'".

Darf ich fragen, ob eine Lösung in Sicht ist? Wir löschen weiterhin 20 node_modules und ein yarn.lock , um das

Darf ich fragen, ob eine Lösung in Sicht ist? Wir löschen weiterhin 20 node_modules und ein yarn.lock , um das

Ich persönlich bin in Bezug auf die Handhabung von Arbeitsbereichen zu lerna gewechselt.

Ziemlich sicher, dass die aktuelle Lerna einfach an Yarn weitergegeben wird.

Ich konnte meine Probleme umgehen, indem ich eine nohoist -Konfiguration für Ember-Pakete hinzufügte. Meine aktuelle Umgebung verwendet eine ältere Version von Ember, die nicht mit Arbeitsbereichen kompatibel ist.

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

Ich denke, wir haben hier jetzt einen minimalen Repro: https://github.com/yarnpkg/yarn/issues/7212#issuecomment -637978197

Das Löschen von yarn.lock und yarn install hat auch bei mir funktioniert

Irgendwelche Neuigkeiten hier? Unser CI-Prozess ist gerade ausgefallen, da alle Pipelines aufgrund eines Abhängigkeitsinstallationsfehlers vom Garn ausgefallen sind. Das ist lächerlich.

Das Setzen von --network-concurrency behebt nichts und Jobs werden auf sauberen Maschinen ausgeführt (keine node_modules, kein Garn-Cache).

@cadavre Keine Garantie, aber dies ist in

yarn set version 2 && yarn config set nodeLinker node-modules

https://yarnpkg.com/getting-started/install#per -project-install
https://yarnpkg.com/configuration/yarnrc#nodeLinker

Dies passierte mir auch gerade erst, nachdem ich einige meiner Vue- und Firebase-Abhängigkeiten aktualisiert hatte. Jetzt 100% wiederholbar in meinen CI- und Entwicklungsmaschinen. Das Hinzufügen von --network-concurrency 1 behebt das Problem nicht zuverlässig. Ich habe nicht genügend Speicherplatz oder Inodes. Ich bin auf WSL1. Garn 1.22.4.

Ich habe es behoben, indem ich das Cache-Verzeichnis vorübergehend geändert habe, das ich gleich danach lösche.

Für mich ist es Docker Build:

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