<p>Garn sollte wahrscheinlich keine Pakete zwischenspeichern, die mit einem Dateipfad aufgelöst wurden</p>

Das hat mich auch reingelegt. Es muss einen Weg geben, dies zu umgehen, ohne den gesamten Cache zu leeren.

Ich denke, es gibt drei Möglichkeiten, um Garn für diesen Fall verwendbar zu machen:

1. @donaldpipowitchs Vorschlag, alle lokalen Abhängigkeiten zu ignorieren.
2. Neuinstallation lokaler Abhängigkeiten, wenn eine Datei dort später geändert wird als beim Zwischenspeichern. Dies würde erfordern, dass wir diese Metadaten behalten. Für lokale Abhängigkeiten können wir Zeilen wie diese in die Spalte "Gelöst" einfügen: file://<path>@<cache_timestamp>
3. Ignorieren von Paketen nach Paketnamen mit Befehlen wie yarn cache rm <package> und yarn cache add <package> . Für alle Abhängigkeiten.

Ich würde gerne sehen, dass der zweite Vorschlag umgesetzt wird. Es sei denn, die dritte Option könnte auch für andere Fälle nützlich sein. Zum Beispiel kann yarn cache add <package> verwendet werden, um den Cache für bereits zwischengespeicherte Abhängigkeiten zu aktualisieren, falls beim Herunterladen einer Abhängigkeit etwas schief gehen könnte.

@hantuzun warum überhaupt lokale Abhängigkeiten zwischenspeichern? Sie sind sowieso lokal, so dass es schnell ist, unabhängig davon, ob es zwischengespeichert ist oder nicht.

@ satya164 du hast recht. Obwohl ich eher zum dritten Ansatz geneigt bin, würde dies helfen, wenn eine Abhängigkeit vom Netzwerk absichtlich geändert wird.

So etwas wie yarn cache ignore <package> wird nützlich sein. Aber ich denke, sie müssen sich nicht gegenseitig ausschließen. Das Ignorieren eines Pakets ist nützlich, erfordert jedoch manuelle Arbeit. Dateiabhängigkeiten könnten ohne zusätzlichen Aufwand zum Funktionieren gebracht werden, wenn sie standardmäßig ignoriert würden.

Kann mir jemand die interne Logik erklären?

Mein Verständnis:
Wenn eine Abhängigkeit mit file: angetroffen wird, wird file-resolver.js aktiviert. Es heißt, die Abhängigkeit sollte kopiert werden und wird nicht gehasht . Bedeutet kein Hash, dass es nicht schon zwischengespeichert werden sollte ...? Aber das copy-fetcher.js scheint den Hash auf eine leere Zeichenfolge zu setzen, anstatt null behalten ... Ist das ein Problem?

@bestander oder @kittens Vielleicht könntest du das ein bisschen mehr erklären ...? Würde gerne ein bisschen Hilfe bekommen, um eine PR zu erstellen ♥

Hash bedeutet den MD5-Hash, der zum Beispiel für Tarball-Fetcher verwendet wird.
Dieser Hash wird dann zur zukünftigen Überprüfung zur Datei yarn.lock hinzugefügt und beim Speichern des entpackten Ordners im Cache auch an den Ordnernamen angehängt.
Sie graben in die richtige Richtung, danke, dass Sie sich damit befasst haben. Eine PR ist sehr willkommen.
Sie können wahrscheinlich mit einer PR beginnen, die fehlerhafte Komponententests hinzufügt

Sie können wahrscheinlich mit einer PR beginnen, die fehlerhafte Komponententests hinzufügt

Okay, danke für deine Antwort. Soll ich Sie als Rezensenten in der PR anpingen oder sollte ich jemand anderen (oder niemanden) anpingen ...?

Ja, ping mich an

@bestander wahrscheinlich sollte dieses Problem nicht geschlossen werden, da es noch nicht behoben ist?

