Yarn: Native Pakete, die jedes Mal neu erstellt werden

Kann dies unter Mac OSX (10.11.6) nicht reproduzieren, ist also möglicherweise ein Ubuntu-spezifisches Problem?

Ich konnte unter Windows 10 repro, aber nur einmal. Das zweite Mal, als ich "Garn" lief, wurden die nativen Bibliotheken nicht neu erstellt. Seltsam.

Ich habe noch ein bisschen damit gespielt und mir ein paar Details ausgedacht:

1. Wenn ich yarn add leveldown bcrypt ausführe, wird leveldown als erstes Element in der Liste kompiliert und der Hash in node_modules/.yarn-integrity entspricht 595306... wenn er fertig ist (Schnitt) der Kürze halber nehme ich an, dass dies eine Prüfsumme ist, die bestimmt, ob etwas getan werden muss). Wenn ich jetzt wieder nur yarn ausführe, werden beide Pakete neu erstellt, wobei bcrypt als erstes in der Liste kompiliert wird (die Reihenfolge ist unterschiedlich). Die resultierende Prüfsumme entspricht cbe480... . Ein späterer Aufruf von yarn die Pakete nicht neu und die Prüfsumme bleibt gleich. Dies widerspricht meinem ursprünglichen Bericht (ich habe wahrscheinlich irgendwo einen Fehler gemacht), stimmt aber mit dem @ Daniel15 sah.
2. Wenn ich die Reihenfolge der Pakete von Anfang an umkehre ( yarn add bcrypt leveldown ), steht bcrypt erster Stelle in der Liste und die resultierende Prüfsumme entspricht sofort cbe480... . Ein späterer Aufruf von yarn die Pakete nicht neu.
3. Das bcrypt -Paket wird immer zuerst beendet (wie erwartet, da einfach nicht so viel zu kompilieren ist), unabhängig von der Position in der Liste.

Ich bin mit den Interna überhaupt nicht vertraut, aber es scheint mir, dass die Reihenfolge, in der die Pakete kompiliert werden, von Bedeutung ist und sie bei der Erstinstallation einfach nicht sortiert werden (und sie werden sortiert, wenn später yarn aufgerufen wird). was sich in irgendeiner Weise auf die Prüfsumme auswirkt.

Vielen Dank für die Untersuchung! Das klingt nach einem guten Vorsprung. Der Hash wird hier geschrieben: https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581 -L583. Es könnte sich lohnen, diesen Code zu debuggen und zu sehen, was in der Sperrdatei anders ist, da der Hash in .yarn-integrity auf der Sperrdatei basiert.

Es könnte sich lohnen, diesen Code zu debuggen und zu sehen, was in der Sperrdatei anders ist, da der Hash in .yarn-Integrität auf der Sperrdatei basiert.

Ich vermutete das, aber was mich abschreckte, war die Tatsache, dass sich die Sperrdatei nicht ändert, sie ist immer dieselbe. Es ist nur der Hash in der Garnintegrität, der sich ändert.

$ yarn add leveldown bcrypt
$ cat node_modules/.yarn-integrity
59530680cc0a4ee12feb373980b5abf2edf2fe2aefa16d556bfb531af8299e71
$ cp yarn.lock leveldown_bcrypt_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock leveldown_bcrypt_afterwards.lock
$ diff -s leveldown_bcrypt_initial.lock leveldown_bcrypt_afterwards.lock
Files leveldown_bcrypt_initial.lock and leveldown_bcrypt_afterwards.lock are identical

$ yarn add bcrypt leveldown
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_afterwards.lock
$ diff -s bcrypt_leveldown_initial.lock bcrypt_leveldown_afterwards.lock
Files bcrypt_leveldown_initial.lock and bcrypt_leveldown_afterwards.lock are identical

$ diff -s leveldown_bcrypt_initial.lock bcrypt_leveldown_initial.lock
Files leveldown_bcrypt_initial.lock and bcrypt_leveldown_initial.lock are identical

Ich habe das gleiche Problem: Ich benutze auch bcrypt. Jedes Mal, wenn ich einige neue Module installiere oder vorhandene aktualisiere, muss ich npm rebuild ausführen, damit meine App ausgeführt werden kann.

macOS 10.12 && node v7.0.0 && yarn v0.16.1

Ich kann die Originalausgabe nicht mehr reproduzieren. Es scheint behoben worden zu sein: +1:. @ Daniel15 Kannst du das bestätigen?

@hustcer Ich denke nicht, dass das das gleiche Problem ist. Möglicherweise möchten Sie mit der neuesten Version testen und einen neuen Fehler melden, wenn dieser bei Ihnen immer noch nicht funktioniert.

@jiripospisil Danke, es ist jetzt okay nach dem Upgrade auf Garn v0.17.4.

Ich sehe dies oder etwas sehr Ähnliches immer noch auf 0.18.1. Übrigens ist es auch Leveldown, der immer wieder neu aufgebaut wird. Wenn Sie das linke Pad als Paket ohne Abhängigkeiten verwenden (und dies hängt nicht von Leveldown ab), um die Demonstration zu demonstrieren, gehen Sie wie folgt vor:

mkdir test && cd test
echo '{ "name": "test", "version": "1.0.0" }' > package.json
yarn add leveldown 
yarn add leftpad
yarn remove leftpad

Meine Ausgabe beim Ausführen folgt. Beachten Sie, dass das Entfernen des linken Pads fast 40 Sekunden dauert. Der größte Teil davon ist das Wiederherstellen des Leveldowns. Dies geschieht konsistent mit und ohne Leveldown oder Leftpad im Garn-Cache, allerdings nur während remove und niemals während add .

$ mkdir test && cd test
$ echo '{ "name": "test", "version": "1.0.0" }' > package.json
$ yarn add leveldown 
yarn add v0.18.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 145 new dependencies.
<... package list omitted for brevity ...>
✨  Done in 49.93s.
$ yarn add leftpad
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
✨  Done in 2.18s.
$ yarn remove leftpad
yarn remove v0.18.1
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
success Uninstalled packages.
✨  Done in 38.76s.
$ yarn why leftpad
<... just to confirm that leftpad and leveldown are entirely unrelated ...>
yarn why v0.18.1
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.30s.

Versionen:

Knoten v7.3.0
Garn 0.18.1
OS X El Capitan (10.11.6)

Bitte öffnen Sie erneut, da dies immer noch geschieht.
Habe gerade yarn add redux und bcrypt , node-sass und einige andere wieder aufgebaut.

Knoten v6.9.4
Garn v0.20.3
Windows 10

@seansfkelley Ich habe Ihre Schritte mit der neuesten Version verfolgt und es hat funktioniert. Könnten Sie es noch einmal versuchen?

/tmp/tp-20170222100611/test ∴ echo '{ "name": "test", "version": "1.0.0" }' > package.json
/tmp/tp-20170222100611/test ∴ yarn add leveldown
yarn add v0.20.3
info No lockfile found.
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 54 new dependencies.
<cut>
warning [email protected]: No license field
✨  Done in 1.64s.
/tmp/tp-20170222100611/test ∴ yarn add leftpad
yarn add v0.20.3
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
warning [email protected]: No license field
✨  Done in 0.69s.
/tmp/tp-20170222100611/test ∴ yarn remove leftpad
yarn remove v0.20.3
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
warning [email protected]: No license field
success Uninstalled packages.
✨  Done in 0.66s.
/tmp/tp-20170222100611/test ∴ yarn why leftpad
yarn why v0.20.3
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.20s.

@Nexxado Könnten Sie bitte ein paar Reproduktionsschritte hinzufügen? Ich habe ein paar Kombinationen ausprobiert, aber es hat funktioniert.

Knoten 7.3.0
Garn 0,20,3
MacOS 10.12.3

@jiripospisil Ich muss keine Reproduktionsschritte bereitstellen. Durch einfaches Installieren eines zusätzlichen Pakets wird das Garn verknüpft und alles neu aufgebaut.

Hier ist die Ausgabe des Hinzufügens eines Pakets (Sperrdatei existiert bereits):

Abhängigkeiten verknüpfen:

Wiederaufbau:

@jiripospisil Ich yarn add [email protected] statt nur yarn add leveldown , sollten Sie das gleiche Verhalten wie zuvor sehen.

Ich habe eine indirekte Abhängigkeit von ttf2woff2 , die auch jedes Mal neu erstellt wird.

Es wird jedoch nur jedes Mal neu erstellt, wenn eine Änderung in yarn.lock . Das heißt, yarn mit einem neuen yarn.lock , yarn upgrade , yarn upgrade-interactive . Im Fall yarn upgrade-interactive wird ttf2woff2 zweimal (!) Neu erstellt, wenn sowohl Devdeps als auch reguläre Deps aktualisiert wurden.

Ich sehe dieses Problem auch, obwohl ich es mit den obigen Schritten nicht reproduzieren konnte. Ich kann es jedoch mit den folgenden Schritten reproduzieren:

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

