Ich habe Verknüpfungsabhängigkeiten mit dieser https://github.com/macdja38/pvpsite/blob/master/package.json unter Windows 10 von einer SSD mit einem anständigen i7 über 200 Sekunden.

Es scheint, dass das Leistungsproblem durch Windows Defender verursacht werden kann, das es deaktiviert, während möglicherweise nicht empfohlen wird, 200 Sekunden auf einen Wert zu reduzieren, der näher an 50 liegt.

Ich denke, dass es eine bessere Lösung geben sollte, als die Sicherheit zu verringern.

Einige andere Benutzer haben bestätigt, dass das Deaktivieren nur im Stammverzeichnis Ihres Projekts funktioniert. Ich kann dies jedoch nicht bestätigen, da sich Windows Defender bei diesem Versuch selbst beschädigt hat.

Ich habe das gleiche Problem mit Git Repo mit ungefähr 30 Abhängigkeiten.
Windows 10
Knoten v5.5.0
Garn 0.16.1

Durch Deaktivieren von Windows Defender wurde die Verknüpfungszeit erheblich verkürzt

Sollte wohl von dieser PR "gelöst" werden?

Ja, hier können wir leider nicht viel tun :( Virenscanner scannen alle Dateien, und das npm-Ökosystem verfügt über viele kleine Dateien. Kleine Dateien haben im Allgemeinen einen etwas höheren Overhead für NTFS als andere Dateisysteme wie EXT4 oder ZFS. aber es wird durch Virenscanner verschärft.

Trotzdem sollte Yarn immer noch schneller als npm sein, es wird einfach nicht so schnell sein wie unter Linux oder Mac.

Ich bin auf einem Mac ohne installierte Antivirenscanner. Aber ich sehe immer noch das gleiche Problem, da das Verknüpfen selbst mit einer einfachen Angular-JS-App viel Zeit in Anspruch nimmt.

Ich habe auch dieses Problem. Unter Ubuntu dauerte es 174 Sekunden.

Ich hatte dieses Problem erst, nachdem ich ein Upgrade von 0.17.8 auf 0.17.19 . Mac ohne Virenschutz.

Seltsam ist auch, dass ich jedes Mal, wenn ich ein Paket lösche, einen Verknüpfungsprozess ausführen muss. Npm macht das schneller. Und das Verknüpfen dauert wirklich lange.

Dies kann mit diesem package.json (auf Heroku) reproduziert werden:

{
  "name": "yarn-link-slowness",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "axios": "^0.15.3",
    "lodash": "^4.17.2",
    "react": "^15.4.1",
    "react-dom": "^15.4.1",
    "react-player": "^0.12.1",
    "react-redux": "^4.4.6",
    "react-router": "^3.0.0",
    "react-router-redux": "^4.0.7",
    "react-scripts": "^0.8.4",
    "redux": "^3.6.0",
    "redux-auth-wrapper": "^0.9.0",
    "redux-logger": "^2.7.4",
    "redux-promise-middleware": "^4.2.0",
    "redux-thunk": "^2.1.0"
  },
  "engines": {
    "node": "7.2.1",
    "yarn": "0.17.8"
  }
}

Mit Garn 0.17.8 dauert die Installation 37s. Mit Garn 0.17.10 dauert die Installation 97 Sekunden. Keine weiteren Änderungen (jedes Mal neue Heroku-Apps).