Ja, es sollte wieder geöffnet werden. Es wurde geschlossen, weil ich im Titel meiner PR "Fixes # 2165" geschrieben habe. Am Anfang dachte ich, es wäre eine laufende PR, aber um diesen Fehler zu beheben, wollen wir zwei PRs: Der erste fügte einen Unit-Test hinzu (die Behauptung, die fehlschlagen würde, ist nicht wirklich aktiv, so dass CI nicht explodiert) und die zweite wird es tatsächlich beheben.

Entschuldigung, Github schließt Probleme, wenn PR zusammengeführt wird

Also ist das offensichtlich immer noch ein Problem? Es ist ziemlich nervig, sich zu entwickeln, um ehrlich zu sein. Es verursacht eine kleine Störung für mich auf persönlicher Ebene bei der Arbeit, wo ich file: , um eine modulare Entwicklungsumgebung zu erstellen. Der blöde Teil ist, dass jedes lokale Paket, das ich bearbeite (unter Verwendung des Pfades file: in package.json ), dies erfordert, um den aktualisierten Inhalt abzurufen:

Bearbeiten des Inhalts meines eslint-config-base-eslint-Pakets

yarn cache clean && rm -rf node_modules/eslint-config-base-eslint && yarn install --force && yarn lint

Jeder kann gerne zum Projekt beitragen.
Es kann alles Mögliche sein - einen fehlerhaften Integrationstest für diesen Fall einzureichen, einen Fix zu erstellen oder jemanden davon zu überzeugen, an dem Fix zu arbeiten.
Wenn Sie sich über den besten Weg unterhalten möchten, dies zu erreichen, finden Sie Hilfe auf dem Discord-Kanal.

Ich denke tatsächlich, dass das Update 10-15 Codezeilen umfassen sollte, es wird wahrscheinlich viel Zeit sparen, es früher zu reparieren

Zu Ihrer Information: Es könnte sein, dass dieses Problem auch für langsame linking dependencies Schritte relevant ist. Siehe meinen Kommentar hier: https://github.com/yarnpkg/yarn/issues/1496#issuecomment -282688818.