Garn hinzufügen co
`` `

dann baut es wieder Leveldown auf.

Es scheint keine Rolle zu spielen, welches Paket ich hinzufüge, es baut immer Leveldown neu auf.

Ich verwende Yarn v0.21.3, Windows 10 und Node v7.7.1

Ich sehe das auch. Ich benutze BuckleScript (bs-Plattform) ....

Ich stoße auch auf dieses Problem mit sharp . Jedes Mal, wenn ich yarn add oder yarn remove ausführe, wird sharp , selbst mit nicht nativen Paketen.

Getestet in Garn v0.21.3, Knoten 7.0.0, unter Windows 10 und Ubuntu Linux 16.04.

Hier sind package.json Abhängigkeiten, wenn es hilft:

{
  "devDependencies": {
    "auto-reload-brunch": "^2.7.1",
    "babel-brunch": "^6.1.1",
    "babel-preset-env": "^1.2.1",
    "brunch": "^2.10.8",
    "chai": "^3.5.0",
    "clean-css-brunch": "^2.10.0",
    "css-brunch": "^2.10.0",
    "express-mysql-session": "^1.2.0",
    "javascript-brunch": "^2.10.0",
    "jquery": "^3.1.1",
    "less-brunch": "^2.10.0",
    "mocha": "^3.2.0",
    "nodemon": "^1.11.0",
    "npm-run-all": "^4.0.2",
    "postcss-brunch": "^2.0.5",
    "postcss-cssnext": "^2.9.0",
    "postcss-font-magician": "^1.6.1",
    "uglify-js-brunch": "^2.10.0"
  },
  "dependencies": {
    "body-parser": "^1.17.1",
    "connect-redis": "^3.2.0",
    "cookie-parser": "^1.4.3",
    "debug": "^2.6.1",
    "express": "^4.15.2",
    "express-session": "^1.15.1",
    "jstransformer-marked": "^1.0.2",
    "md5": "^2.2.1",
    "morgan": "^1.8.1",
    "multer": "^1.3.0",
    "node-mysql": "^0.4.2",
    "passport": "^0.3.2",
    "passport-local": "^1.0.0",
    "pug": "^2.0.0-beta11",
    "serve-favicon": "^2.4.1",
    "sharp": "^0.17.2"
  }
}

sehe dies auch mit bs-platform

Wenn Sie dies auch mit ttf2woff2 erleben, wird yarn add ttf2woff2 , obwohl es seit über einem Jahr nicht mehr veröffentlicht wurde.

Ich habe das auch mit Couchbase

edit: scheint in 0.23.2 behoben zu sein

Es passiert mir immer noch auf 0.23.2 ( argon2 und node-sass werden jedes Mal neu erstellt, wenn ich ein nicht verwandtes Paket wie moment hinzufüge / entferne, das keine Abhängigkeiten hat)

Betriebssystem: Windows 10
Knoten: 7.9.0
Garn: 0,23,2

Um etwas mehr Farbe hinzuzufügen, war meine Wahrnehmung dieses Ereignisses auf yarn add <some-package> viel größer als die Realität, da viele Fälle für mich tatsächlich durch die Kombination mit yarn remove <unrelated-package> unmittelbar zuvor aufgrund der force: true ausgelöst wurden dieser Zeile .

Sicherlich praktisch, um die Installationslogik in remove wiederzuverwenden, um die Sperrdatei zu generieren, aber es wäre schön, wenn sie nicht das gesamte Gepäck einer erzwungenen Installation enthalten würde :)

Für mich begann dies erneut, als ich auf 0.23.x upgrade. Ich bin auf 0.21.3 zurückgekehrt und es wird nicht mehr jedes Mal erstellt. Dies führte auch zu diesem Problem, bei dem meine IP von unicode.org blockiert wurde, nachdem einige Pakete hintereinander aktualisiert wurden: https://github.com/dodo/node-unicodetable/issues/16

Während 0.21.3 beim Hinzufügen eines neuen Pakets nicht alle Pakete neu erstellt, werden beim Entfernen alle Pakete neu erstellt. Und es scheint, dass Garn es nicht als Fehler ansieht, wenn der Wiederaufbau fehlschlägt.

Für mich hat ein Downgrade auf 0.21.3 nicht geholfen. bs-platform wird bei jedem Hinzufügen / Entfernen neu erstellt.

Dies unter MacOS mit Yarn 0.23.4 sehen. Erstellt sqlite3 jedes Mal neu, wenn ich yarn add .

$ yarn add gulp-rename gulp-notify gulp-sass -D                                                                                         1 ↵
yarn add v0.23.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning [email protected]: The platform "darwin" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
warning [email protected]: The platform "darwin" 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.
success Saved 42 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]
├─ [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]
├─ [email protected]
├─ [email protected]
├─ [email protected]
└─ [email protected]
$ install-app-deps
Rebuilding native production dependencies for darwin:x64
Rebuilding native dependency sqlite3
✨  Done in 56.61s.

Dieses Problem wird mit Ubuntu 16.04LTS mit dem neuesten Garn v0.24.6 und dem Knoten 8.1.2 angezeigt

Jedes Mal, wenn ich ein Modul hinzufüge, wird gdal , node-sass Dies führt dazu, dass das Hinzufügen von Garn viel länger dauert als erforderlich.

Ich sehe das auch, es ist super nervig auf einem Raspberry Pi Zero W, wo das Erstellen von Paketen (wie Bleno) einige Minuten dauern kann.

Ich sehe das immer noch mit Yarn v0.27.5 und uws . Jedes Mal, wenn sich etwas in meinen Paketen ändert, wird uws neu erstellt.

Das einzig Interessante an uws ist, dass es in package.json kein Abhängigkeitsfeld gibt .

Das ist für mich in den letzten Tagen ziemlich frustrierend geworden. Ich hatte windows-build-tools zu einem bestimmten Zeitpunkt global installiert (muss sich nur einmal selbst erstellen, um die Windows-Entwicklungsumgebung für native Pakete einzurichten), die sich jedes Mal neu erstellten, wenn ich ein Paket hinzufügte. Wie Sie sich vorstellen können, hat das eine Weile gedauert und mir wurde schließlich klar, dass ich es nicht mehr installieren musste, und ich habe es entfernt.

Jetzt scheint es, dass node-sass beim Hinzufügen von Paketen immer wieder auf einem anderen Projekt aufbauen möchte.

Dieses Verhalten tritt yarn remove mir sowohl bei yarn add als auch bei yarn remove auf. Sicherlich ist für diese Schritte keine Neuerstellung erforderlich, da die nativen Pakete gemäß der Node-Version nur einmal erstellt werden.

Bearbeiten: Verwenden von Node v8.2.1 und Yarn v0.27.5 unter Windows 10.

Ich kann nicht zählen, wie oft uws für mich neu erstellt wurde :) Beachten Sie, dass uws
hat keine Abhängigkeiten und es fehlt sogar das Feld in package.json

Am Montag, 31. Juli 2017, 22:50 Uhr Paul Myburgh [email protected]
schrieb:

Das ist für mich in den letzten Tagen ziemlich frustrierend geworden. ich hatte
Windows-Build-Tools werden global in einer Phase installiert (müssen nur wirklich
Erstellen Sie sich einmal selbst, um die Windows-Entwicklungsumgebung für native Geräte einzurichten
Pakete), die sich jedes Mal neu aufbauten, wenn ich ein Paket hinzufügte. Wie
Sie können sich vorstellen, dass das eine ganze Weile gedauert hat und ich merkte schließlich, dass ich es nicht tat
brauche es nicht mehr installiert und entfernt.

Jetzt scheint es so, als ob Node-Sass immer wieder auf einem anderen Projekt aufbauen möchte
beim Hinzufügen von Paketen.

Dieses Verhalten tritt bei mir sowohl beim Hinzufügen als auch beim Entfernen von Garn auf. Sicher nein
Für diese Schritte ist eine Neuerstellung erforderlich, da nur die nativen Pakete erstellt werden
einmal nach der Node-Version?

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/932#issuecomment-319192291 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AADWlgSNhi-V9-yGWsWHBDFYdyJW8Arjks5sTj4UgaJpZM4KVN87
.

Ich bin auf 0.27.5 und sehe dieses Verhalten immer wieder mit bs-platform .

Das ist ziemlich frustrierend, ebenso hier mit bs-platform .

Nettes Anspruchsgefühl dort… Wie wäre es mit einem PR Tim?

Am Dienstag, 22. August 2017, 10:44 Uhr Tim Shnaider [email protected]
schrieb:

FFS kann dies bitte behoben werden.
Geben Sie mindestens eine Befehlszeilenoption oder eine env-Einstellung an, um sie zu deaktivieren.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/932#issuecomment-323960245 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AADWltQedG4owTlcC8koC4RL-vTiCE0Hks5sapTbgaJpZM4KVN87
.

Es scheint bisher nicht erwähnt worden zu sein, aber ich kann diesen Fehler auch mit yarn global list reproduzieren.

Schritte zum Reproduzieren:

1. Verwenden Sie eine neue globale Umgebung :: Warnung: Führen Sie diese nur aus, wenn Sie wissen, was Sie tun

   rm -rf ~/.config/yarn/
   

2. Fügen Sie ein problematisches Paket hinzu (_i.e._ zeppelin-solidity ):

   → yarn global add node-gyp zeppelin-solidity
   yarn global v0.27.5
   [1/4] Resolving packages...
   warning zeppelin-solidity > truffle-hdwallet-provider > web3-provider-engine > ethereumjs-block > merkle-patricia-tree > level-ws > xtend > [email protected]:
   [2/4] Fetching packages...
   [3/4] Linking dependencies...
   [4/4] Building fresh packages...
   success Installed "[email protected]" with binaries:
         - node-gyp
   warning "[email protected]" has no binaries
   Done in 20.53s.
   

3. Führen Sie yarn global list und sehen Sie, wie einige native Pakete neu kompiliert werden

4. Wiederholen Sie so oft Sie möchten. yarn global list kompiliert diese nativen Pakete immer neu
5. 😭

Ich hoffe das hilft.

ℹ️ MacOS 10.12.6 mit über Homebrew installiertem Garn 0.27.5.

Der Anspruch ist unnötig, aber ich kann die Frustration verstehen. Dies verschwendet viele Leute viel Zeit (lange Neuinstallationen summieren sich im Laufe der Zeit und unterbrechen den Fluss). Sicher, Sie können sagen "Machen Sie eine Pull-Anfrage" - und das ist fair. Aber es wäre ein Lernprozess, der möglicherweise nur ein paar Codezeilen ändert ... Wir hoffen, dass Leute, die die Vor- und Nachteile dieses Projekts kennen, dieses Problem bei der nächsten Veröffentlichung als wirklich priorisieren scheint ziemlich wichtig zu sein (und möglicherweise eine einfache Lösung? Verhindern Sie die Neuinstallation von Binärdateien, wenn sich die Node-Version möglicherweise nicht geändert hat).

Es ist fast ein Jahr her, seit es zum ersten Mal gemeldet wurde.

Ich hoffe, ich klinge nicht berechtigt, das zu sagen ... Ich möchte hinzufügen, dass ich für dieses Projekt und die Nützlichkeit, die es mir bereits bringt, sehr dankbar bin. Dieses Problem war einer der wenigen Probleme, die ich damit hatte.

BEARBEITEN: Habe gerade ein yarn remove für ein zufälliges Paket gemacht und es hat versucht und (diesmal) konnte meine Binärdateien nicht neu erstellen. Der Nebeneffekt ist, dass meine Binärdateien jetzt vollständig fehlen und es anscheinend nur mit einem npm rebuild . Es scheint also nicht nur, dass dieses Problem unnötige Neuerstellungen verursacht. Wenn dieser Prozess fehlschlägt, müssen Sie anscheinend auf npm zurückgreifen, um es erneut zu beheben.

Ich sehe das gleiche Verhalten wie @zhangjyr und @lostpebble. Das Ausführen von yarn add funktioniert einwandfrei, aber yarn remove bewirkt, dass native Pakete neu erstellt werden.

Mac Sierra 10.12.6
Garn 0,27,5

Ich werde versuchen zu sehen, was ich dagegen tun kann, da dies auch mich betrifft. Das heißt, Garn ist nicht so schwer beizutragen. Wenn jemand eine PR senden möchte, probieren Sie es bitte aus und wir werden versuchen, Sie so gut wie möglich zu unterstützen.

Daran werde ich einige Wochen nicht arbeiten können.

Ich sehe das auch.
Arbeiten vor Ort auf Gatsby bauen. JEDER Fadenvorgang führt zum Wiederaufbau.
Versuchen Sie, eine Site mit Gatsby zu erstellen und damit zu fädeln. Hoffe das hilft

Sehen Sie dies in einem Projekt mit gatsby:
Garn 1.0.2
Knoten 7.10.1
Ubuntu 16.04

Dieses Problem wird jetzt ziemlich ernst. Meine Binärdateien werden nicht nur immer neu erstellt. Es kommt jedoch häufig vor, dass meine Binärdateien nach einem yarn add oder yarn install vollständig entfernt werden (nachdem die Versionsnummern eines Pakets in package.json geändert wurden, um ein Modul zu aktualisieren / zurückzusetzen). Und egal wie viel ich danach yarn install oder yarn install --check-files laufen lasse, diese Binärdateien sind einfach verloren und verschwunden und kommen nie wieder zurück. Der einzige Weg, sie abzurufen, ist mit einem npm rebuild .

Es fühlt sich an, als hätte Garn überhaupt kein Wissen über den Zustand nativer Verpackungen. Ob sie bereits installiert / gebaut sind oder ob sie nicht richtig installiert / gebaut sind.

Hat diesbezüglich vielleicht Fortschritte erzielt?

Ich denke, dass das kürzlich hinzugefügte artifacts -Feld zur Garnintegritätsdatei von

Ich habe ein ähnliches Problem mit bs-platform, wenn ich Pakete in meinem reasonml-Projekt installiere

Gleich ... buchstäblich jedes yarn add wird das Gyp-Projekt neu erstellen.

Passiert auch hier.
(Garn 1.2.1)

Ich sehe das mit node-sass .

Passiert zum Beispiel mit Cypress.

Knoten -v
v8.8.1
Garn -v
1.2.1

✋ Anstatt "Ich auch" ohne zusätzliche Informationen zu schreiben, verwenden Sie die + 1-Funktion in Github im oberen Beitrag . Jedes Mal, wenn Sie einen "Ich auch" -Kommentar schreiben, werden 35 Abonnenten unnötig benachrichtigt.

+1

Bitte klicken Sie einfach auf Subscribe wenn Sie Updates erhalten möchten. Ich hoffe, jeder möchte benachrichtigt werden, wenn es gelöst ist, aber nicht, wenn jemand Neues mit diesem Problem konfrontiert ist.

@BYK können Sie bitte Thread sperren und ihn nur für Besitzer zur Verfügung stellen.

Ich untersuche derzeit dieses Problem und versuche, es auf einen minimal reproduzierbaren Testfall zu reduzieren. Ein "großartiges" Paket zur Demonstration dieses Problems ist htmlstrip-native - das Kompilieren dauert einige Minuten, sodass Sie es nicht verpassen können.

Ich würde gerne jemanden bitten, dieses package.json in einem leeren Ordner auszuprobieren:

{
  "name": "yarn-test",
  "version": "1.0.0",
  "dependencies": {
    "htmlstrip-native": "^0.1.3",
    "left-pad": "1.1.3"
  }
}

Versuchen Sie, die folgenden Befehle auszuführen:

yarn
yarn upgrade [email protected]

Auf meiner Maschine mit dem neuesten Garn 1.2.1 führt der Befehl upgrade zu einer Neuerstellung von htmlstrip-native die ewig dauert. Garn sollte dies nicht neu erstellen, da ein Upgrade von left-pad keine Auswirkungen auf htmlstrip-native oder seine Abhängigkeiten hat.

Versuchen Sie jetzt npm :

rm -rf node_modules
npm install
npm install [email protected]

Auf meinem Computer führt der zweite Befehl (korrekt) nicht zu einer erneuten Neuerstellung von htmlstrip-native .

BEARBEITEN :

OK, nach langem Debuggen scheint dieses Verhalten beabsichtigt zu sein. Beim Durchlaufen des Codes sieht es so aus, als würde beispielsweise yarn upgrade [email protected] zu den folgenden Schritten führen:

1) Das Modul upgrade wird aufgerufen, das eine Operation new Add() für left-pad .
2) Add.init() ruft seine Oberklasse an, Install.init()
3) Install.init() einen rebuildingPackages Schritt in die Warteschlange
4) In PackageInstallScripts.init() einfach alle Pakete gesammelt und zu den workQueue hinzugefügt, die neu erstellt werden sollen.
5) PackageInstallScripts entdeckt dann, dass es einen Installationsbefehl für htmlstrip-native und führt ihn einfach aus - dies ist die super langsame native Neuerstellung, die wir alle sehen.

Nach allem, was ich bisher gesehen habe, scheint es keine Logik zu geben, die Pakete herausfiltern will, die nicht "neu erstellt" werden müssen. Es wird einfach alles neu erstellt, wie in der Konsolenausgabe angegeben.

Ich würde es lieben, wenn sich jemand aus dem Yarn-Team hier einschaltet - wenn dieses Verhalten wirklich beabsichtigt ist, würde ich empfehlen, dieses Problem zu schließen!

Für meine persönliche Situation werde ich einfach meine Abhängigkeit von htmlstrip-native austauschen, da es keinen Grund gibt, warum das Erstellen Minuten dauern sollte (es ist wie ein paar winzige .c Dateien). Der Rest meiner einheimischen Deps baut sich schnell auf, daher ist es keine große Sache, wenn es die ganze Zeit passiert.

Es klingt wie ein unbeabsichtigter Nebeneffekt des Designs, aber vielleicht kann jemand auf @ yarnpkg / core dies kommentieren. Ich denke nicht, dass es beabsichtigt ist, Pakete neu zu erstellen, die nicht neu erstellt werden müssen.

Dies ist nicht beabsichtigt, es ist wahrscheinlich nur einfacher, auf diese Weise zu implementieren.
Es gibt einen Kommentar von BYK oben, der besagt, dass dieses Problem nach einer PR sucht:
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

Sicherlich sind native-schwere Pakete nicht häufig genug, um als höchste Priorität für Yarn aufzutauchen. Yarn kann jedoch nicht bei jeder Installation Pakete neu erstellen.
Dies scheint ein Fehler zu sein, der einfach zu beheben sein sollte. Senden Sie eine PR.
Es kann Vorbehalte geben, da Yarn nicht sicher wissen kann, ob ein erstelltes Paket beschädigt worden sein könnte. Aus diesem Grund werden Installationsskripte jetzt eifrig erneut ausgeführt.

Es gibt eine Garngabel, die vom Team hinter Reason https://github.com/esy-ocaml/esy-install verwendet wird und viele native Kompilierungsprobleme umgeht, da Reason / Ocaml-Abhängigkeiten eine umfangreiche Kompilierung erfordern.
Wenn dieser Ansatz ausgereift ist, hoffe ich, dass es möglich sein wird, die Änderungen vorgelagert zusammenzuführen.

Grundsätzlich werden native Pakete neu erstellt, weil entweder:

1) Das Flag force=true wurde gesetzt, oder
2) Das Paket wurde mit fresh=true markiert.

Es scheint, dass bei einigen Befehlen (wie upgrade und remove ) das Flag force auf "nur für den Fall" gesetzt ist. Dieses Flag verspricht, "alle Pakete neu zu erstellen, unabhängig davon, ob sie geändert wurden". Daher ist es nicht sinnvoll, einen Änderungserkennungscode hinzuzufügen, da dies dieses Versprechen brechen würde.

Um dies zu beheben, müssen wir anscheinend die Annahmen der verschiedenen Stellen im Code in Frage stellen, die force=true .

Der erste, den ich aufgespürt habe, passiert, wenn yarn upgrade whatever . Es wurde in diesem Commit als Teil von # 2780 von @juanca eingeführt. In den Festschreibungsnotizen heißt es:

"Ensure force flag is enabled when using `yarn upgrade` Otherwise exotic packages are not updated."

Vielleicht könnte @juanca oder jemand, der mit der Geschichte des Garns besser vertraut ist, mit dem Problem

@nfarina danke, das bringt Klarheit. Für Upgrades möchten wir möglicherweise wirklich native Pakete erzwingen (wenn sie aktualisiert werden). Aber für Installationen (Garn hinzufügen) würde ich sagen, dass wir, wie Sie sagten, zu Recht die Annahme in Frage stellen müssen, dass bereits installierte native Pakete neu erstellt werden, wenn etwas anderes installiert wird.

Ich nehme an, dass das Flag force ist, damit der Garnauflöser die vorhandene Abhängigkeit nicht überspringt, da sich die alte Version in yarn.lock befindet.

Ich denke, es war eine schnelle Lösung, um das Upgrade zum Laufen zu bringen.
Ein geeigneter Weg wäre, ein anderes Flag zu übergeben, das nur die Auflösung bestimmter Pakete betrifft und nicht so nuklear ist wie force .
Senden Sie eine PR :)

Vielleicht könnte @juanca oder jemand, der mit der Geschichte des Garns besser vertraut ist, mit dem Problem

Richtig, ich habe nur mit der API Add - sie hat (hat?) Nichts getan, wenn ein vorhandenes Paket hinzugefügt wurde.

Ich empfehle auch die Verwendung einer besseren Technik zur Steuerung des Verfahrensflusses.

Ich verwende Garn auf meinem Himbeer-Pi-Nullpunkt in einem Projekt, das von Node-OpenCV abhängig ist. Jedes Mal, wenn ich ein nicht verwandtes Paket hinzufüge / entferne / aktualisiere, muss ich 35 Minuten auf die Neuerstellung warten.

@ Torsten85 , ich benutze es auch auf pi, ja, unnötige Umbauten müssen wir angehen.
Können Sie ein Repro-Skript für Ihre Neuerstellungen bereitstellen?

Gleiches gilt hier für Lubuntu 17.10, wenn ich Garn verwende und mit https://github.com/mui-org/material-ui weiterentwickle

Jede einzelne yarn add/remove (-D) <pkg> Neuerstellung alles, wie eine Neuinstallation, dauert mehr als 1 Minute

Geht npm so auch damit um? Wenn nicht, wäre es eine mögliche Problemumgehung, vorübergehend zu wechseln?

passiert auch hier

• Knoten 9.2.0
• Garn 1.4.0

Jedes Mal, wenn ich Abhängigkeiten hinzufüge, werden Module wie bcrypt oder couchbase jedes Mal neu erstellt

Hallo allerseits, ich arbeite an einem kleinen Hack https://github.com/yarnpkg/yarn/pull/5314.
Die Idee ist, ein integriertes Paket im Offline-Spiegel zwischenzuspeichern, um zu vermeiden, dass ständig Installationsskripte ausgeführt werden.

Wenn Sie also den Offline-Spiegel verwenden und yarn add node-sass ausführen:

1. Garn würde wie gewohnt Node-Sass bauen und installieren,
2. Nachdem die Installationsskripte ausgeführt wurden, wird node-sass-v4.7.2-darwin-x64-57.tgz aus dem geänderten Ordner node_modules/node-sass generiert
3. Wenn Sie das nächste Mal yarn install auf derselben Plattform ausführen, wird nur node-sass-v4.7.2-darwin-x64-57.tgz anstelle des ursprünglichen entpackt und es werden keine Installationsskripte ausgeführt

Dies funktioniert nicht in jedem Fall, könnte jedoch eine Lösung für Offline-CI-Systeme sein, bei denen Sie nicht möchten, dass Pakete jedes Mal ins Internet gelangen und dieselben Installationsskripte ausführen.

Ich versuche, Typoskript als globales Paket zu installieren, und Garn verbringt die ganze Zeit damit, Dinge neu aufzubauen, anstatt das zu installieren, was ich jetzt wirklich brauche.

Ich wechselte zu Garn und dachte, es sei schneller und besser. Ich habe alle Spuren von npm entfernt (mit Ausnahme der mit der Knoteninstallation gelieferten). und alle globalen Pakete zu Garn neu installiert.

Yarn testet jetzt meine Geduld, indem es mich 1-15 Minuten auf die einfache Installation des Pakets warten lässt. Das Garn sollte intelligenter genug sein, um die Anforderung zuerst zu installieren, bevor andere Inhalte neu erstellt werden, es sei denn, das angeforderte Paket hängt explizit von einem der nativen Pakete ab, die neu erstellt werden müssen.

Umgebung:

• Knoten: 9.4.0
• Garn (global): 1.3.2
• macOS Sierra: 10.12.6
• Macbook Pro 15 Zoll
  
  
  
  • Speicher: 16 GB
  
  
  • CPU: 2 GHz - Intel Core i7
  
  
  • Lagerung: Magentic (viel freier Speicherplatz)
  
  
  • Apps, die zum Zeitpunkt der Installation ausgeführt werden: Firefox (6 Registerkarten), Mail.app und iTerm (mit 2 Registerkarten)
  
  

Protokolle

Das Abrufen von Paketen nimmt viel Zeit in Anspruch

Garn globales Upgrade Typoskript
Garn global v1.3.2
[1/4] 🔍 Auflösen von Paketen ...
[2/4] 🚚 Pakete holen ...
[################################################### ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

Das Verknüpfen von Abhängigkeiten bleibt minutenlang ohne Fortschritt hängen

Garn globales Upgrade Typoskript
Garn global v1.3.2
[1/4] 🔍 Auflösen von Paketen ...
[2/4] 🚚 Pakete holen ...
[3/4] 🔗 Abhängigkeiten verknüpfen ...
[--------------------------------------------- -------------------------------------------------- -------------------------------------------------- ---------------------------------------------] 0/2566

Das Neuerstellen aller Pakete nimmt viel Zeit in Anspruch

Garn globales Upgrade Typoskript
Garn global v1.3.2
[1/4] 🔍 Auflösen von Paketen ...
[2/4] 🚚 Pakete holen ...
[3/4] 🔗 Abhängigkeiten verknüpfen ...
[4/4] 📃 Alle Pakete neu erstellen ...
[17.12.] ⠐ Websocket
[2/17] ⠐ expresso: Überprüfung auf gcc-Option zur Annahme von ISO C99 ...
[8/17] ⠐ serialport: using [email protected] | darwin | x64
[17.06.] ⠐ jetzt:> Den Quellcode finden Sie unter: https://github.com/zeit/now-cli

Garn globales Upgrade Typoskript
Garn global v1.3.2
[1/4] 🔍 Auflösen von Paketen ...
[2/4] 🚚 Pakete holen ...
[3/4] 🔗 Abhängigkeiten verknüpfen ...
[13/17] ⠈ serverlos
[13/17] ⠂ serverlos
[14/17] ⠠ Solgraph
[14/17] ⠁ Solgraph
[14/17] ⡀ Solgraph
[- / 17] ⠈ Warten ...
[- / 17] ⠄ Warten ...
[- / 17] ⠠ Warten ...
[- / 17] ⠈ Warten ...
[- / 17] ⠄ Warten ...
[- / 17] ⢀ Warten ...
[- / 17] ⠈ Warten ...

Ich warte weiter :-)

Ein weiterer Nebeneffekt ist, dass Bibliotheken, die Vorkompilierungen herunterladen und zwischenspeichern, ebenfalls gelöscht werden und erneut heruntergeladen werden müssen: nämlich nwjs-builder-phoenix 's Cache mit Build-Target-SDKS

1. Das native Paket wird immer neu erstellt, wenn eine Paketversion aktualisiert wird, die kein natives Paket ist.

Zwischenspeichert Garn die Binärdatei wie npm im globalen Bereich?

Es frustriert mich ein bisschen, dass ich nwjs in jeder einfachen Installation neu erstellen muss. Macht keinen Sinn

Ich sehe das auch. uws wird jedes Mal neu erstellt, wenn ich eine Add / Remove-Operation durchführe. Garn v1.3.2

Hallo @bestander. Wir haben # 5314 auf dem Monorepo unseres Unternehmens ausprobiert, es hatte jedoch keine Auswirkung darauf, die Neuerstellung einiger Abhängigkeiten für uns zu stoppen. Wir haben yarn-offline-mirror und pack-built-packages in .yarnrc aktiviert, wie in den hinzugefügten Tests gezeigt.

Der springende Punkt ist, dass das Ausführen von yarn für uns immer ungefähr 40-50 Sekunden dauert, selbst wenn der Befehl, den wir direkt zuvor ausgeführt haben, auch yarn war.

@ bazyli-brzoska, ich habe die Flagge expliziter geändert und vergessen, die Beschreibung zu aktualisieren.
Können Sie versuchen, das Flag experimental-pack-script-packages-in-mirror auf "true" zu setzen?

Gibt es hier Fortschritte? Ich sehe, dass die Pull-Anfrage bereits zusammengeführt wurde und in der neuesten Version 1.5.1 enthalten ist. Ich bin auf 1.5.1 und nichts hat sich für mich geändert. Trotzdem denke ich darüber nach, zu npm zurückzukehren, weil ich auf 322.70s oder 282.69s oder sogar 683.41s (das sind wirklich meine letzten drei yarn add s) warte Das Installieren eines kleinen Rollup-Plugins oder eines Lodash oder so ziemlich alles ist einfach verrückt.

Es wäre fantastisch, wenn größere Vorbehalte wie diese auf Ihrer README.md stehen würden. Benutzer installieren Garn, weil es angeblich "schneller" ist und dieser Übergang von npm zu Garn kein kleiner Schritt ist. Es wäre also schön, wenn Entwickler vorab gewarnt würden, damit sie vor dem Konvertieren lieber noch einmal darüber nachdenken können ihre Skripte, die ihre Globalen verschmutzen und das Garn Cli lernen.

Ich dachte, dies sei nur ein Problem mit meiner alten 32-Bit-Maschine, aber nachdem ich es beim 237. Mal gesehen hatte, googelte ich es und oh, Garn ist einfach nicht schneller. Großartig.

Tut mir leid, dass ich wahrscheinlich gemein bin, aber ich denke, du bekommst die Frustration.

Wir akzeptieren Beiträge.

Beachten Sie jedoch, dass Pakete neu erstellt werden, wenn sie nicht "benötigt" werden: Build-Schritte werden ausgeführt, nachdem Abhängigkeiten installiert wurden. Dies bedeutet, dass die Build-Skripte diese Abhängigkeiten verwenden dürfen. Das heißt, wenn sich diese Abhängigkeiten aus irgendeinem Grund ändern (was "zufällig" auftreten kann, beispielsweise wenn wir zwei kompatible Versionen eines Pakets in eine optimiert haben), müssen wir die Erstellungsschritte tatsächlich erneut ausführen, auch wenn diese Abhängigkeiten nicht tatsächlich vorhanden sind wird während des Builds verwendet (denn wie können wir das wissen?).

Es ist also nicht gerade ein einfaches Problem. Zumindest ein Teil des Problems stammt aus dem package.json-Design selbst. Erzähl mir von Frustration 🙂

@arcanis Ich verstehe diesen Teil nicht:

selbst wenn diese Abhängigkeiten während des Builds nicht tatsächlich verwendet werden (denn wie können wir das wissen?).

Ich dachte, dass YARN Design statische Abhängigkeiten + Version (Garnsperre) beibehalten sollte und es daher keine zufälligen "Updates" geben wird.
Obwohl das Paket json einen vollständigen Baum enthält, warum sagen Sie dann "Wie können wir das wissen?" Sobald der Baum aufgelöst ist, ist es wirklich einfach zu sagen, ob sich eine der Abhängigkeiten (auch auf tiefer Ebene) zum Erstellen von X geändert hat oder nicht.

Angenommen, ich habe eine Abhängigkeit foo , die von babel-core und left-pad@^1.0.0 abhängt, und diese foo Abhängigkeit hat ein Build-Skript, das babel in seiner Indexdatei ausführt .

Nachdem ich yarn add foo in meinem Projektordner ausgeführt habe, habe ich am Ende [email protected] in den Knotenmodulen, richtig? Angenommen, es wird eine neue Version für das linke Pad veröffentlicht ( 1.1.0 ), die ich in meinem Projekt verwenden möchte. Ich werde yarn add left-pad ausführen, was sich dann in latest , dh 1.1.0 .

Was nun passieren kann ist, dass Yarn "sieht", dass sich zwei Kopien des linken Pads im Baum befinden, und dass sie optimiert werden könnten: Immerhin hängt foo von left-pad@^1.0.0 , also ist 1.1.0 kompatibel. Es wird also die vorherige Version entfernt und nur 1.1.0 . Da sich die Abhängigkeit geändert hat, müssen wir das Build-Skript erneut ausführen, da Yarn nicht wissen kann, dass left-pad eher eine Laufzeitabhängigkeit als eine Build-Time-Abhängigkeit ist .

Jetzt könnten Sie fragen: "Aber warum nicht einfach die Neuerstellung überspringen, wenn sich die transitiven Abhängigkeiten geändert haben?". Die Antwort ist, dass einige Pakete (insbesondere native Pakete) Abhängigkeiten aufweisen, die sich radikal auf ihre Erstellung auswirken. Wenn es passiert, wollen wir diese Pakete wirklich, wirklich neu erstellen, sonst würden wir inkompatible Artefakte haben.

@arcanis , ich denke, Sie verstehen das Problem falsch. Das Problem hierbei ist, dass diese nativen Pakete jedes Mal neu erstellt werden, selbst wenn yarn zweimal (oder öfter) schnell hintereinander ausgeführt wird. es hat nichts mit der Aktualisierung von Abhängigkeiten zu tun - es wird immer wieder neu aufgebaut.

@ Spongman Ich stimme Ihrem letzten Kommentar zu. Aber wie @Spongman richtig erwähnt hat , erfolgt die Neuerstellung jedes Mal . Selbst wenn Sie nur yarn && yarn ausführen , erhalten

Ich habe versucht, yarn add leveldown bcrypt && yarn && yarn wie im OP auszuführen und habe nur einen Build erhalten: / Haben Sie einen Befehl, mit dem ich dieses Verhalten wiederholen kann?

Sie können zum Beispiel versuchen:

mkdir foobar
cd foobar
yarn init
....
yarn add socket.io
      (5 native packages build)
yarn add react
      (5 native packages build again)
yarn remove react
      (5 native packages build again)

(Dies ist unter Ubuntu 14 LTS)

foobar billli$ yarn -v
1.3.2
foobar billli$ node -v
v8.9.1

yarn & yarn 

Verursacht nicht zwei Neuerstellungen, aber das Beispiel mit socket.io, Hinzufügen von Reagieren, Entfernen von Reagieren, verursacht zwei Neuerstellungen

Ich habe das Beispiel socket.io mit Garn v1.5.1 ausprobiert und keine Neuerstellungen erhalten, wenn ich die neue Funktion zum Zwischenspeichern nativer Builds verwendet habe. Dazu müssen Sie den Offline-Cache verwenden. In meinem ~/.yarnrc ich:

experimental-pack-script-packages-in-mirror true
pack-built-packages true                                         
yarn-offline-mirror "/home/skomorokh/yarn-offline-cache"

Wenn ich es als anderer Benutzer ohne diese Konfiguration versuche, wird es jedes Mal neu erstellt.

Ja, jetzt keine Neuerstellung, wenn diese Optionen hinzugefügt werden.
Aber wenn nur experimental-pack-script-packages-in-mirror true , wird es immer noch neu aufgebaut.
Warum setzen Sie yarn-offline-mirror auf einen Standardpfad wie "~ / .yarn / cache"?

Noch experimentell, aber es ist ein interessanter Vorschlag (cc @bestander). Ich denke, das Problem, das ich damit habe, ist, dass mir persönlich die Idee, Dinge ohne die ausdrückliche Zustimmung des Benutzers zu aktivieren, nicht gefällt. Es hat auch andere Auswirkungen: Was würde es bedeuten, wenn yarn-offline-mirror auf false und experimental-pack-script-packages-in-mirror auf true ? Sollte experimental-pack-script-packages-in-mirror die yarn-offline-mirror -Einstellungen überschreiben? Ein bisschen verwirrend imo.

Abgesehen davon ist der Fehler, uws beim Hinzufügen von left-pad erstellen, in der Tat etwas ärgerlich, und die Einstellungen von experimental-pack-script-packages-in-mirror nur eine Problemumgehung. Ich bin mir nicht sicher, ob ich in der nächsten Woche die Bandbreite haben werde, um dies zu prüfen, aber wenn jemand daran interessiert ist, einen Fix zu landen, wäre dies ziemlich wirkungsvoll.

@arcanis Vielen Dank für die freundliche Antwort. Die Frustration kommt von der Art und Weise, wie Garn präsentiert wird. Im Moment ist es einfach nicht "schnell", definitiv nicht schneller als npm und irgendwie unbrauchbar in realen Projekten. Imho, es sollte eine Information darüber oder sogar die Problemumgehung von

Ich würde die gleiche Frustration empfinden, wenn die Readme des Angularjs Repo besagen würde, dass es sich um ein leichtes Framework handelt. Es ist einfach nicht.

Es wird immer wiederholt, um die Binärdatei nach yarn-offline-mirror config herunterzuladen.

cd \tmp\t
yarn init
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node

Ich werde heute versuchen, ein bisschen darüber zu debuggen. Ich denke, es könnte tatsächlich so einfach sein, wie PackageInstallScripts nicht pkg.fresh zu überprüfen, um nur neu installierte Pakete neu zu erstellen. Stattdessen sieht es so aus, als würde es nur alle durchlaufen.

Nach einigem Herumspielen beginne ich zu denken, dass wir die ganze Zeit Dinge neu aufbauen, falls jemand rm -rf node_modules oder das Modul von dort gelöscht wird.

Wir haben eine Liste der erkannten Build-Artefakte in der .yarn-integrity -Datei, daher denke ich, dass eine Neuerstellung nur stattfinden sollte, wenn fresh package || module destination dir does not exist || any file in integrity artifacts does not exist || --force flag was passed

Es ist also etwas komplizierter als ich dachte.

Ich habe gerade yarn add ed moment , ein Paket mit null Abhängigkeiten, für meine aktuelle Reaktions-App 377.97s .

Habe es gleich danach noch einmal gemacht, es hat 389.63s und die Binärdateien erneut erstellt.

Nur zum Vergleich habe ich dann node_modules gelöscht und npm install eingegeben:
added 1751 packages and updated 124 packages in 360.595s

Jetzt wieder auf npm umgestellt.

OK, noch ein paar Infos für alle Augen zu diesem Thema ... Ich habe jetzt seit anderthalb Tagen mit diesem Ding rumgespielt und endlich ein paar Dinge realisiert.

Erstens sind die meisten dieser Wiederherstellungsprobleme behoben. In PackageInstallScripts ist bereits Code enthalten, der die Installationsskripte für ein Paket nur erneut :

    if (!ref.fresh && !this.force) {
      // this package hasn't been touched
      return false;
    }

Wenn Sie beispielsweise node-sass :

yarn add node-sass <-- builds sass because first install
yarn add left-pad <-- does NOT rebuild node-sass

Auch aufeinanderfolgende yarn install nicht neu erstellt.

yarn add uws <-- builds because first install
rm -rf node_modules
yarn install <-- builds uws because dir was deleted
yarn install <-- does NOT rebuild uws

... aber natürlich gibt es ein paar Ausnahmen ...

Auf einem yarn remove das Flag force gesetzt (um einen anderen Fehler zu beheben, den ich annehme, aber seit> 2 Jahren so), so dass immer wieder Neuerstellungen stattfinden.

Dies ist jedoch wohl "richtig", da es auch das ist, was npm tut:

~/Projects/yarn-test 🐒   npm uninstall left-pad

> [email protected] install /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/install.js

Cached binary found at /Users/me/.npm/node-sass/4.7.2/darwin-x64-57_binding.node

> [email protected] postinstall /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/build.js

Binary found at /Users/me/Projects/yarn-test/node_modules/node-sass/vendor/darwin-x64-57/binding.node
Testing binary
Binary is fine
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

added 180 packages, removed 1 package and updated 7 packages in 4.03s

Sie können sehen, dass npm auf uninstall von left-pad die Skripte install und postinstall für node-sass .

Das uws -Paket (das von einigen anderen Paketen verwendet wird, wie socket.io , browser-sync usw.)

Während des Installationsvorgangs ändert sich eine der Dateien (Größe und Zeitstempel sind unterschiedlich).

~/Projects/yarn-test 🐒   ls -l /Users/me/Library/Caches/Yarn/v1/npm-uws-9.14.0-fac8386befc33a7a3705cbd58dc47b430ca4dd95/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  383636 Nov 21 00:43 uws_darwin_57.node

~/Projects/yarn-test 🐒   ls -l node_modules/uws/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  378672 Mar  4 11:18 uws_darwin_57.node

Garn sieht eine Datei, die sich im Vergleich zum Cache "geändert" hat, und markiert das Paket für die Neuinstallation als "frisch"

Dies löst dann die obige Logik aus, die die Installationsskripte erneut ausführt, da sie "frisch" sind. Yarn versucht, hilfreich zu sein und die falschen Dateien zu "reparieren", aber es weiß natürlich nicht, dass sich die Datei aufgrund des Installationsskripts geändert hat. Möglicherweise müssen wir nach einer Möglichkeit suchen, dies zu beheben, aber es wird auch darüber gesprochen, die Art und Weise zu ändern, in der diese Dateien verglichen werden (die Ausführung von stat für jede Datei wird beendet), damit sie möglicherweise mit dieser Überarbeitung behoben wird.

Hoffentlich erklärt dies einige der Fälle hier, in denen einige Leute sagen, dass es funktioniert und andere sagen, dass es nicht funktioniert.

Danke, dass du dort tiefer getaucht bist, @ Rally25rs.

1. Betreff: Verwenden von force im Löschbefehl.
   Dies war eindeutig eine schnelle Fehlerbehebung, die mit einem nuklearen Ansatz IIRC https://github.com/yarnpkg/yarn/pull/323 zur Richtigkeit führte
   Sollte nicht schwer sein, force zu entfernen und das Problem zu umgehen.

2. node_modules/uws/uws_darwin_57.node : Diese Datei sollte sich im Feld artifacts von .yarn-integrity und dann sollten uws beim Verknüpfen nicht als nicht frisch markiert werden.
   Hier stimmt wahrscheinlich etwas nicht

@bestander ah guter Punkt auf 2. Ich werde versuchen zu sehen, ob es einen vernünftigen Weg gibt, das in den Scheck

@stereokai In meinem obigen Kommentar

@ Rally25rs Danke für den Hinweis :)

Ich halte dieses Verhalten jedoch unabhängig vom Paketmanager für fehlerhaft. Es ist schwer zu verstehen, warum diese Art von Verhalten für einen korrekten Betrieb überhaupt notwendig ist. Ihr Betriebssystem installiert lokale Programme nicht neu, wenn Sie ein anderes hinzufügen / entfernen, da die Apps bereits vorhanden sind. Ich würde von einem statischen Abhängigkeitsmanager nichts anderes erwarten, nahmean?

@stereokai Ich stimme etwas zu, weshalb ich den Ausdruck "wohl richtig" verwendet habe 😆
Ihr Betriebssystem ändert auch nicht, wo andere Anwendungen installiert sind, wenn Sie eine nicht verwandte installieren.

Angenommen, Sie haben einen Abhängigkeitsbaum wie:

myProj
  |- depA v1
  |    |-depB v2
  |- depB v1

Wenn Sie dies installieren, würde es dieselbe Verzeichnisstruktur unter node_modules , da es depB in das Stammverzeichnis heben kann.

myProj
  |- node_modules
       |- depA v1
       |   |- node_modules
       |        |-depB v2
       |- depB v1

Aber von euch yarn remove depB lautet die neue Dep-Struktur:

myProj
  |- depA v1
       |-depB v2

myProj
  |- node_modules
       |- depA v1
       |- depB v2

Daher kann sich das tatsächliche Verzeichnis, in dem depB v2 installiert ist, ändern, wenn ein Paket hinzugefügt oder entfernt wird. Diese Verzeichnisse werden nicht nur von einem Speicherort an einen anderen kopiert. Das alte wird gelöscht und das neue wird aus dem Cache in das neue Ziel kopiert. Dies bedeutet, dass Build-Artefakte in node_modules/depA/node_modules/depB nicht mehr vorhanden sind und in node_modules/depB .

Ebenso würde yarn add [email protected] den Pfad ändern, in dem depB v2 installiert ist (tatsächlich sollte ich testen, dass meine PR, um nicht auf yarn add erstellen, in diesem Fall tatsächlich funktioniert).

Ich vermute deshalb, dass diese Pakete jedes Mal neu erstellt werden.

Die tatsächliche Änderung erfolgte in diesem Commit: https://github.com/yarnpkg/yarn/commit/5300b482c851e2578ac1f3aa4908be4d0289dca8
Die Datei hatte zu diesem Zeitpunkt den Namen uninstall.js , aber force: true wurde zu den Flags hinzugefügt, die an install . Der Commit-Kommentar scheint nichts Spezifisches zu enthalten, das darauf hinweist, warum.

Wäre fantastisch, wenn es eine Möglichkeit gibt, die Neuerstellungen zumindest in einigen Fällen zu vermeiden.

Jeder kann gerne an einer PR arbeiten. 😸Wie ich oben erwähnt habe, finden Neuerstellungen bei yarn install und yarn add (in den meisten Fällen) bereits nicht statt. Ich habe # 5470 geöffnet, das unnötige Neuerstellungen für yarn add vermeiden sollte, wenn Sie uws in Ihren Abhängigkeiten haben (oder andere Pakete, die ihre eigenen Dateien während der Installation ändern). Der einzige verbleibende Fall, den ich kenne, ist yarn remove .

Nachdem ich den größten Teil dieses Threads gelesen habe, verstehe ich nicht, was hier passiert.

Ich habe mehrere native Pakete, die jedes Mal neu erstellt werden, wenn ich yarn add für ein anderes (nicht verwandtes) Modul verwende. Es dauert ungefähr 20 Minuten, bis die CPUs meines Laptops sehr stark belastet sind. Ich kann einfach nicht so arbeiten.

Anscheinend ist es aus diesem Thread seit 19 Monaten ein Problem.

Ist es ein Fehler? Wird daran gearbeitet? Gibt es eine Problemumgehung? Soll ich wieder zu npm wechseln?

Soll ich wieder zu npm wechseln?

Ja, bis # 5470 veröffentlicht wird.

@vibl

Anscheinend ist es aus diesem Thread seit 19 Monaten ein Problem.

Es wurde tatsächlich (meistens) vor langer Zeit behoben. Dieser Thread bleibt nur für einen Randfall offen, den ich vor einigen Wochen gefunden habe, in dem Garn ein Paket neu erstellt, wenn dieses Paket eine seiner Dateien geändert hat (es glaubt, dass die Datei im Vergleich zu dem, was im ursprünglichen Download enthalten war, falsch ist, und möchte dies daher beheben es). Und für eine offene Diskussion darüber, ob remove und upgrade einen Neuaufbau durchführen sollen (dies geschieht in npm, aber vielleicht nicht)

Ist es ein Fehler?

Könnte sein. Welche Pakete werden neu erstellt? Das einzige, von dem ich weiß, dass es ein ständiges Problem ist, ist uws , daher wäre es hilfreich, mehr zu wissen.

Wird daran gearbeitet?

Der oben erwähnte spezielle Fall ist in # 5470 behoben

Gibt es eine Problemumgehung?

Wenn das hinzugefügte Paket keine Installationsskripte enthält, können Sie --ignore-scripts

Oder Sie können den Zweig aus der obigen PR überprüfen und diesen verwenden.

Es dauert ungefähr 20 Minuten

Beeindruckend. Ich bin gespannt was das für ein Paket ist.

Danke für die Antwort.

Die Pakete noise-search , level-rocksdb und jq jedes Mal neu kompiliert, wenn ich ein nicht verwandtes Paket mit yarn add hinzufüge. Mein Laptop ist etwas alt, daher dauert es sehr lange, sie gleichzeitig zu kompilieren.

Ich habe Garn 1.5.1 und Knoten 9.8.0 verwendet.

@vibl yeesh, noise-search ist definitiv der Schuldige hinter den langen Builds ...

~/Projects/yarn-test 🐒   yarn add noise-search
yarn add v1.5.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 73 new dependencies.
✨  Done in 426.15s.

über 7 min auf einem MacbookPro 😢

Wie auch immer, ich habe noise-search installiert und dann ein yarn add left-pad mit dem Code von # 5470 ausgeführt, und es hat _nicht_ eine Neuerstellung verursacht, also denke ich, dass Sie gut gehen sollten, sobald wir das zusammengeführt haben 👍

Vielen Dank :-)

Sollte ich in ein paar Tagen, ein paar Wochen oder ein paar Monaten noch einmal bei Yarn nachsehen?

Ich habe gerade festgestellt, dass dieser Fehler mit genau demselben Projekt auf demselben Laptop (Dual Boot) unter Windows 10 nicht auftritt. Er ist jedoch in den letzten drei Debian-Versionen, Ubuntu, Arch Linux und Fedora, vorhanden. Seltsam. Ich habe MacOS noch nicht ausprobiert, aber es scheint, dass einige Leute dort auch Probleme haben.

@vibl Ich bin mir nicht sicher, wann unsere nächste Veröffentlichung sein wird (ich bin nicht an dieser Planung beteiligt)

@nnmrts Ja, ich habe festgestellt, dass es sich um eine

Unter Linux mit Knoten 8 werden die Zeitstempel aktualisiert, wenn Dateien aus dem Cache in node_modules kopiert werden. Garn entscheidet, dass die Feilen unterschiedlich sind und markiert die Referenz frisch.
Dies scheint jedoch nur unter Linux Node 8 zu passieren.
Dies liegt daran, dass Node v8.5 fs.copyFile eingeführt hat, wodurch Kopien viel schneller erstellt wurden. IIRC, das an die native Dateisystemkopie weitergeleitet wird, sodass erklärt wird, warum es unter Betriebssystemen und nur in Knoten 8 unterschiedlich funktioniert.

@ Rally25rs @nnmrts Es ist definitiv keine MacOS-spezifische Sache. Kommt auch auf meinem Win10 PC vor

@stereokai Nun, das ganze Problem ist nicht spezifisch. Manchmal müssen Pakete neu erstellt werden und die Leute denken immer noch, dass es ein Fehler ist und posten ihn hier. Ohne ein solides reproduzierbares Repo für jedes Betriebssystem können wir nichts wissen.

Das lokale Zwischenspeichern von gebauten Modulen (ab # 5314) kann helfen?:

Fügen Sie Ihrem Projekt .yarnrc wie folgt hinzu:

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

Nach der ersten Installation werden vorgefertigte Module in ./<your-offline-mirror-path>/prebuilt gespeichert. yarn.lock wird auch mit vorgefertigten Varianten aktualisiert

Hat die neueste 66a0143a753cd4ade1a0fffee2174890d564c129 gezogen, und es scheint richtig zu funktionieren😎

Laden Sie die Binärdatei NOCH wiederholt herunter.

• Knoten v6.13.1
• Garn v1.6.0-20180327.1507
• Betriebssystem: Ubuntu 17.10 Linux 4.13.7-041307-generic
• ~ / .yarnrc:

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

yarn add node-sass
yarn remove node-sass
yarn add node-sass

Am Do, 29. März 2018, um 02:30 Uhr, Andrew Lane [email protected]
schrieb:

Lokales Zwischenspeichern von gebauten Modulen (ab # 5314
https://github.com/yarnpkg/yarn/pull/5314 ) kann helfen?:

Fügen Sie Ihrem Projekt .yarnrc wie folgt hinzu:

Garn-Offline-Spiegel "./""
Experimental-Pack-Skript-Pakete-im-Spiegel wahr

Nach der ersten Installation leben vorgefertigte Module in
.// vorgefertigt. yarn.lock wird ebenfalls aktualisiert
mit vorgefertigten Varianten

Zog die neueste 66a0143
https://github.com/yarnpkg/yarn/commit/66a0143a753cd4ade1a0fffee2174890d564c129 ,
und es scheint richtig zu funktionieren😎

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/932#issuecomment-376989174 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AAUAzz07Js-JQyj9n9_rsYq3cpd9Rp8qks5ti9a2gaJpZM4KVN87
.

@snowyu hast du yarn.lock, node_modules und yarn cache clean gelöscht? Wird ./yarn-offline-mirror/prebuilt nach der Installation ausgefüllt?

Es ist ein neues Projekt in Temp. Ja, ich kann die Datei node-sass-4.8.3.tgz im Cache-Ordner sehen.
Jetzt führe ich yarn cache clean . ABER NOCH Binär wiederholt herunterladen * .

`` `Bash

