<p>Garninstallation hängt während "Pakete holen..."</p>

Ich habe das gleiche Problem unter Windows 10 mit nodejs v6.2.0 x64.

Es hängt sich beim Holen des letzten Pakets auf:

C:\xxx>yarn
yarn install v0.15.1
info No lockfile found.
warning [email protected]: No license field
[1/4] Resolving packages...
warning wdio-mocha-framework > mocha > glob > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning wdio-mocha-framework > mocha > [email protected]: to-iso-string has been deprecated, use @segment/to-iso-string instead.
warning wdio-mocha-framework > mocha > [email protected]: Jade has been renamed to pug, please install the latest version of pug instead of jade
[2/4] Fetching packages...
█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ 868/869

@sorgloomer yep gleiches Verhalten, es hängt tatsächlich am letzten Paket.

Gleiches Problem, aber mit bower.json. In diesem Fall funktioniert es auf meinem lokalen macOS. (mit einer Komplikation https://github.com/yarnpkg/yarn/issues/846)

{
  "name": "jaguar",
  "version": "0.0.0",
  "private": true,
  "dependencies": {
    "bootstrap": "~3.3.5",
    "devicejs": "2ae5c775e35ccc837589e5af34e292c54936778c",
    "jquery": "2.1.3",
    "jquery-transform": "e195b9a7118558bb1141e50b80380ea5f31dffb8",
    "moment": "2.14.1",
    "moment-timezone": "0.5.5",
    "owl-carousel2": "2.0.0-beta.2.4",
    "raven-js": "3.5.1",
    "ua-parser-js": "0.7.10",
    "underscore": "1.8.3",
    "object-fit": "~0.4.2",
    "picturefill": "^3.0.2",
    "jquery-selectBox": "316c77f157cb25c7a6ea36822143ac9d97845067"
  },
  "resolutions": {
    "jquery": "2.1.3"
  }
}

Gleiches Problem hier.
Windows 10
Knoten v6.2.0
npm 3.8.9

yarn yarn install v0.15.1 info No lockfile found. warning [email protected]: No license field [1/4] Resolving packages... warning glob > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue warning gulp.spritesmith > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected]: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. warning gulp-imagemin > imagemin-gifsicle > exec-buffer > execa > [email protected]: cross-spawn no longer requires a build toolchain, use it instead! warning gulp.spritesmith > spritesmith > pixelsmith > ndarray-fill > cwise > static-module > through2 > xtend > [email protected]: [2/4] Fetching packages...

Gleiches Problem hier
Windows 10
Knoten v6.2.0
npm 3.8.9
[email protected]
Verwenden von nvm zum Aktualisieren oder Installieren von Knotenversionen

Es funktioniert unter Windows 10 mit
Knoten 6.7.0
npm v3.10.3
[email protected]
Es scheint also eine Node- oder npm-Version zu geben, die in Konflikt steht

Ich dachte, der springende Punkt wäre, den npm-Client aus der Gleichung auszuschließen

Das Update auf nodejs v6.7.0 hat mein Problem gelöst

Defekt auf Knoten v4, Arbeit an v6.7

hängt an:

• Knoten 5.11.1
• npm 3.8.6
• macOS 10.12
• Garn 0.15.1

hängt an:

• node v6.7.0
• windows 10
• yarn 0.15.1

Mein Jenkins-Rechner sah auch die gleiche Hang-on-Final-Package-Installation mit:

• Knoten v5.11.0
• Ubuntu 14.04.2 LTS
• Garn 0.15.1
• npm 3.10.8

Ein Upgrade auf Node 6.8.1 über n hat es auf magische Weise behoben.

Bestätigt. Hängt an 6.1.0 und ein Upgrade auf 6.8.1 hat es behoben.

(Das gleiche hier - Node 6.2 -> 6.8 behebt es)

Scheitern für mich auf CircleCI:

• Ubuntu 14.04 (Vertrauenswürdig)
• Knoten v4.4.6
• Garn 0.16.1
• npm wird in dieser Umgebung nicht ausgeführt.
• Cache/node_modules werden über rm -rf node_modules/ && rm -rf ~/.yarn-cache/ && mkdir -p ~/.yarn-cache gelöscht

Besonders zu beachten ist, dass es ständig hängt, wenn eine Datei aus einem privaten Git-Repository gezogen wird. Die Datei variiert, aber es ist immer dieses Repository.

Dieser Befehl zeigt die Dateideskriptoren an, die von einem bestimmten Prozess geöffnet wurden:

$ lsof -p <pid of yarn.js process>
( ... results trimmed ... )
node    19551 ubuntu   24w   REG               0,89     2048  457983 /home/ubuntu/.yarn-cache/npm-our-private-pkg-1.0.0/src/styles/fonts/glyphicon.svg

Ich habe hier in den CircleCI-Foren ein verwandtes Problem mit anderen Informationen eingereicht, die wahrscheinlich nicht wesentlich wertvoller sind als die hier.
https://discuss.circleci.com/t/yarn-install-hangs-and-never-completes-related-to-dash/7664

Update: Das Update auf Node v6.9.1 behebt das Problem bei wiederholten Neuerstellungen mit und ohne Cache.

Um einige Daten hier in einem Bogen für eine Fehlerbehebung zusammenzufassen:
Beeinflusst alle Betriebssysteme, sowohl Garn 0.15.1 als auch 0.16.1, und scheint in Knoten 6.2 (und früher) gebrochen und in Knoten 6.7 (und später) behoben zu sein, ohne dass in der Mitte Datenpunkte gemeldet werden.

Dies scheint mir auch zu passieren.
Ubuntu 14.04
Knoten 4.4.5
Garn 0.16.1

ich auch, scheiße
[email protected]
[email protected]
[email protected]

Gleiches Problem hier
Ubuntu 14.04
Knoten v6.0.0
npm 3.8.6
[email protected]

Dasselbe:

OSX: 10.11.6
Knoten: v5.12.0
Garn: 0.17.9

Funktioniert mit Knoten > 6,7

Hängt bei mir auch bei 1040/1041
Windows 10
Knoten v6.9.3
Garn 0.18.1

Ich bin gerade darauf gestoßen.

Knoten 7.4.0
npm 3.10.9
Garn 0.18.1

Update: Ich habe festgestellt, dass, wenn Sie es ~ 8 Minuten lang ruhen lassen, es irgendwann durchgeht ...

Datapoint: Ich habe das jetzt seit 2 Tagen hängen lassen. Der Prozess hat nichts Nützliches bewirkt :

Ich habe mein Problem herausgefunden, aber es könnte nur für wenige Leute spezifisch sein.

ich bin auf windows 10