✨ Fertig in 45.10s.

    "autoprefixer": "6.3.6",
    "babel-core": "6.7.6",
    "babel-jest": "13.0.0",
    "babel-loader": "6.2.4",
    "babel-plugin-transform-class-properties": "6.9.1",
    "babel-plugin-transform-object-rest-spread": "6.8.0",
    "babel-preset-es2015": "6.6.0",
    "babel-preset-react": "6.5.0",
    "bluebird": "3.3.5",
    "cardmask": "github:aj0strow/cardmask#v1.0.0",
    "chai": "3.5.0",
    "classnames": "2.2.5",
    "copy-webpack-plugin": "2.1.3",
    "core-js": "2.4.1",
    "css-loader": "0.23.1",
    "enzyme": "2.3.0",
    "file-loader": "0.8.5",
    "force-case-sensitivity-webpack-plugin": "0.1.1",
    "jest": "13.0.0",
    "jest-cli": "13.0.0",
    "json-loader": "0.5.4",
    "lodash": "4.11.1",
    "moment": "2.13.0",
    "ms": "0.7.1",
    "node-sass": "3.4.2",
    "postcss-loader": "0.9.1",
    "raw-loader": "0.5.1",
    "react": "15.2.0",
    "react-addons-css-transition-group": "15.2.0",
    "react-addons-test-utils": "15.2.0",
    "react-css-transition-replace": "2.0.1",
    "react-dom": "15.0.1",
    "react-redux": "4.4.5",
    "react-router": "2.3.0",
    "react-textarea-autosize": "4.0.3",
    "recompose": "0.20.2",
    "redux": "3.5.1",
    "redux-actions": "0.10.0",
    "redux-thunk": "2.0.1",
    "reselect": "2.5.3",
    "sass-loader": "3.2.0",
    "sinon": "1.17.4",
    "style-loader": "0.13.1",
    "webpack": "1.13.0",
    "webpack-dev-server": "1.14.1",
    "whatwg-fetch": "1.0.0",
    "zxcvbn": "4.3.0"

Kann jemand erklären, was Garn im Schritt "Abhängigkeiten verknüpfen" genau macht?
Da die maximale Anzahl in diesem Schritt von ~ 1000 bis ~ 65000 für dasselbe Projekt auf verschiedenen Maschinen variiert. Was bedeutet diese Zahl?

Ich habe auch dieses Problem. Das Hinzufügen einer Abhängigkeit mit yarn add scheint "Abhängigkeiten verknüpfen" auszulösen und dauert ewig. Musste vorerst wieder auf npm umschalten.

Knoten: 6.9.2
Betriebssystem: Windows 10

Knoten: 7.3.0
Betriebssystem: Windows 10 64
Gleiche für mich

Hier gilt das gleiche. Links 23420 ... etwas und dauert an einem guten Tag ungefähr eineinhalb Minuten.

Garn 0.19.1
NodeJS 7.3.0
Windows 10

yarn add moment dauert 105 Sekunden. Es hat keine Abhängigkeiten. : /

BEARBEITEN: Durch Deaktivieren von Windows Defender wird die Zeit auf ~ 30 bis ~ 50 Sekunden reduziert. Ich habe versucht, das Verzeichnis auszuschließen, in dem ich arbeite, aber das schien nicht zu helfen.

Ich habe gerade eine neue Kopie der Create-React-App ausgeführt und es dauerte 876,37 Sekunden. Ich verstehe, dass Sie nicht viel / keine Kontrolle darüber haben, wie Antivirus funktioniert, aber meine Erfahrung mit NPM und CRA war unter Windows viel schneller.

Verwenden Sie unter Windows 10 nur die Ubuntu-Bash-Shell als allgemeinen Rat.

Verwenden Sie unter Windows 10 nur die Ubuntu-Bash-Shell als allgemeinen Rat.

Die Festplatten-E / A ist im Windows-Subsystem für Linux extrem langsam. Dies ist derzeit eine bekannte Einschränkung

Aber meine Erfahrung mit NPM und CRA war unter Windows viel schneller.

@ JeffBaumgardt - Interessant ... Garn ist unter Windows langsamer, sollte aber immer noch schneller als npm sein!

@ Daniel15 wahrscheinlich sollte es sein, aber es ist nicht. Knoteninstallationen und -deinstallationen waren für mich kleiner. Also würde ich npm add <packages> --save-dev , yarn.lock löschen und Garn laufen lassen und das ist schneller als yarn add <packages> -D ein einziges Mal laufen zu lassen. Nun, da alle auf Garn sind, möchte ich natürlich nicht das Schloss löschen und alle zwingen, ihr Bundle zu aktualisieren. Stattdessen war Folgendes großartig:

cc @echobnet

Für alle unter Windows 10 + Windows Defender

1. Klicken Sie zuerst auf Einstellungen

   

2. Scrollen Sie nach unten zu Ausschlüssen

   

3. Führen Sie yarn cache dir , um den Speicherort Ihres Cache-Ordners abzurufen

   • Fügen Sie diesen Cache-Ordner zur Ausschlussliste hinzu
   • Fügen Sie Ihren Projektordner node_modules zur Ausschlussliste hinzu

4. Beschleunigung für ein Reaktionsprojekt x 3-10

@SleeplessByte oder Sie können einfach yarn und node zu ausgeschlossenen Prozessen hinzufügen.

Nicht nur ein Problem unter Windows. Ich habe auf meinem Mac Pro schreckliche Linkzeiten gesehen.

Betriebssystem: OS X 10.11.6 (El Capitan)
Knoten: 7.6.0
Garn: 0,20,3

Ich kann bestätigen, dass es auch auf Mac 10.12.3 sehr langsam ist. Nicht im Zusammenhang mit Windows.

Und es scheint, dass mein Setup _way_ langsamer ist als andere in diesem Thread. Garn versucht manchmal, in kleinen Projekten rund 600.000 Dateien zu verknüpfen. Dies kann länger als 30 Minuten dauern. Ich versuche es derzeit mit einem sauberen Cache und jede Nacht (v0.22.0-20170226.1626). Ich verwende die offizielle Registrierung sowie eine benutzerdefinierte private Registrierung für bestimmte Pakete mit Gültigkeitsbereich. Meine Kollegen leiden jedoch nicht unter diesem Problem, sodass ich nicht denke, dass die benutzerdefinierte private Registrierung das Problem ist (und das Abrufen von Paketen ohnehin bereits abgeschlossen ist). Wir haben auch einige relative Dateien mit dem Protokoll path: in unserem package.json .

Ich habe viele Probleme bei der Installation von https://github.com/google/material-design-icons, das viele kleine Dateien enthält, die auch für andere Benutzer problematisch zu sein scheinen (https://github.com/google/). Material-Design-Icons / Issues / 518). Ich weiß nicht, ob meine Hardware bei der Verarbeitung vieler kleiner Dateien oder Ähnlichem defekt ist oder ob dies überhaupt damit zusammenhängt. Wieder haben meine Kollegen nicht so viele Probleme bei der Installation von https://github.com/google/material-design-icons wie ich.

Aktualisieren

Ich bin mir nicht sicher ... es sieht so aus, als würde ein Paket mit file: installiert und ein Modul in den Cache gestellt, das node_modules/ und andere Dinge enthält. Dies ist wirklich ein Problem, wenn Sie mehrere Beispiele haben, die alle ihre eigenen node_modules/ . Es scheint, dass .npmignore usw. für file: Installationen ignoriert wird. Dies läuft wahrscheinlich auf https://github.com/yarnpkg/yarn/issues/2165 hinaus , wenn die Lösung darin besteht, lokal aufgelöste Dateien überhaupt nicht zwischenzuspeichern. Wenn ich meinen Cache öffne ( $ yarn cache dir ) und nach Modulen suche, warum mit file: installiert werden und diese ein node_modules Verzeichnis oder andere große Verzeichnisse enthalten, kann ich das linking phase beschleunigen

[3/4] Linking dependencies...
Done in 947.71s. 

Musste so lange warten, bis ein neues Paket mit yarn add ... hinzugefügt wurde
Win7 / w Yarn v0.21.3
Ich habe ein material-design-icons -Paket in meiner App.
Ich denke, dieser ist verwandt https://github.com/yarnpkg/yarn/issues/990

@kuncevich alles funktioniert gut auf meiner Seite, während der Laufzeit von Ihnen Garn hinzufügen Start Task-Manager Strg + Alt + Esc Überprüfen Sie, welches Programm die höchste CPU verwendet, in meinem Fall war es Antivirus, so musste ich nicht nur die% appdata% Verzeichnisse ausschließen, sondern Auch das Projektverzeichnis und die Dinge wurden wieder schnell