Garn init -y
Garn hinzufügen Node-Sass
Garn hinzufügen v1.6.0-20180327.1507
info Keine Sperrdatei gefunden.
[1/4] Pakete auflösen ...
[2/4] Pakete holen ...
[3/4] Abhängigkeiten verknüpfen ...
[4/4] Erstellen neuer Pakete ... Herunterladen von Binärdateien von https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
Erfolg Gespeicherte Sperrdatei.
Erfolg 152 neue Abhängigkeiten gespeichert.
Fertig in 11.98s.

Garn hinzufügen Node-Sass
Garn hinzufügen v1.6.0-20180327.1507
[1/4] Pakete auflösen ...
[2/4] Pakete holen ...
[3/4] Abhängigkeiten verknüpfen ...
[4/4] Erstellen neuer Pakete ... Herunterladen von Binärdateien von https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
Erfolg Gespeicherte Sperrdatei.
Erfolg 1 neue Abhängigkeit gespeichert.
info Direkte Abhängigkeiten
└─ [email protected]
info Alle Abhängigkeiten
└─ [email protected]
Fertig in 13.45s.
``

OK, ich habe einfaches Git Repo gemacht, um diesen Fehler zu reproduzieren.

https://github.com/vlmonk/yarn-bug-test

Garn führt unnötige Umbauten durch ttf2woff2 wenn ich versuche, eine Nullabhängigkeit left-pad hinzuzufügen

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
yarn
[ ... building binary package here ... ]
yarn add left-pad
[ ... rebuilding binary packages here ... ]