Vanilla-Masker wurde mitgeliefert, um von Garn heruntergeladen zu werden, aber Vanilla-Masker ist aufgrund eines schlecht benannten Verzeichnisses nicht mit Windows kompatibel. Ich habe die Abhängigkeit geändert, um lagden-vanilla-masker (https://www.npmjs.com/package/lagden-vanilla-masker) zu verwenden, eine Kopie von Vanilla-Masker, die das fehlerhafte Verzeichnis in Windows-kompatibel umbenannt hat.

Als mein Problem stellte sich heraus, dass die Festplatte voll war.

Was für mich funktionierte, war, VPN zu verlassen:

Vor:

λ bundle → λ git develop* → yarn add winston-aws-cloudwatch
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error Command failed.
Exit code: 128
Command: git
Arguments: clone git://github.com/realtymaps/ssh2.git /Users/Justin/Library/Caches/Yarn/.tmp/f5257a9a008d54d3956928f15f351a79
Directory: /Users/Justin/Projects/www/MotorTrend/OnDemand/api/assets/bundle
Output:
Cloning into '/Users/Justin/Library/Caches/Yarn/.tmp/f5257a9a008d54d3956928f15f351a79'...
fatal: read error: Operation timed out
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

nach:

λ bundle → λ git develop* → yarn add winston-aws-cloudwatch
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning Unmet peer dependency "request@^2.34".
warning Unmet peer dependency "request@^2.34".
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 19 new dependencies.
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
└─ [email protected]
✨  Done in 16.95s.
λ bundle → λ git develop* →

Ich habe das gleiche Problem schon seit langer Zeit unter macOS, es verlangsamt sich zufällig beim Abrufen von Paketen. Für meine Konfiguration dauert es durchschnittlich 2-4 Minuten, aber alle paar Durchläufe sind es 35-30 Minuten.

npm: 4.0.5
Knoten: 7.4.0
Garn: 0.19.1

Dieses Problem trat in Travis auf, als eine Github-Abhängigkeit hinzugefügt wurde:(

Gleiches:
OSX 10.12.2
$ Knoten -v
v6.5.0
$ npm -v
3.10.6
$ Garn --version
0.17.8

Für mich war die Lösung "npm install -g Garn" statt "apt-get install Garn"

Update: Hängt wieder, also war npm install keine Lösung und es funktioniert manchmal. Ich denke, es funktioniert mit Version 0.19.0 aber nicht 0.19.1..

Für mich eingefroren. Habe es sogar mit "npm install -g Garn" versucht. Bitte repariere!!!

Garnausführung:
0.19.1

Knotenversion:
4.4.6

Plattform:
Linux x64

dies auch über mehrere Projekt-/Garndateien hinweg nach dem Upgrade auf Garn 0.19.1 über npm i -g yarn@latest

Garn 0.19.1
Knoten 6.1.0
Mac OS

Für mich hat das Downgrade über npm i -g [email protected] funktioniert, um auf yarn install

Das passiert mir auf unseren Staging-Servern, die gerade neu installiert wurden.

Garn 0.19.1
Knoten 5.11.1
ubuntu

BEARBEITEN: gleiches Problem bei 0.19.0 und Knoten 5.12.0

EDIT 2: aktualisiert auf Knoten 6.9.5 und funktioniert jetzt

EDIT 3: wieder auf Garn 0.19.1 aktualisiert und es funktioniert immer noch

Knoten 6.1.0 => 7.2.1 funktioniert

Ist bei mir auch passiert. Hängt an der letzten Abhängigkeit.
Knoten: v5.12.0
Garn: v0.20.3
Ubuntu 14.04

FIX: Node auf die neueste Version (v7.5.0) aktualisiert und es funktionierte.

Bekomme dieses Problem in letzter Zeit, eine wirkliche Lösung?

Nein, es wird einfach ignoriert, wie üblich, wenn große Unternehmen ein Open-Source-Projekt machen. Wenn es für sie funktioniert, wen interessiert es dann, wenn so etwas passiert.

Helfen Sie mit, eine Lösung zu finden oder machen Sie eine Wanderung @robclancy

lmao Ich liebe diese Logik ... wenn etwas Open Source ist, spielt es keine Rolle, wie viele Milliarden-Dollar-Unternehmen dahinter stehen, mit einem Problem, in das die Leute immer wieder ohne Reaktion geraten, die Fanboys werden es blind verteidigen.

Es ist kantig und ihre kaputten Dokumente noch einmal.

Geh woanders Fanboy.

Sie, Sir, sind ein Narr, wenn Sie denken, ich könnte jemals ein Fanboy von allem sein, was in JavaScript geschrieben ist. Aber oder natürlich sind Sie nur hier, um zu trollen, nicht um etwas Sinnvolles beizutragen. Sie können wahrscheinlich damit rechnen, dass dieses Problem bald behoben wird.

Eigentlich beschwerte ich mich hier über ein Problem, das inzwischen behoben oder zumindest beantwortet werden sollte, wie bei anderen auch. Sie sind hier, um mit jemandem im Internet wie ein kleiner Fanboy zu streiten.

Wie wäre es, wenn Sie dies beheben oder eine Wanderung unternehmen.

Andere sind sie, um höflich nach möglichen Fortschritten in dieser Angelegenheit zu fragen. Garn wurde Ihnen nie verkauft, also beschweren Sie sich weiter bei sich selbst. Sie sind "dieser Typ", der Open Source zu einer Nervensäge macht.

Wie ironisch.

Sie sind einer dieser Open-Source-Helden. Fahren Sie fort, ich bin sicher, es gibt da draußen eine andere Bibliothek, die vernachlässigt wird und die Sie blind verteidigen können. Sei gegangen Held. Machen Sie Ihre Arbeit.

Ich würde total dazu beitragen und helfen, aber ich habe den Quellcode durchgesehen und war zu Recht verwirrt, wo ich überhaupt anfangen sollte.

Es gibt Projekte, zu denen ich mit Code beitragen kann, und ich tendiere dazu, diesen Weg zu bevorzugen. Es gibt andere Projekte, bei denen ich nur ein Problem melden kann und hoffe, dass jemand, der sich mit der Codebasis besser auskennt, helfen kann, die Ursache zu finden.

Das ist definitiv letzteres hehe.

Bleiben wir zivilisiert @benjie @robclancy 🥇

Gleiches Problem, hängt an Gesamtpaketen - 1
ubuntu linux 4.4.0-64-generisch x86_64
Knoten 6.2

@code-by Ein Upgrade auf Node 6.8.1 oder höher scheint dieses Problem für die meisten (aber nicht alle) Leute zu beheben; probier das mal aus. Ich habe das Problem seit dem Upgrade im Oktober nicht mehr gesehen. Node 7.6 bietet native Unterstützung für async/await, wenn das den Deal versüßt 😉

Komm schon! Nagelneuer Mac. Homebrew installierter Knoten und npm. Hängt noch am letzten Paket.
$ node -v v7.7.1
$ npm -v 4.1.2

Es ist ein langer Versuch, aber ich habe dies auch auf einem Mac gesehen, wenn Sie ein privates Paket haben, auf das in Ihrer package.json verwiesen wird - es scheint zu hängen, aber es fragt tatsächlich nach Ihrem Schlüsselbundkennwort für ssh. Die Glyphe mit sicherer Eingabe ( ) erscheint am rechten Rand des Fortschrittsbalkens, aber auf dem Terminal eines Kollegen, das praktisch unsichtbar war. Ich habe es behoben, indem ich ssh-add -K bevor ich yarn .

@jdelStrother das war es! Ich hatte eine private Paketreferenz und ssh-add -K && yarn install ist der Befehl, der es zum Laufen gebracht hat. Vielen Dank und meine Anerkennung, mein Herr!

Unsere Probleme damit sind für uns vor Ort verschwunden, aber ich bin es immer noch
Verwenden von NPM in CI, da dies manchmal vorkommt. Mit den letzten Kommentaren
über ssh habe ich mich entschieden, alle mit https zu überprüfen und zu ändern. Sie waren nur
öffentliche Github-Repositorys, also habe ich nie ssh benötigt, aber ich dachte, wenn sich ssh ändert
könnte das lösen, vielleicht war es ein Problem mit SSL. Und diese ändern
Pakete sowohl in eine Version als auch in eine, die die github-Definitionen anstelle von
eine https-URL und die erste Ausführung hat nicht aufgehängt.

Am Freitag, 3. März 2017 um 04:30 Uhr DouG Molidor [email protected]
schrieb:

@jdelStrother https://github.com/jdelStrother das war es! Ich hatte ein
private Paketreferenz und ssh-add -K && Garninstallation ist der Befehl
das hat es zum laufen gebracht. Vielen Dank und meine Anerkennung, mein Herr!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/yarnpkg/yarn/issues/764#issuecomment-283737992 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AA0UF5PKUy1Lx5nlGZF9HMoSIPhEG8-Tks5rhwrOgaJpZM4KUM4j
.

Gleiches hier für CircleCI mit Ubuntu 14.04 (Trusty) und Knoten v6.9.1.

Ich habe das Problem in https://github.com/yarnpkg/yarn/pull/2950 behoben

Ich bin überrascht, wie viel Zeit mit Diskussionen verschwendet wurde, als es buchstäblich eine Einzeilenkorrektur war, wenn man bedenkt, dass ich kein Javascript-Hintergrund habe.

Hatte das Problem nur bei der Verwendung von Node 5.12.0. Der Wechsel zu Version 6.9.1 von Node (über nvm ) hat das Problem für mich behoben.

Es sollte nicht von der Node-Version betroffen sein, da die Ursache des Problems das nicht angegebene Timeout ist. #2950 fügt die Zeitüberschreitung hinzu.

Führt Garn also einen erneuten Versuch und Abruf von anderen Servern aus, wenn eine Zeitüberschreitung auftritt? Wird deshalb die Zeitüberschreitung als Fix für die Hänger angesehen?

Yarn wiederholt alle Anfragen, die aufgrund eines Netzwerkfehlers fehlgeschlagen sind. Dieser PR veranlasst Yarn, den Timeout-Fehler als Netzwerkfehler zu betrachten. Es gibt keine "anderen Server", aber Sie können beim nächsten Versuch mehr Glück haben, wenn es sich um einen Verbindungsfehler zwischen dem Hosting Ihrer App (EC2) und dem CDN vor registry.yarkpkg.com

apt-get update friert für immer ein, wenn ich 'deb https://dl.yarnpkg.com/debian/stable main' in meiner sources.list habe:( - irgendeine Lösung?

Habe immer noch dieses Problem mit Garn v0.23.2 und nodejs 6.1.0 . Upgrade auf nodejs 6.7.0 das Problem gelöst.

Ich habe dieses Problem auch mit:
Garn v.0.23.2
nodejs v.7.9.0

und nachdem Sie diesen Befehl ausprobiert haben:
Garn hinzufügen Semantik-ui

Ich habe mehr als zwei Stunden gewartet und die Installation wurde nicht abgeschlossen

Anscheinend werden die meisten Fälle mit einem Node-Update behoben.
Eine andere Möglichkeit, die Fehlersuche zu unterstützen, besteht darin, das Flag --verbose auszuführen, um zu sehen, welche Anfrage hängt.
Sonst können wir hier nichts machen

Sie können auch strace zu sehen, was genau es hängt.

Gleiches Problem, hatte nvm und würde die Knotenversionen wechseln, um eine zu finden, die funktioniert.

Ging von 4.4.6 und 5.12 (kein Erfolg). Knoten 6.7.0 funktioniert, aber es ist schwieriger, das Team davon zu überzeugen, dass Garn ein Drop-In-Ersatz ist, wenn wir die Knotenversionen wechseln müssen.

@jeffshek kannst du versuchen, strace Garn auf Knoten 4.4.6 oder 5.12 zu verkleben? Das könnte uns möglicherweise helfen, das Problem zu finden.

Nachdem ich also auf Node 6.7 umgestiegen war, konnte ich installieren usw.

Um dieses Problem zu reproduzieren, habe ich das Garn.lock gelöscht, alle node_modules entfernt und auf den Knoten 4.4.6 umgestellt.

ich bekam

yarn install

[2/4] 🚚  Fetching packages...
error [email protected]: The engine "node" is incompatible with this module. Expected version ">=6.0".
error Found incompatible module

Okay, das sieht nach einer Art diagnostizierbarer Meldung aus ... (War diese Fehlermeldung die ganze Zeit nur versteckt?)

Aber jetzt, wenn ich Garn installiere, funktioniert es einfach wie von Zauberhand (Knoten 4.4.6). Jetzt kann ich sogar auf Knoten 4.4.6 eine Garninstallation mit demselben package.json durchführen, das vor ein paar Stunden nicht funktioniert hätte. Ich habe Garn.lock entfernt, eine neue Garninstallation durchgeführt und es funktioniert weiterhin.

Ich wünschte wirklich, ich könnte mehr Hilfe leisten, aber die Verwendung von nvm zum Wechsel auf Version 6.7 und dann zurück zu 4.4.6 ließ das vorherige Problem verschwinden.

Ich bin neu in Sachen Garn. Habe es zum ersten Mal probiert. yarn install . Ergebnis: Hängen auf unbestimmte Zeit während der Installation von Paketen. (Besonders das Paket jsesc , aber ich bin mir nicht sicher, ob das wichtig ist.)

Es stellte sich heraus, dass Garn auch meine NPM-Befehle verpfuscht hat? o_O "npm clean" funktioniert jetzt nicht mehr nach einem einfachen brew install yarn und yarn install . Das war alles, was ich in einem Projektordner gemacht habe, und meine GLOBAL-Node-Module sind jetzt gesperrt.

Garnversion ist 0.24.6
Node.js-Version ist 7.10.0

Seit der Installation von Yarn sieht Node komplett kaputt aus.

_Update: Ich habe endlich Node / NPM zum Laufen gebracht, aber Yarn hängt immer noch._

Bei mir hängt es hier auf unbestimmte Zeit:

Dies scheint immer noch ein anhaltendes Problem zu sein. Ich kann reproduzieren mit:

[email protected]
[email protected]
[email protected]
[email protected]
amazon [email protected]
[email protected]
[email protected]

scheint erfolgreich zu sein für node@>=6.9.5

Soweit ich das beurteilen kann, scheint das Problem mit Git-Repo-Abhängigkeiten aufgrund einer Race-Bedingung beim Extrahieren des von git archive erzeugten

Ich habe ein Repo erstellt, das das Verhalten zeigt.
https://github.com/andrsnn/yarn-git-dependency-issue

Bisher habe ich das Problem mit diesem Code in ~/.yarn/lib-legacy/util/git.js aufgespürt

_cloneViaLocalFetched(dest) {
    var _this4 = this;

    return (0, (_asyncToGenerator2 || _load_asyncToGenerator()).default)(function* () {
      yield (_child || _load_child()).spawn('git', ['archive', _this4.hash], {
        cwd: _this4.cwd,
        process: function process(proc, resolve, reject, done) {
          const extractor = tar.Extract({ path: dest });
          extractor.on('error', reject);
          extractor.on('end', done);

          proc.stdout.pipe(extractor);
        }
      });
    })();
}

In diesem Schritt scheint das Abhängigkeits-Repository erfolgreich in einen tmp-Ordner /Users/andrsnn/Library/Caches/Yarn/.tmp/06cc8c2b5aba0eca42bd03dabc0d87f6 geklont worden zu sein, der an ein Ziel unter /Users/andrsnn/Library/Caches/Yarn/npm-yarn-dependency-a-1.0.2-fc796525f8a9e3130248520d386f9823502eb6cd extrahiert wird. Scheint kein Netzwerkproblem zu sein.

Gelegentlich wird das 'end'-Ereignis nie vom node-tar Modul ausgelöst. Es scheint an einer 'data'-Ausgabe zu hängen, die einen abgeschnittenen Teil der Datei "garn.lock" aus der Git-Abhängigkeit enthält.

████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████░ 176/177{ '0': 'data',
  '1': <Buffer 30 2e 34 3a 0a 20 20 76 65 72 73 69 6f 6e 20 22 34 2e 30 2e 36 22 0a 20 20 72 65 73 6f 6c 76 65 64 20 22 68 74 74 70 73 3a 2f 2f 72 65 67 69 73 74 72 ... > }
0.4:
  version "4.0.6"
  resolved "https://registry.yarnpkg.com/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz#7c526a52d89b45c45cc690b88163be0497f550cb"

lodash.isstring@^4.0.1:
  version "4.0.1"
  resolved "https://registry.yarnpkg.com/lodash.isstring/-/lodash.isstring-4.0.1.tgz#d527dfb5456eca7cc9bb95d5daeaf88ba54a5451"

lodash.keys@^3.0.0:
  version "3.1.2"
  resolved "https://registry.yarnpkg.com/lodash.keys/-/lodash.keys-3.1.2.tgz#4dbc0472b156be50a0b286855d1bd0b0c656098a"
  dependencies:
    loda

Um das Obige zu bestimmen, habe ich den Ereignis-Emitter umschlossen:

_cloneViaLocalFetched(dest) {
    var _this4 = this;

    return (0, (_asyncToGenerator2 || _load_asyncToGenerator()).default)(function* () {
      yield (_child || _load_child()).spawn('git', ['archive', _this4.hash], {
        cwd: _this4.cwd,
        process: function process(proc, resolve, reject, done) {
          const extractor = tar.Extract({ path: dest });

          var timeout;
          function log(args) {
            return function() {
              console.log(require('util').inspect(args));
              console.log(args[1].toString());
            };
          }
          function debug(emitter) {
              var originalEmitter = emitter.emit;

              emitter.emit = function() {
                  console.log('eventName', arguments[0]);
                  clearTimeout(timeout);
                  timeout = setTimeout(log(arguments), 20000);
                  originalEmitter.apply(emitter, arguments);
              };
          }

          debug(extractor);
          extractor.on('error', reject);
          extractor.on('end', done);


          proc.stdout.pipe(extractor);
        }
      });
    })();
}

Dies könnte sehr gut ein Fehler in node-tar oder eine Abhängigkeit sein, von der es abhängt.

Hoffentlich können andere etwas Licht in die Lösung bringen. Hatte eine schwierige Zeit mit diesem Fehler, der Probleme auf CI-Servern und in der lokalen Entwicklung verursachte.

Vielen Dank für die Repro-Stapes und die Analyse.
Wir hatten das Problem, dass ein Tar zweimal heruntergeladen werden musste, und das verursachte eine Ausnahme
beim Enttarnen.

Das Kernteam wird sich nächste Woche vorher auf Stabilität konzentrieren
freigeben 0.26

Am 28. Mai 2017 um 22:44 Uhr schrieb andrsnn [email protected] :

Dies scheint immer noch ein anhaltendes Problem zu sein. Ich kann reproduzieren mit:

[email protected]
[email protected]
[email protected]
[email protected]
amazon [email protected]
[email protected]
[email protected]

scheint erfolgreich zu sein für node@>=6.9.5

Soweit ich das beurteilen kann, scheint das Problem mit git repo zusammenzuhängen
Abhängigkeiten aufgrund einer Racebedingung beim Extrahieren des von git . erzeugten Tars
Archiv .

Ich habe ein Repo erstellt, das das Verhalten zeigt.
https://github.com/andrsnn/yarn-git-dependency-issue

Bisher habe ich das Problem in diesem Codestück aufgespürt, das sich in befindet
~/.yarn/lib-legacy/util/git.js

_cloneViaLocalFetched(Ziel) {
var _this4 = dies;

return (0, (_asyncToGenerator2 || _load_asyncToGenerator()).default)(function* () {
  yield (_child || _load_child()).spawn('git', ['archive', _this4.hash], {
    cwd: _this4.cwd,
    process: function process(proc, resolve, reject, done) {
      const extractor = tar.Extract({ path: dest });
      extractor.on('error', reject);
      extractor.on('end', done);

      proc.stdout.pipe(extractor);
    }
  });
})();

}

Gelegentlich wird das Ereignis 'end' nie vom Modul node-tar ausgelöst. Es
scheint an einer 'Daten'-Emission zu hängen, die einen abgeschnittenen Teil der . enthält
Garn.lock-Datei aus der Git-Abhängigkeit.

██████████████████████████████████████████████████. ██████████████████████████████████████████████████. ██████████████████████████████████████████████████. ██████████████████████████░ 176/177{ '0': 'Daten',
'1': 0,4:
Version "4.0.6"
gelöst " https://registry.yarnpkg.com/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz#7c526a52d89b45c45cc690b88163be0497f550cb "

lodash.isstring@^4.0.1:
Version "4.0.1"
gelöst " https://registry.yarnpkg.com/lodash.isstring/-/lodash.isstring-4.0.1.tgz#d527dfb5456eca7cc9bb95d5daeaf88ba54a5451 "

lodash.keys@^3.0.0:
Version "3.1.2"
gelöst " https://registry.yarnpkg.com/lodash.keys/-/lodash.keys-3.1.2.tgz#4dbc0472b156be50a0b286855d1bd0b0c656098a "
Abhängigkeiten:
loda

Um das Obige zu bestimmen, habe ich den Ereignis-Emitter umschlossen:

_cloneViaLocalFetched(Ziel) {
var _this4 = dies;

return (0, (_asyncToGenerator2 || _load_asyncToGenerator()).default)(function* () {
  yield (_child || _load_child()).spawn('git', ['archive', _this4.hash], {
    cwd: _this4.cwd,
    process: function process(proc, resolve, reject, done) {
      const extractor = tar.Extract({ path: dest });

      var timeout;
      function log(args) {
        return function() {
          console.log(require('util').inspect(args));
          console.log(args[1].toString());
        };
      }
      function debug(emitter) {
          var originalEmitter = emitter.emit;

          emitter.emit = function() {
              console.log('eventName', arguments[0]);
              clearTimeout(timeout);
              timeout = setTimeout(log(arguments), 20000);
              originalEmitter.apply(emitter, arguments);
          };
      }

      debug(extractor);
      extractor.on('error', reject);
      extractor.on('end', done);


      proc.stdout.pipe(extractor);
    }
  });
})();

}

Dies könnte sehr gut ein Fehler in node-tar oder eine Abhängigkeit sein, auf die es angewiesen ist.

Hoffentlich können andere etwas Licht in die Lösung bringen. Hatte eine schwierige
Zeit mit diesem Fehler, der Probleme auf CI-Servern und in der lokalen Entwicklung verursacht.

—
Sie erhalten dies, weil Sie den Status Öffnen/Schließen geändert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/yarnpkg/yarn/issues/764#issuecomment-304542314 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ACBdWLWEI3Aui9XTLxl7ISk-OaXSQLL0ks5r-eqlgaJpZM4KUM4j
.

Hatte dieses Problem in den letzten Wochen seit der Aktualisierung von Garn und wurde schließlich behoben, indem die Version des Knotens von 6.2.0 auf 6.9.0 . Hoffe das hilft anderen.

Gleiches Problem. Beim "Abholen von Paketen" beim letzten Paket hängen geblieben. Das passiert nicht in jedem Projekt, aber die meisten meiner Projekte haben dieses Problem. Ich habe mein System gestern neu installiert, daher kann es sein, dass die vorherige Version diese Probleme nicht hatte oder das Paket, das Chaos anrichtet, bereits zwischengespeichert wurde oder was auch immer.

Garnversion: v0.24.6
Knotenversion: versucht v8.0.0, v7.10.0, v7.9.0, nichts hat funktioniert
Betriebssystem: macOS 10.12.5

Yarn über brew installiert, Node über nvm, um weitere Versionen von Node auszuprobieren.

// BEARBEITEN
ssh-agent forderte zur Eingabe der Passphrase auf und das Garn hat sie verschluckt. Als ich die Eingabetaste drückte, konnte ich die Frage noch einmal sehen, weil "Ich habe eine falsche Passphrase eingegeben"

@vass-david mit deiner neuesten Bearbeitung, hast du das Problem immer noch?
@andrsnn - Ich habe versucht, das Problem mit Ihrem Repository mit verschiedenen Kombinationen von Node 4.8, Node 6.10, Node 7, Node 8 und Garn 0.24, 0.25, Master zu reproduzieren. Ich konnte das Problem nicht reproduzieren. Kannst du bestätigen, dass es nicht mehr da ist?

@vass-david @JulianLeviston können Sie strace für den Stickgarnprozess verwenden, um herauszufinden, was genau geklebt ist? Hier ist eine tolle Anleitung, wie man es benutzt.

@BYK nein, da ich jetzt verstehe, woran es liegt und dass ich einfach meine Passphrase für ssh eingeben sollte. Auf der anderen Seite sollte es diese Aufforderung nicht schlucken. Wenn der Benutzer sich dessen nicht bewusst ist, wird er möglicherweise nie bemerken, dass dies passiert ist.
@kirs brauchst du das noch, auch wenn ich jetzt weiß, woran es liegt?

@kirs Mine funktioniert, seit ich das Garn aktualisiert habe.

Hatte das gleiche Problem. Das Löschen des node_modules Ordners und das erneute Ausführen von yarn hat bei mir funktioniert!

ich versuche

rm yarn.lock
yarn

Für mich geht das

Ich hatte das Problem mit node 7.10.0 und yarn v0.24.6 im Docker, habe aber festgestellt, dass der Ordner node_modules versehentlich gedrückt wurde. Das Entfernen des Ordners node_modules und yarn clear cache das Problem behoben.

Dies geschieht in großen Paketen. Es kann schön sein, wenn bei einer bestimmten Größe eine Warnung ausgegeben wird.

Ich hatte das gleiche Problem. Ich glaube, es ist ein Versionskonflikt mit dem Knoten. Mein Projekt verwendete v81.2. Ich habe einfach auf die richtige Version umgestellt und das Garn hat aufgehört zu hängen:
nvm use v7.4

Habe dieses Problem immer noch in v1.9.4, aber wie bei #5055

Hatte das gleiche Problem:
Betriebssystem: OSX 10.14.1 (Mojave)
Knoten: 10.9.0
Garn: 1.12.3

Sieht so aus, als ob es sich wahrscheinlich um eine beschädigte Datei "garn.lock" handelt. Folgendes wurde behoben:

yarn cache clean
rm yarn.lock
rm - r node_modules

yarn

Gleicher Fehler

Betriebssystem: OSX 10.14.1 (Mojave)
Knoten: 12.3.1
Garn: 1.16.0

Ich habe es gelöst, indem ich zu einem anderen Netzwerk (Hotspot) gewechselt habe. Ich schätze, unsere Büronetzwerk-Firewall hatte einige Einschränkungen.

Gleicher Fehler

Betriebssystem Windows 10

Meine Lösung: Motherboard-Treiber aktualisieren

Hatte das gleiche Problem:
Betriebssystem: Ubuntu 18.04
Knoten: v8.10.0
Garn: 1.17.3

Ich habe es wie folgt gelöst:
yarn cache clean

dann nochmal den install-Befehl probiert und es funktioniert. Obwohl es einige Minuten dauert, bis der Vorgang abgeschlossen ist, haben Sie Geduld, es wird funktionieren. In meinem Fall dauerte es 10 Minuten (abhängig von der Internetgeschwindigkeit), um den Vorgang abzuschließen.

Garn aktualisieren hat nicht geholfen. In meinem Fall war eines der Pakete zu groß und konnte vor dem Timeout nicht heruntergeladen werden

Lösung ist die Installation mit
yarn install --network-timeout 100000

oder fügen Sie die .yarnrc-Datei zu Ihrem Projekt hinzu und fügen Sie diese ein:
network-timeout 500000

Ich auch:

yarn install v1.22.4
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[###############################################################################################] 1908/1909

System:
    OS: macOS 10.15.3
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Memory: 192.86 MB / 8.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.13.1 - ~/.nvm/versions/node/v12.13.1/bin/node
    Yarn: 1.22.4 - ~/Documents/youpendo-app-bareworkflow/node_modules/.bin/yarn
    npm: 6.12.1 - ~/.nvm/versions/node/v12.13.1/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.3 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 28, 29
      Build Tools: 28.0.3, 29.0.2
      System Images: android-28 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 3.6 AI-192.7142.36.36.6392135
    Xcode: 11.3.1/11C504 - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_232 - /usr/bin/javac
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: ^4.8.0 => 4.9.0
    react: 16.11.0 => 16.11.0
    react-native: 0.62.2 => 0.62.2
  npmGlobalPackages:
    *react-native*: Not Found

Gleiches Problem!
Warum ist dieser geschlossen?

[email protected]
Node.js v12.18.2.

Für dieses Repository ausgeführt:
https://github.com/metabase/metabase

Windows 10

Lange Rede, kurzer Sinn, überprüfen Sie Ihr VPN. Ist es verbunden?

Ein Kollege und ich haben das gleiche Problem behoben. Es würde nur bei einem bestimmten Paket anhalten, obwohl wir uns nicht sicher waren, welches Paket.

Grundsätzlich hatte die Person ihren Computer zuvor neu gestartet und musste beim erneuten Starten auch ein neues Passwort für ihr VPN einrichten. Ihr VPN hat sich also nie automatisch wieder verbunden. Da es sich um ein "Garnproblem" handelte, dachte ich nicht viel über das VPN nach. Aber wir haben ein Firmenrepo mit ein paar Paketen und da hing es. :/