@kuncevic Sie könnten von dem Fehler betroffen sein, den ich unter Windows gefunden habe: https://github.com/yarnpkg/yarn/pull/2958

Im Wesentlichen kann Garn für jede Operation immer jede Datei in node_modules kopieren.

@asolopovas in meinem Fall ist es node.exe wie 10-26 % :

Mein AV ist kein Problem, auch wenn ich es gerade vollständig ausgeschaltet habe. Ich kann keine Verbesserungen der Garngeschwindigkeit feststellen.

Knoten -v 6.9.2

@kuncevic aktualisiert Ihren Knoten auf 7 und prüft, ob dies die Dinge schneller macht, andernfalls zeigt @vbfox in die richtige Richtung.

Im Wesentlichen kann Garn für jede Operation immer jede Datei in node_modules kopieren.

@vbfox könnten Sie

@danpalmer Die Verknüpfungsphase funktioniert im Wesentlichen in 3 großen Schritten:

1. Finden Sie jede Datei, die sich in node_modules
2. Überprüfen Sie diese Liste im Vergleich zu den bereits vorhandenen und finden Sie heraus, was aus dem Cache in node_modules kopiert werden muss
3. Mach die Kopie

Aufgrund eines libuv / nodejs-Fehlers ( utime wird von Garn verwendet und der Fehler besteht darin, dass die Millisekunden auf Null gesetzt werden) werden Dateien, die von Garn in einem vorherigen Lauf kopiert wurden, immer als unterschiedlich befunden (Version im Cache hat eine normale Änderungszeit, aber alle Dateien in node_modules haben eine Millisekunden-Version von Null), sodass Phase 2 immer meldet, dass sich alles geändert hat.

Da der Fehler in Knoten 7.1 behoben ist, ist er ziemlich einfach zu beheben, wenn Sie nicht auf LTS beschränkt sind (Der erste Garnvorgang auf einem Repo ist langsam, da die Dateien mit dem Buggy utime aber alle folgenden sind viel schneller). Meine PR behebt dies im Wesentlichen, indem sie den Millisekunden-Teil der Dateizeiten unter Windows beim Vergleich ignoriert.