Es tut uns leid. Ich konnte keine Zeit finden, eine weitere PR für dieses Problem zu erstellen :( Ich war (und bin) sehr beschäftigt.

@bestander Dies ist ein ziemlich großer Blocker für mich, der an einem Projekt mit mehreren Modulen arbeitet. Wenn ich die Code-Links und -Kommentare von @donaldpipowitch richtig lese, kann der hash (anstelle von null) erstellen, um eine Neuinstallation zu erzwingen? Sagen Sie eine UUID oder einen aktuellen Zeitstempel? Verzeihen Sie mir, wenn mir etwas fehlt, ich bin nicht mit der Funktionsweise des Codes vertraut.

Ein neuer Cache mit Zeitstempel und UUID klingt nach einem vernünftigen Hack.
Idealerweise sollten wir die Dateien direkt ohne den Cache kopieren, aber es kann eine sein
komplexere Änderung.
Senden Sie eine PR

Am Dienstag, den 7. März 2017 um 03:38 Uhr schrieb Matt Traynham [email protected] :

@bestander https://github.com/bestander Dies ist ein ziemlich großer Blocker
Ich arbeite an einem Projekt mit mehreren Modulen. Wenn ich @donaldpipowitch lese
https://github.com/donaldpipowitch 's Code-Links und Kommentare
Richtig, könnten wir den File-Resolver einen neuen Hash erstellen lassen (anstelle von
null) jedes Mal, wenn es versucht zu lösen, so dass eine Neuinstallation erzwungen wird? Sagen Sie eine UUID
oder aktueller Zeitstempel? Vergib mir, wenn mir etwas fehlt, ich bin nicht vertraut
mit der Art und Weise, wie der Code funktioniert.

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

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

@bestander Zu Ihrem letzten Kommentar: Wäre es nicht noch sinnvoller, ihn zu verknüpfen, anstatt die Dateien zu kopieren? Oder gibt es einen Grund, das nicht zu tun?

@danrot Windows scheint Admin zu erfordern, um Symlink.
Außerdem wird die Rekursion durcheinander gebracht, um Knotenmodule zu finden

Symlink ignoriert auch .npmignore und ähnliches. (Was derzeit ebenfalls ignoriert zu werden scheint. Was problematisch sein könnte: https://github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818)

Gibt es eine Problemumgehung dafür, die derzeit das Löschen des gesamten Caches verhindert? Leider scheint es keinen Befehl yarn cache rm package .

@ rhys-e Ich benutze dieses kleine Skript:

#!/bin/sh
if [ $# != 1 ]
then
   echo Usage $0 package-name
   exit 1
else
    echo Reinstalling $1
fi

dir="node_modules/$1"

if [ -d $dir ]
then
    rm -fr $dir
fi

cache=`yarn cache dir`/npm-${1}*
#        echo $cache
rm -fr $cache && yarn install --force

Hat jemand versucht , nur zu yarn link all lokalen Abhängigkeiten von postinstall ? Sieht nach einer geeigneten Lösung aus, bis die richtige Lösung gefunden wurde.

Ich denke, die Idee ist, die Versionsnummer des Pakets nicht bei jeder Änderung für die lokalen Abhängigkeiten aktualisieren zu müssen. Eine Garnverbindung würde dich dazu zwingen, oder? (habe es nicht versucht)

Auf meiner Seite habe ich schließlich ein Skript in der PreInstall-Phase aufgerufen, das vergleicht, was sich im Quellordner und im Ordner node_modules für lokale Abhängigkeiten befindet. Wenn ein Unterschied festgestellt wird, wird lediglich die zwischengespeicherte Abhängigkeit und die Integritätsdatei entfernt (um eine Neuinstallation zu erzwingen). Wenn sich also nichts ändert, ist die Garninstallation ziemlich schnell (es gibt nicht viele lokale Abhängigkeiten) und wenn es die veraltete zwischengespeicherte Version gibt, wird sie nicht verwendet.

Der @ lucdew- Link erstellt im Grunde genommen einen Symlink unter der Haube, was bedeutet, dass die neueste lokale Version verwendet wird. Aber ich denke, ein Skript zu haben, das vor der Installation den Cache von bestimmten Deps bereinigt, ist momentan die richtige Lösung.

Ich habe verschiedene Kombinationen getestet, um Änderungen im lokalen Paket zu umgehen, die in der installierten Version eines übergeordneten Projekts unter ./node_modules/ nicht aktualisiert wurden. Ich finde, dass genau dies ausreichen würde, ohne dass die ./node_modules/ gelöscht werden müssten.zuerst:

yarn cache clean; yarn upgrade file:../<package>

Es ist unnötig zu erwähnen, dass das manuelle Erzwingen der globalen Cache-Bereinigung nicht erforderlich sein sollte, um lokale Pakete zu aktualisieren / zu aktualisieren.

@fungilation Um dieses Problem zu umgehen , können Sie auch npm verwenden, um lokale Abhängigkeiten zu installieren und so zu vermeiden, dass bei jeder Aktualisierung der gesamte Cache verloren geht.

Gemäß # 2860 und dem anschließenden Zusammenführungs-Commit https://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24 können Sie jetzt file: Protokollabhängigkeiten mit "aktualisieren"

yarn install --force

Bearbeiten oder aktualisieren Sie das jeweilige Paket (wusste nicht, dass dies auch funktioniert). Wenn sich die Abhängigkeitsversion nicht geändert hat, wird die Sperrdatei dadurch nicht geändert, die neuere Version wird jedoch weiterhin nach unten kopiert.

yarn upgrade [file protocol package name]

Durch die PR-Änderung wird die Abhängigkeit im Cache ungültig und lokal neu installiert. yarn install funktioniert auch, wenn sich die Abhängigkeitsversion geändert hat, wodurch die Datei yarn.lock ungültig wird. Sie müssen weder den Cache leeren noch das Modul aus der lokalen Installation löschen.

Mir wurde auch klar gemacht, dass es einen aktiven RFC zum Verknüpfen von Abhängigkeiten gibt, möglicherweise mit einem link: -Protokoll. Dies kann hier unter https://github.com/yarnpkg/rfcs/pull/34 verfolgt werden.

@mtraynham Vielen Dank für Ihre Pull-Anfrage! 👌 Das ist großartig. Gibt es Gründe, warum --force benötigt wird? Ich weiß momentan nicht einmal genau, was es gerade tut, ohne es nachzuschlagen :) Ich frage nur, weil npm kein --force -Flag benötigt und es schön gewesen wäre, sich wie npm zu verhalten.

Bearbeiten Es sieht so aus, als ob yarn upgrade [dependency] funktioniert. Ich möchte darauf hinweisen, dass dies nicht immer die Sperrdatei ändert, die nur Änderungen der package.json-Version widerspiegeln sollte. Ich habe meinen ursprünglichen Beitrag aktualisiert, da ein Upgrade wahrscheinlich angemessener ist.

Die kurze Version ist, dass Yarn nichts mit Cache-Resolvern macht, wenn sich die Sperrdatei nicht geändert hat. Daher müssen wir die Prüfung der Sperrdatei überspringen und den Cache fragen, ob es eine neuere Version gibt. Dies kann mit upgrade oder install --force

Pro yarn install --force Dokumentation

"Es werden alle Pakete wiederhergestellt, auch die zuvor installierten".

Dies bedeutet wirklich, dass die Integritätsprüfung der Sperrdatei übersprungen wird. Die Überprüfung der Integrität von Sperrdateien wird normalerweise bestanden, wenn Sie die Datei package.json nicht ändern und ordnungsgemäß aussteigen. Beim Überspringen wird der Cache aufgefordert, nach fehlenden / nicht übereinstimmenden Abhängigkeiten für die Sperrdatei zu suchen, diese herunterzuladen, falls sie fehlen, und neuere / fehlende Abhängigkeiten lokal zurückkopieren. Dann werden npm install / postInstall Skripte ausgeführt.

Die PR-Änderung macht jetzt die Abhängigkeit von file: im Cache ungültig und kopiert die neue Version lokal nach unten. Zuvor wurde die Abhängigkeit von file: niemals ungültig. Wenn Sie bei anderen Protokollen Ihre Datei package.json nicht geändert haben, bleiben sie unverändert (im Cache und lokal).

Was bedeutet das für uns? Ich habe ungefähr 60 Abhängigkeiten von einem Projekt (von Angular bis Webpack) mit einer Abhängigkeit von file: . Bei einem zweiten install --force , bei dem ich nur die lokale Abhängigkeit aktualisieren möchte, dauert es ungefähr ~ 5 Sekunden (von ~ 1,5 Sekunden für yarn install ). Für mich ist das ziemlich vernachlässigbar und ich bin wirklich sehr beeindruckt davon, wie wenig Arbeitsgarn während des gesamten Prozesses zu leisten versucht.

Wenn es einen anderen CLI-Befehl gibt, mit dem die Sperrdateiprüfung übersprungen und der Cache nur auf die jeweilige Dateiabhängigkeit überprüft werden kann, ist dies wahrscheinlich noch schneller, aber ich habe keinen gefunden.

Trotzdem würde ich das immer noch als Pflaster bezeichnen. Dies könnte durch eine bessere Lösung wie link: ; Ich glaube nicht, dass es irgendjemand wirklich interessiert, lokale Abhängigkeiten zwischenzuspeichern. Zumindest ist der zusätzliche Aufwand für die Verwendung von install --force oder upgrade meist fahrlässig und Sie müssen nicht mehr yarn cache clean; mv node_modules /tmp/ .

Gute Antwort. 👏 Danke, dass Sie dies aufgeschrieben haben.

Überschreibt Garn lokal verknüpfte Projektdateien mit Dateien aus dem Garncache? (weil es so aussieht, als ob das passiert)

Die PR-Änderung macht jetzt die Datei: Abhängigkeit im Cache ungültig und kopiert die neue Version lokal nach unten.

Bedeutet dies, dass jedes Mal, wenn ich $ yarn in einem Paket aufrufe, dessen Abhängigkeit "foo": "file:../" ist, eine neue Kopie von "file:../" erstellt wird?

ZB habe ich ein Paket mit mehreren Beispielen, die auch Pakete sind:

foo/
foo/examples/
foo/examples/example-1/
foo/examples/example-2/
foo/examples/example-3/
...
foo/examples/example-10/

Und es sieht so aus, als hätte ich jetzt foo 10 mal im Garn-Cache. Ich teste meine Beispiele auch bei jeder Versionsänderung von foo (und ich habe mehrere Module auf diese Weise konfiguriert, nicht nur foo ), sodass mein Garn-Cache derzeit sehr schnell wächst.

Ist das das richtige Verhalten?

Ich denke, es ist eine bessere Alternative als eine veraltete Version in Ihrem Cache.
Mit Garn 0.26 können Sie link: , um Symlinks zu erstellen, anstatt Dateien zu kopieren.
Außerdem arbeiten wir an Arbeitsbereichen, die die Erstellung von Symlinks automatisieren, https://github.com/yarnpkg/yarn/issues/3294

Ja, ich freue mich auf Arbeitsplätze 👍

link: funktioniert noch nicht mit npm, oder? (Da https://github.com/npm/npm/pull/15900 noch geöffnet ist.)

Ab npm 5 Patchnote werden Dateien jetzt automatisch mit der Syntax file: verknüpft:

npm install ./packages/subdir erstellt jetzt einen Symlink anstelle einer regulären Installation. file: //path/to/tarball.tgz wird nicht geändert - nur Verzeichnisse sind mit Links verknüpft. (# 15900)

Also ja, es gibt kein link mit npm.

npm install ./packages/subdir erstellt jetzt einen Symlink anstelle einer regulären Installation

Ein bisschen unglücklich. Datei-Deps haben sich nie gleich verhalten, da alles kopiert wurde (einschließlich node_modules ) und das Feld .npmignore oder files beachtet wurde. Jetzt ist es schlimmer mit Symlink.

Ich denke, file: and link: könnte weiter verbessert werden, es gibt verschiedene Strategien, die ihre eigenen PROs und CONs haben, und Yarn sollte es den Leuten ermöglichen, eine auszuwählen.
Zum Beispiel könnte knit RFC als eine der Strategien https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md implementiert werden

@bestander

Ich denke, es ist eine bessere Alternative als eine veraltete Version in Ihrem Cache.

Zumindest würden Sie glauben, bis Ihnen der Speicherplatz ausgeht und Sie feststellen, dass Ihr Garn-Cache mehrere zehn Gigabyte für Millionen völlig nutzloser Dateien verwendet .
IMO, die das Ganze schwerwiegender macht als zuvor, weil Sie es erst herausfinden, wenn Sie Ihr Entwicklungssystem vorübergehend kaputt gemacht haben.

Hallo Leute, gibt es Updates zu diesem Thema? Es ist wirklich ein großes Problem für uns, insbesondere wenn wir an mehreren Produkten gleichzeitig arbeiten, die von denselben verknüpften Multi-Abhängigkeiten abhängen. Gigabyte Cache an einem Tag der Entwicklung usw. Könnten Sie es vielleicht zumindest optional machen und das Caching für solche Pakete deaktivieren?

@nikdojo Verwenden Sie das Protokoll link: für Abhängigkeiten anstelle von file: . Es werden Symlinks verwendet. Es wurde in 0.26 eingeführt .

Alternativ können Sie Arbeitsbereiche verwenden, wenn Sie viele projektübergreifende Abhängigkeiten haben.

@mtraynham Danke für den Hinweis, ich habe versucht, Informationen link: Protokoll

@bestander Übrigens, wie Sie wissen, unterstützt react-native keine Symlinks. Wenn wir also mit rn libs arbeiten, ist dies immer noch ein großes Problem.

Das wurde nie gelöst, oder? Sie müssen Linklocal (NPM-Pakete) verwenden, um lokale Pakete zu verknüpfen (dies sollte die Standardmethode sein, wenn Garn Pakete aus dem lokalen Dateisystem verwendet - unter Verwendung von Junctions oder Symlinks unter Windows anstelle von Caching). Ein neues yarn install überschreibt dann alles mit alten Sachen aus dem Cache und Sie müssen erneut mit dem Verknüpfen beginnen.

Können wir weniger Architekturastronauten sein und lokale Pakete einfach nicht zwischenspeichern? Dieses Problem ist jetzt 1,5 Jahre alt und ich habe es satt, jedes Mal yarn add ../<another-local-package> auszuführen, wenn ich etwas in another-local-package ändere.

Hallo @fungilation
Ich habe ein weiteres verwandtes Problem geöffnet: # 6037

funktioniert nicht
Ich habe in Datei App.js gelegt
console.log ('hier sind wir'), und es wurde nicht ausgegeben.
Entfernen Sie dann alle Dateien und die Ausgabe erfolgt weiterhin aus dem Cache.
Wie vermeide ich das?

Garn hat mich in dieser Frage wirklich im Stich gelassen. Es war großartig für alles andere, außer für dieses.

Ich habe versucht, zu Testzwecken eine neue Version eines lokalen Pakets zu installieren, und ich erhalte immer wieder das alte Paket, egal was ich tue.

Ich habe es versucht:

1. Reinigen des Garncaches ( yarn cache clean package-name )
2. yarn add mit --force
3. Entfernen von node_modules/package-name und yarn add erneut
4. Aktualisieren der Versionsnummer und des Dateinamens des lokalen Pakets ( Garn installiert weiterhin den Inhalt der alten Version , obwohl die Installation der neueren
5. Kombinationen aller oben genannten

Das ist lächerlich und ich habe fast 4 Stunden meines Tages damit verbracht.

Wir brauchen die Fähigkeit, lokale Pakete zu entwickeln und neu zu installieren . Ich verlasse mich auf Garn, um eine Datei im Ordner .bin zu installieren, daher kommt yarn link nicht in Frage.

@ Yarn Developers: Können Sie ein lokales Paket installieren, Änderungen an diesem lokalen Paket vornehmen und die Änderungen dann durch eine erneute Installation übernehmen?

@gregjacobs Ich hatte Erfolg mit yarn install --force

@ Jonathantorley Ich habe es gerade noch einmal mit --force versucht und es funktioniert immer noch nicht mit Garn 1.12.3

Für andere, die mit diesem Problem konfrontiert sind: Eine Problemumgehung, mit der ich dies tatsächlich zum Laufen gebracht habe, bestand darin, die Versionsnummer des abhängigen Pakets zu erhöhen. Ein bisschen nervig, und Sie müssen daran denken, es bei jeder Änderung zu tun (es sei denn, Sie können es skripten).

yarn sollte diese Problemumgehung bei der Installation lokaler Pakete definitiv nicht erfordern

Ich habe yarn upgrade MY_PACKAGE_NAME in preinstall Skript hinzugefügt und es wird gut auf die neueste NPM-Version aktualisiert. (Trotzdem muss ich die NPM-Version manuell anstoßen).

Es scheint, dass yarn add file:PATH jetzt immer den neuen Inhalt in Garn 1.13.0 aktualisieren.
yarn install immer noch nicht.

@leavesster Immer noch nichts für mich.

Ich muss das tgz umbenennen, damit es aktualisiert wird

Versuchen Sie es mit dem Befehl link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn add file:PATH hat den neuen Inhalt für mich nicht aktualisiert. Darüber hinaus werden Dateien in package.json und .npmignore nicht berücksichtigt.

Es funktioniert, wenn Sie die Version Ihres Pakets ändern.

Wenn Sie möchten, dass yarn add file:PATH Dateien in package.json und .npmignore berücksichtigt, müssen Sie yarn pack in Ihrer lokalen Paketabhängigkeit ausführen und dann, wo Sie es installieren möchten, yarn add file:path-to-local-pacckage.tgz ausführen

Versuchen Sie es mit dem Befehl link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn link soll nicht das gleiche Problem lösen. Es ist nicht gut, wenn jemand das npm-Paket so möchte, als ob es unter Berücksichtigung der Dateien in package.json und .npmignore veröffentlicht wurde

@leavesster Immer noch nichts für mich.

Ich muss das tgz umbenennen, damit es aktualisiert wird

Ich habe kein tgz in meinem Paket, das ich mit yarn add file: PACKAGE_PAH zum aktuellen Projekt hinzufüge. Ich habe nur js Code in meinem Paket. Vielleicht tgz immer noch falsch?

Ich arbeite auch nicht für mich

@bestander warum dieses Problem geschlossen? Das Garn speichert immer noch lokale Dateien und TGZ-Pakete zwischen. Arbeitsbereiche sind in einigen Fällen keine Lösung, z. B. wenn ein Paket Deps mit bestimmten Versionen enthält und andere Pakete devDeps dieselben Pakete wie das erste haben, aber mit anderen Versionen, und wenn Sie ein Paket mit einem anderen verknüpfen, wurde Ihr Projekt beschädigt .

Ich habe das gleiche Problem wie @gregjacobs. yarn cache clean package hat nicht geholfen. Aber ich habe herausgefunden, dass Sie, wenn Sie yarn add path/to/package.tgz installieren und dann das Archiv durch ein anderes ersetzen, eine neue Version installieren können. Ändern Sie einfach den Pfad wie yarn add path/to/../to/package.tgz , sodass der absolute Pfad der gleiche ist, aber für Garn ist er anders .

Ich verstehe nicht, wo sonst Garn zwischengespeicherte Pakete nach Auflösungspfad speichern, selbst yarn cache list --pattern package ist leer.

Ich denke, das Problem liegt irgendwo hier https://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58 -L63

Was ist los:

• Von URL path/to/package.tgz wird Hash generiert (deshalb führen path/to/package.tgz und path/to/../to/package.tgz zu unterschiedlichen Hashes)
• Mit diesem Hash wird ein temporäres Verzeichnis für das Paket erstellt (wie dieses /Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 )
• Für den ersten Lauf isValidModuleDest false und alles läuft gut
• In diesem Verzeichnis extrahierte Tarball-Pakete
• Dateien aus diesem Verzeichnis, die im Projekt installiert sind
• Sie ändern Entwicklungsprojektquellen und erstellen / packen den neuen Paket-Tarball mit demselben Namen und Speicherort wie den vorherigen
• Sie versuchen, einen neuen Tarball zu installieren, aber der generierte Hash ist derselbe wie zuvor, und das temporäre Verzeichnis wurde nach dem ersten Start nicht gelöscht
• In dieser Zeit geben isValidModuleDest true
• Und Garn installieren alte Version Ihres Pakets
• Sie führen yarn cache clean package , aber das temporäre Verzeichnis bleibt unberührt

@bestander können wir einfach das temporäre Verzeichnis hier entfernen https://github.com/yarnpkg/yarn/blob/master/src/config.js#L431 ?

Angesichts des gleichen Problems benötigt der Cache unter dem temporären Ordner 10 GB, nachdem ich nur einen Tag an meinem lokalen Paket gearbeitet habe!

Können wir dieses Problem erneut öffnen? Wir stehen vor dem gleichen Problem. Zwei Projekte, die per Datei auf ein anderes Paket verweisen:. Nach einigen Builds in unserem CI / CD-Server nimmt der Cache-Ordner viel Platz ein.

Ich denke, das Link-Protokoll ist die beste Lösung dafür. File: // funktioniert nicht, da es immer noch manuelles Reinigen der Caches und Erzwingen der Installation erfordert

https://github.com/yarnpkg/yarn/issues/2165#issuecomment -345825904

Machen Sie einfach Ihre Abhängigkeit so etwas

"<package>": "link:./libs/<package>"

@alxtz funktioniert das Verbindungsprotokoll mit Paketen in tgz?

Ich denke, das Link-Protokoll ist die beste Lösung dafür. File: // funktioniert nicht, da es immer noch manuelles Reinigen der Caches und Erzwingen der Installation erfordert

# 2165 (Kommentar)

Machen Sie einfach Ihre Abhängigkeit so etwas

"<package>": "link:./libs/<package>"

Vielen Dank dafür, dass dies das Verhalten von NPM wiederholt, das file:.. Referenzen in node_modules symlink. Es scheint nicht dokumentiert zu sein, zumindest nicht hier, wo ich es erwarten würde: https://yarnpkg.com/lang/en/docs/package-json/

Leider kann link nicht in allen Fällen verwendet werden.

Zum Beispiel benötige ich eine Shared / Peer-Abhängigkeit von meinem SDK-Paket, die ich bei Änderungen für die lokale Entwicklungsarbeit verknüpfe.
Mit link erkennt Garn nicht, dass es sich bei der Abhängigkeit um eine Shared / Peer-Abhängigkeit handelt, und verwendet das lokale Paket, in dem sich der Symlink befindet, was falsch ist.

Ich habe yarn pack neben yarn add file:<path_to_packed_tgz> , um dies zu umgehen.
Ich kann das Paket zwar jedes Mal umbenennen, wenn ich es packe, und es in mein Repo einfügen, um nicht den gleichen Hash zu generieren, wie bei @wKich fantastischer Entdeckung, aber es ist verdammt ärgerlich.

Ich habe das Repo gegabelt und eine zusätzliche Klausel in die if-Anweisung eingefügt, um zu verhindern, dass Garn jemals ein lokales .tgz-Paket aus seinem Cache lädt, wenn es mit yarn add file:<path> .

const dest = this.config.getTemp(crypto.hash(url));
// If specified using file: never load from cache
if (!url.match(/file:/) && (await this.config.isValidModuleDest(dest))) {
  // load from local cache
} else {
  // continue as if it's a new package
}

Ich kann eine PR machen, wenn die Leute es wollen, obwohl ich das noch nie gemacht habe und es eine ziemlich hackige Lösung ist.
Könnte jemand bestätigen, ob dieser Ansatz weiterhin die lokalen Pakete zum Garncache hinzufügt oder nicht?

@ojboj für jetzt, yalc könnte helfen, bis dies eine richtige Lösung bekommt. Es hat sehr gut funktioniert, Pakete vor dem Veröffentlichen lokal zu testen.

@souporserious Genau das brauchte / wollte ich, vielen Dank!

Wahnsinn, das ist nach so vielen Jahren immer noch ein Problem.

Ist es in [email protected] behoben?

@wKich ich glaube schon! Ich habe es nicht persönlich getestet, aber es sieht so aus, als würden sie die lokale Entwicklung durch das neue Portalprotokoll lösen.

Ich erhalte immer noch den Fehler "Entpacken im selben Ziel" unter Verwendung des link: -Protokolls und es verweist auf mein Cache-Verzeichnis. Es scheint mir also, dass Garn immer noch link: Abhängigkeiten zwischenspeichert. Ich verweise auf 2 Kopien desselben lokalen Pakets, die in den Ordner .deps/ jeder App kopiert wurden, die sie verwendet - front-end und renderer im Fehler unten. (Kann aus nicht verwandten Gründen nicht mit dem Original verknüpft werden)

warning Pattern ["@horizon/common<strong i="11">@link</strong>:packages/front-end/.deps/@horizon/common"] is trying to unpack in the same destination "/home/garyo/.cache/yarn/v6/[email protected]/node_modules/@horizon/common" as pattern ["@horizon/common<strong i="12">@link</strong>:packages/renderer/.deps/@horizon/common"]. This could result in non-deterministic behavior, skipping.