Ich kann dies sowohl im Host-OSX-System als auch im Docker-Container mit dem neuesten node -Image reproduzieren

NPM funktioniert in diesem Fall ordnungsgemäß:

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
npm i 
[ ... building binary package here ... ]
npm i left-pad
[ ... don't rebuild binary packages here ... ]

Meine Garnversion 1.5.1

@vlmonk passiert dies immer noch, wenn Sie https://github.com/rally25rs/yarn von @ Rally25rs klonen und den Code in # 5470 (Zweig fix-linking-rebuilding-uws-932 ) verwenden?

@karlhorky ja, das Garn left-pad immer noch ttf2woff2 left-pad

# which yarn
yarn: aliased to node /Users/monk/work/yarn/lib/cli/index.js
# yarn --version
1.6.0-0

Das Paket ttf2woff2 Dateien, die im Erstellungsschritt geändert werden. Beim nächsten Durchlauf sieht Garn, dass diese Dateien geändert wurden, und installiert das Paket neu.

Garn sollte mit dieser Situation besser umgehen: Es sollte sehen, dass sich diese Dateien während des Erstellungsschritts geändert haben, und es sollte diese geänderten Dateien als "richtige" Dateien akzeptieren und sie nicht als Grund für eine Neuinstallation behandeln.

Ich habe dies mit zusätzlicher Protokollierung überprüft (https://github.com/sth/yarn/tree/trace-rebuild). Bei der ersten Installation wird Folgendes angezeigt:

build artifacts for ttf2woff2
  modified file: build
  modified file: build/Makefile
  modified file: build/Release
  modified file: build/Release/.deps
  modified file: build/Release/.deps/Release
  modified file: build/Release/.deps/Release/addon.node.d
  modified file: build/Release/.deps/Release/obj.target
  modified file: build/Release/.deps/Release/obj.target/addon
  modified file: build/Release/.deps/Release/obj.target/addon/csrc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/addon.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/backward_references.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/block_splitter.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode_parallel.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/entropy_encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/histogram.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/literal_cost.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/metablock.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/streams.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/font.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/glyph.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/normalize.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/table_tags.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/transform.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/variable_length.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_common.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_enc.o.d
  modified file: build/Release/.deps/Release/obj.target/addon.node.d
  modified file: build/Release/addon.node
  modified file: build/Release/obj.target
  modified file: build/Release/obj.target/addon
  modified file: build/Release/obj.target/addon/csrc
  modified file: build/Release/obj.target/addon/csrc/addon.o
  modified file: build/Release/obj.target/addon/csrc/enc
  modified file: build/Release/obj.target/addon/csrc/enc/backward_references.o
  modified file: build/Release/obj.target/addon/csrc/enc/block_splitter.o
  modified file: build/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode_parallel.o
  modified file: build/Release/obj.target/addon/csrc/enc/entropy_encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/histogram.o
  modified file: build/Release/obj.target/addon/csrc/enc/literal_cost.o
  modified file: build/Release/obj.target/addon/csrc/enc/metablock.o
  modified file: build/Release/obj.target/addon/csrc/enc/streams.o
  modified file: build/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/obj.target/addon/csrc/woff2/font.o
  modified file: build/Release/obj.target/addon/csrc/woff2/glyph.o
  modified file: build/Release/obj.target/addon/csrc/woff2/normalize.o
  modified file: build/Release/obj.target/addon/csrc/woff2/table_tags.o
  modified file: build/Release/obj.target/addon/csrc/woff2/transform.o
  modified file: build/Release/obj.target/addon/csrc/woff2/variable_length.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_common.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_enc.o
  modified file: build/Release/obj.target/addon.node

Die Paketdatei https://registry.npmjs.org/ttf2woff2/-/ttf2woff2-2.0.3.tgz enthält tatsächlich diese Dateien.

Wir sehen dies auch unter OS X: Wenn Sie ein Paket mit yarn add hinzufügen, wird eine Neukompilierung aller abhängigen Pakete ausgelöst. Wir haben ein Node-Gyp-Paket mit nativem Code. Jedes Mal, wenn ein weiteres Paket hinzugefügt wird, dauert es mehr als 1 Minute. Das native Modul enthält noch nicht viel Code (es wird viel schlimmer). Dies ist mit Garn 1.5.1.

Wir verwenden yarn add ../a mit relativen Pfaden, wenn dies einen Unterschied macht.

Bitte lassen Sie mich wissen, ob es Problemumgehungen gibt oder wann diese behoben werden.

Dies ist mit Garn 1.5.1.

Dieses Problem wurde in 1.6.0 behoben, das erst vor kurzem veröffentlicht wurde.

Ich sehe das immer noch mit 1.6. Seit dem Wechsel von npm zu yarn langer Zeit wurde uws wie immer wieder aufgebaut (oder zumindest yarn wurde für uws festgefahren ungefähr 5-10 Sekunden).

Schritte zum Reproduzieren:

1. $ Garn veraltet
2. Wählen Sie ein veraltetes Paket
3. $ Garn Upgrade [Paket]

@grantila Kannst du ein komplettes package.json oder Repo mit Schritten bereitstellen, die dies mit Yarn 1.6.0 reproduzieren?

Dies geschieht immer noch am 1.6.0

Sie können dies unter https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784 wiederholen

Ich habe ein einfaches Projekt und ich sehe das auch. Das Hinzufügen oder Entfernen eines Pakets scheint jedes Mal eine vollständige Neuerstellung von mindestens einem Paket auszulösen.

"dependencies": {
    "bufferutil": "3.0.4",
    "chance": "1.0.16",
    "discord.js": "11.3.2",
    "dog-facts": "1.0.3",
    "erlpack": "discordapp/erlpack",
    "flickr-sdk": "3.7.0",
    "html-entities": "1.2.1",
    "node-opus": "0.2.7",
    "snekfetch": "4.0.0",
    "sodium": "2.0.3",
    "utf-8-validate": "4.0.1"
  }

Nachdem diese installiert wurden, fügte ich das Paket unescape , das eine Neuerstellung von sodium auslöste. Dann entfernte ich es, was eine Neuerstellung von scheinbar jedem Paket auslöste, das kompiliert werden musste. Das Hinzufügen dieses einfachen Pakets dauerte 36 Sekunden und das Entfernen dauerte 100 Sekunden!

BEARBEITEN: Verwenden von Node 8.11.1 und Garn 1.6.0 auf Debian Stretch.

@arcanis @ Rally25rs Bitte öffnen Sie das Problem erneut. Es gibt immer noch mehrere Berichte darüber, auch mit dem zusammengeführten Fix.

Ich denke, das ist eher ein @ Rally25rs- Problem :)

@grantila und upgrade werden immer alle neu erstellen. Dies ist beabsichtigt. npm macht dasselbe (ich erwähne dies in einem Kommentar irgendwo in diesem langen Thread), obwohl wir möglicherweise versuchen könnten, damit aufzuhören. Ich bin mir nicht sicher, welche Auswirkungen dies haben könnte.

Jeder andere:

In # 5680 weise ich darauf hin, dass dies immer noch passiert, wenn ein Paket seine eigenen Dateien löscht _ (warum oh, warum machen sie diese Dinge 😿) _ und Garn verfolgt das nirgendwo (wir verfolgen, welche Dateien erstellt oder geändert werden), also Es glaubt nur, dass dem Paket Dateien fehlen, und erstellt es neu.

Ich nehme an, wir können dies wieder öffnen, aber dies wurde für die meisten Pakete behoben. Wenn jemand "mich auch" hinzufügen möchte, geben Sie bitte entweder Ihre package.json an oder erwähnen Sie speziell, welches Paket ständig neu erstellt wird, da Sie möglicherweise einige Abhängigkeiten haben, die neu erstellt werden, und einige, die dies nicht tun.

Jeder kann gerne eine PR dafür machen! (Siehe meine Debugging-Kommentare in # 5680)

Es tut uns leid, dass Sie mehr Rauschen hinzugefügt haben, aber ich möchte vorschlagen, dieses Problem zu sperren und auf ein neues mit den neuesten Informationen oben zu verweisen.

Ich denke, das Problem hier hat sich ziemlich verschoben und ist zumindest teilweise gelöst. Bei all den Posts hier ist es für jemanden, der neu ist, schwierig, sich über das zu informieren, was behoben wurde und was immer noch ein Problem ist.

Ich stimme @ james-rabbit zu

Ja, du hast recht. Ich werde diesen sperren , damit die Antwort von

Wenn Sie ein Problem mit nativen Paketen haben:

• Wenn dies bei jeder nativen Abhängigkeit der Fall ist, öffnen Sie bitte ein allgemeines Problem. Dieses Problem hätte behoben werden müssen, daher erwarte ich keine baldige Lösung. Wenn Sie jedoch Reproduktionsschritte bereitstellen können, können Sie gerne eine neue Ausgabe öffnen (und Sie können auf diese verlinken, wenn Sie möchten).

• Wenn dies bei einer bestimmten nativen Abhängigkeit der Fall ist, öffnen Sie bitte auch ein Problem. Vergessen Sie jedoch nicht, den Namen der Abhängigkeit im Titel anzugeben (wie erläutert, können verschiedene Pakete aus unterschiedlichen Gründen neu erstellt werden. Behalten Sie für jedes dieser Probleme ein Problem bei den Austausch von Informationen für alle erleichtern).