Beim Kopieren des gesamten Pakets handelt es sich nicht um einen Vorgang, der auf den aktuellen AFAIK-Dateisystemen ausgeführt wird. Alle arbeiten auf Dateiebene.
Das beste Windows-Angebot ist eine FileCopy-API (ich habe eine PR, um sie in Garn zu verwenden: https://github.com/yarnpkg/yarn/pull/2960), aber sie ist nur ein bisschen schneller als die native NodeJS-Stream-API.

Was das Symlinking betrifft, weiß ich nicht, warum es nicht gemacht wird. Ich kenne mich mit Javascript-Paketmanagern nicht gut aus. (Einige Änderungen an den Paketdateien wurden vorgenommen, z. B. das Entfernen von Testordnern, aber das Symlinking einzelner Dateien würde dies nicht anders machen.) Aber da dies auch unter Linux / Macos nicht der Fall ist (wo es viel häufiger vorkommt als unter Windows), kann es einen guten Grund geben.

Mein Experiment mit dem Upgrade auf Node 7.8.0 : https://github.com/yarnpkg/yarn/issues/990#issuecomment -290288375

1. Find every file that need to be in node_modules
2. Check this list versus what is already there and find what need to be copied around from cache to node_modules
3. Do the copy

Wenn man bedenkt, dass die meisten Leute beim Wechsel zwischen Zweigen eine Vielzahl von Bibliotheken neu verknüpfen - gibt es vielleicht einen besseren Weg, dies zu tun?

Könnten Sie eine eindeutige ID für jeden Build von node_modules erstellen und dann das gesamte Verzeichnis aus einem Cache mit sym verknüpfen? Auf diese Weise verbindet das Hin- und Herwechseln von Zweigen wirklich nur verschiedene node_modules

Zugegeben, Sie werden viel auf die Festplatte schreiben, da Sie jetzt jede Version von node_modules Sie stoßen, aber könnte es dort Optimierungen geben, um Sym-Links zu Verzeichnissen zu erstellen, so dass Sie wirklich nur Sie sind einen Baum von Sym-Links speichern?

Verzeihen Sie mir, dass ich naiv bin. Ich bin nicht besonders gebildet, wenn es um Unix- und noch weniger Windows-Dateisysteme geht, aber ich würde mich gerne als Lernübung damit befassen und versuchen, eine bereitzustellen Proof of Concept dieser Idee, wenn sie nicht offensichtlich in irgendeiner Weise fehlerhaft ist.

pnpm und ied verwenden einige der Techniken, die Sie erwähnen. Ich glaube, sie sind nicht ganz sicher, haben sie vor einiger Zeit ausprobiert, aber sie haben entweder Probleme unter Windows verursacht oder waren nicht so schnell wie Garn.

Auch ich hatte gerade sehr lange Zeit, um eine App mit Garn zu erstellen
Windows Server 2012
Knoten 7.9.0
Garn 0,22
Fertig in 554.08s.

In anderen Fällen ist es jedoch viel schneller, wenn keine React-Installationen enthalten sind

Ich beobachte in letzter Zeit keine lange Verknüpfungszeit. Laufen
Garn - v0.23.2
Knoten - 6.10.2 oder 7.9.10 (mit nvm wechseln)

Versuchte dies auf einem Mac und Archlinux (Manjaro)

Ich kann bestätigen, dass das Hinzufügen von Knoten und Garn zu den Windows Defender-Ausschlüssen die Verknüpfungszeit auf meinem Windows-Computer um etwa 60% verkürzt hat.

+1

[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 180.22s.

Der Wechsel zu Knoten 7.9.0 hat es für mich nicht beschleunigt. Das Hinzufügen von 'Garn', 'Knoten' und 'npm' zu Windows Defender (mit und ohne EXE-Erweiterungen, nicht sicher, was erforderlich ist) hat es für mich dreimal beschleunigt, aber immer noch 50% länger als die Installation von npm.

Es scheint mir auch keine gute Idee zu sein, jeglichen Schutz von irgendetwas zu entfernen, das auf dem Knoten läuft, oder von Paketen, die installiert werden ...

Hinzufügen meiner Erfahrung - Durch Hinzufügen von node.exe / yarn.exe zur Ausnahmeliste von Windows Defender konnte die Garninstallationszeit halbiert werden (von 60 auf 30 Sekunden).

Ich sehe dies auch, was es frustrierend macht, während der Entwicklung eines Pakets schnell zu iterieren, da das Aktualisieren eines einzelnen Pakets so lange dauert.

yarn install v0.24.5
[1/4] Resolving packages...
[2/4] Fetching packages...
warning [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...
Done in 338.20s.

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:    14.04
Codename:   trusty

  "dependencies": {
    "autoprefixer": "^6.7.7",
    "axios": "^0.16.1",
    "babel-core": "^6.24.1",
    "babel-loader": "7.x",
    "babel-preset-env": "^1.4.0",
    "coffee-loader": "^0.7.3",
    "coffee-script": "^1.12.5",
    "compression-webpack-plugin": "^0.4.0",
    "css-loader": "^0.28.0",
    "element-ui": "^1.3.3",
    "extract-text-webpack-plugin": "^2.1.0",
    "file-loader": "^0.11.1",
    "glob": "^7.1.1",
    "js-yaml": "^3.8.3",
    "node-sass": "^4.5.2",
    "path-complete-extname": "^0.1.0",
    "postcss-loader": "^1.3.3",
    "postcss-smart-import": "^0.6.12",
    "precss": "^1.4.0",
    "rails-erb-loader": "^5.0.0",
    "rails-ujs": "^5.1.0",
    "sass-loader": "^6.0.3",
    "style-loader": "^0.16.1",
    "turbolinks": "^5.0.3",
    "vue": "^2.3.0",
    "vue-loader": "^12.0.2",
    "vue-router": "^2.5.3",
    "vue-template-compiler": "^2.3.0",
    "webpack": "^2.4.1",
    "webpack-manifest-plugin": "^1.1.0",
    "webpack-merge": "^4.1.0"
  },
  "devDependencies": {
    "element-theme": "*",
    "element-theme-default": "^1.3.3",
    "eslint": "^3.19.0",
    "eslint-config-airbnb": "^14.1.0",
    "eslint-plugin-import": "^2.2.0",
    "eslint-plugin-jsx-a11y": "^4.0.0",
    "eslint-plugin-react": "^6.9.0",
    "nodemon": "^1.11.0",
    "webpack-dev-server": "^2.4.5"
  }

:(

Hinzufügen meiner +1 auf Mid-Summer 2010 MacBook Pro (Sierra 10.12.4) mit Garn 0.24.5, Knoten 7.10.0 und npm 4.2.0:

λ Garn Bootstrap-Sass hinzufügen
Garn hinzufügen v0.24.5
[1/4] 🔍 Auflösen von Paketen ...
[2/4] 🚚 Pakete holen ...
[3/4] 🔗 Abhängigkeiten verknüpfen ...
[4/4] 📃 Neue Pakete bauen ...
Erfolg Gespeicherte Sperrdatei.
Erfolg 1 neue Abhängigkeit gespeichert.
└─ [email protected]
✨ Fertig in 123,52s.

"dependencies": {
    "@angular/animations": "^4.1.3",
    "@angular/common": "^4.0.0",
    "@angular/compiler": "^4.0.0",
    "@angular/core": "^4.0.0",
    "@angular/forms": "^4.0.0",
    "@angular/http": "^4.0.0",
    "@angular/material": "^2.0.0-beta.5",
    "@angular/platform-browser": "^4.0.0",
    "@angular/platform-browser-dynamic": "^4.0.0",
    "@angular/router": "^4.0.0",
    "bootstrap-sass": "^3.3.7",
    "core-js": "^2.4.1",
    "font-awesome": "^4.7.0",
    "material-design-icons": "^3.0.1",
    "materialize-css": "^0.98.2",
    "rxjs": "^5.1.0",
    "zone.js": "^0.8.4"
},
"devDependencies": {
    "@angular/cli": "1.0.1",
    "@angular/compiler-cli": "^4.0.0",
    "@types/jasmine": "2.5.38",
    "@types/node": "~6.0.60",
    "codelyzer": "~2.0.0",
    "jasmine-core": "~2.5.2",
    "jasmine-spec-reporter": "~3.2.0",
    "karma": "~1.4.1",
    "karma-chrome-launcher": "~2.0.0",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "^0.2.0",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.1.0",
    "ts-node": "~2.0.0",
    "tslint": "~4.5.0",
    "typescript": "~2.2.0"
}

Das Zurückschalten auf npm install hat das Problem für mich behoben. Ich habe - u'stream ': u' [3/4] Verknüpfungsabhängigkeiten im Garn und keinen Fehler im NPM.

Vielleicht ist mit dem neuesten Build etwas schiefgegangen

Führen Sie dies über Docker aus.

@iwarner npm 5.0 ist eine gute Wahl.

Ich führe Garn in Vagrant (Ubuntu Xenial) und von Jenkins. Es gibt zwei Unterprojekte mit package.json.
npm -v 3.10.10
Knoten -v 6.10.1
Garn installieren v0.21.3

Wir haben vor einiger Zeit von npm auf Garn umgestellt, weil wir ein Timeout-Problem hatten (4 Stunden waren nicht genug) für die Installation von npm.

Jetzt arbeitet Garn ungefähr 30% der Zeit, aber für 70% der Zeit bekommen wir irgendwann eine 4-Stunden-Zeitüberschreitung. Es kann sein, dass das erste Garn installiert wird oder das zweite, oder dass beim Ausführen von Komponententests (Scherz) eine Zeitüberschreitung auftritt.

Dies ist ein Duplikat von https://github.com/yarnpkg/yarn/issues/990 . Es gibt eine Vergleichstabelle und es scheint, als hätten die neuesten Versionen von Yarn dort einige gute Fortschritte gemacht.
Wenn es immer noch ein Problem gibt, reichen Sie bitte ein neues Problem mit Repro-Schritten und einem Vergleich mit dem neuesten npm ein

success Saved lockfile.
Done in 1737.79s.

Ubuntu 16.04
i5, 8 GB RAM

:(

Windows 10 v 1709 + SSD + PowerShell + Knoten 6.12.2:
Die Garninstallation war bis zum letzten Paket schnell und schien bei einem Vorinstallationsbefehl hängen zu bleiben.
Befolgen Sie die Anweisungen hier, um Ausschlüsse für Windows Defender hinzuzufügen, aber ich habe auch meine Quelle in% USERPROFILE% source auschecken lassen, was sie drastisch verlangsamte. Auschecken in c: Es war haufenweise schneller.

Irgendeine Lösung für die Ubuntu-Plattform? Ich muss buchstäblich zweimal überlegen, bevor ich ein Paket hinzufüge.

Ubuntu ist super schnell für mich, überhaupt keine Langsamkeit.

Am Freitag, 23. Februar 2018, 11:13 Uhr schrieb Basant Besra, [email protected] :

Irgendeine Lösung für die Ubuntu-Plattform? Ich muss buchstäblich zweimal überlegen
ein Paket hinzufügen.

- -
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/1496#issuecomment-367897260 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AAcMheTtAYOsXcrnej_f2F8bY5D3nDT2ks5tXizngaJpZM4Kh3OZ
.

Das ist super nervig. Ich habe buchstäblich eine Zeile in einem Modul geändert, sie unter einer neuen Version erneut veröffentlicht und yarn add module hat über 5 Minuten gedauert.

Es wäre schneller, meine Pakete manuell mit einem Texteditor zu aktualisieren

Ich habe auch dieses Problem:

success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ @material-ui/[email protected]
info All dependencies
└─ @material-ui/[email protected]
Done in 93.43s.

Mein System ist Linux manjaro 4.14.31-1-MANJARO #1 SMP PREEMPT Wed Mar 28 21:42:49 UTC 2018 x86_64 GNU/Linux

NodeJS: v9.9.0
Garn: v1.5.1

Auch super langsam für mich Done in 254.32s.

Knoten v8.10.0
npm 5.6.0

OSX 10.11.6 (15G19009)

Ich bin zurück zu [email protected] gewechselt,

Wir verwenden die Offline-Cache-Funktion, um dieses Problem die meiste Zeit zu vermeiden. Sobald sich jedoch die Datei package.json oder die Garn-Sperrdatei ändert, kehren wir zu diesem Problem zurück. Das Verknüpfen dauert auf unserem Linux-Computer 10 Minuten. Ich denke nicht, dass dies Windows-spezifisch ist.

Dies ist definitiv kein Windows-Problem (was aus allen Posts von Personen auf Nicht-Windows-Computern ersichtlich sein sollte)!

Ich bin auf macOS High Sierra 10.13.4 und verwende Knoten 10.1.0 (npm 5.6.0) und Garn 1.6.0. Mit Garn dauerte die Installation einer Abhängigkeit ca. 40 Sekunden. Ich wechselte zu npm und es dauerte ungefähr 10 Sekunden. Ich bleibe vorerst bei npm.

Gleiches gilt für unsere Centos 7 Box. Irgendwelche Updates dazu?
Garn: v1.7.0
npm: v5.7.1

es passiert mir auf 1.9.2 auf Mac auf Knoten 10

Für mich unter macOS HighSierra verursachte Avast FileShield das Problem. Ich habe die ausführbare Garndatei als ausgeschlossener Pfad mit which yarn hinzugefügt. Es scheint jetzt in Ordnung zu sein, ich werde ein Update geben, wenn es zurückkommt.

es passiert mir auf 1.9.2 auf Mac auf Knoten 10

Hier gilt das gleiche. Garn 1.9.2, Knoten 10.6.0 in High Sierra.

@bestander Dies ist kein Windows-Problem. Ich kann mit Yarn 1.9.4 auf meinem Mac repro. Dieses Problem sollte erneut geöffnet werden.

@davidgoli , öffnen

Garn ist für jede Umgebung, in der ich es betrieben habe, ziemlich langsam. Debian, Mac, Windows. Die neue Ausgabe war offen? oder der RFC, der node_modules loswird, wird dies lösen?

Ich habe das gleiche Problem, wechsle bereits zu npm, habe aber immer noch einen Fehler

Ich habe auch das gleiche Problem mit Garn. Irgendeine Lösung gefunden?

Dies ist ein Duplikat von # 990, es gibt eine Vergleichstabelle und es scheint, als hätten die neuesten Versionen von Yarn dort einige gute Fortschritte gemacht.
Wenn es immer noch ein Problem gibt, reichen Sie bitte ein neues Problem mit Repro-Schritten und einem Vergleich mit dem neuesten npm ein

Dies ist kein Duplikat, dieses Problem betrifft nicht nur Windows. Das Öffnen einer neuen Ausgabe würde zu einem Kontextverlust führen.

Ich habe das gleiche Problem!

yarn install
yarn install v1.16.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] 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.
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.
[4/5] Linking dependencies...
[###############################################---------------------------------------------------------------------------------------------] 22778/67399

Done in 179.59s.

MacOS / Docker

Vagrant 2.2.4
Gast: Ubuntu 18.10 (GNU/Linux 4.18.0-25-generic x86_64)
Gastgeber: MacOS 10.14.5 Mojave

Garn 1.16.0
npm 6.9.0

MacBook Pro (Retina, 13 Zoll, Anfang 2015)
Prozessor 2,7 GHz Intel Core i5
Speicher 16 GB 1867 MHz DDR3

yarn install v1.16.0
[1/4] Resolving packages...
[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...
success Saved lockfile.
Done in 1552.45s.

Ich kann yarn install nicht ausführen, ohne mehr als 25 Minuten Produktivität zu verlieren. Es ist absurd. Ich kaufe nicht, dass dies ein Windows-Problem ist. Es scheint mir sehr wahrscheinlich, dass beim Ausführen in einer virtualisierten Umgebung ein Problem auftritt. Vielleicht mit synchronisierten Ordnern / Überprüfen des Dateistatus auf dem Gastbetriebssystem zu tun?

Garn v1.17.3
Knoten v10.16.3
npm 6.9.0

Windows

Ich habe versucht, den Speicherort meines App-Projektordners im selben Festplattenbereich wie yarn cache dir .
Garn-Cache-Verzeichnis -> C: BenutzerAppDataLocalYarnCachev4

Das Ergebnis:
alter Ort -> D: myApp Done in 747.17s.
neuer Speicherort -> C: myApp Done in 488.97s.

C und D sind dieselbe physische Festplatte.

Mac

Mac ist jedoch schneller als Windows Done in 121.37s

Ich denke, der Engpass ist die Lese- / Schreibgeschwindigkeit der Festplatte?

OS X 10.15
Garn v1.22.4
Knoten v12.13.0
npm v6.12.0

Ich erlebe das immer noch. Das Projekt befindet sich in einem bereitgestellten verschlüsselten Disk-Image. Die Installation eines einzelnen Pakets dauert mit einem relativ kleinen package.json einige Minuten. Ich habe es nicht bewertet, aber npm fühlt sich viel schneller an.

Bearbeiten: Es stellte sich heraus, dass das Ändern des Standard-Cache-Ordners des Garns auf demselben verschlüsselten Volume dies für mich behoben hat.

Ich bin auch davon betroffen und renne:

Betriebssystem: Ubuntu 18.04.2
Garn: 1.22.4
Knoten: 14.7.0
NPM: 6.14.7