@chinesedfan Hast du yarn upgrade-interactive ausprobiert?

@milesj Ja, es führt zum gleichen Ergebnis und ich habe auch die Reproduktionsschritte in der Problembeschreibung aktualisiert.

Das liegt daran, dass yarn add [email protected] Ihre package.json auf _exakt_ Version 1.0.0 setzt, wie Sie es angefordert haben.

yarn upgrade respektiert Ihren Semver-Bereich von package.json, und da Sie genau Version 1.0.0 angegeben haben, wird kein Upgrade auf andere Versionen angeboten.

Sie können dies auf zwei Arten lösen:

• yarn upgrade --latest ignoriert den Semver-Bereich und sieht, was in der Registrierung als latest gekennzeichnet ist.
• Ändern Sie die Datei package.json, um einen Versionsbereich wie ^1.0.0 und dann yarn upgrade zu akzeptieren (möglicherweise müssen Sie zuerst yarn install eingeben, damit die Sperrdatei für den geänderten Bereich aktualisiert wird).
• Geben Sie explizit eine Version für upgrade an, z. B. yarn upgrade [email protected] oder yarn upgrade is-alphanumerical@^1.0.0

Bearbeiten:

Tut mir leid, mir ist gerade aufgefallen, dass es unterschiedliche Paketnamen gibt. alphanumerical und alphabetical sehen auf den ersten Blick gleich aus :)

Richtig, da es kein Upgrade für is-alphanumerical gibt, wird der Abhängigkeitsbaum nicht tiefer durchlaufen, um seine transitiven Abhängigkeiten zu handhaben.

Sie könnten versuchen, das --force -Flag hinzuzufügen und zu sehen, ob es dadurch zu den Unterabhängigkeiten wird. Ansonsten denke ich, dass Sie Recht haben, es gibt keinen einfachen Weg, das zu tun, außer yarn remove is-alphanumerical und yarn add is-alphanumerical

@rally25rs Danke für deine Antwort! Ich habe 2 weitere Fälle getestet.

• yarn upgrade is-alphabetical --force geht auch nicht.
• yarn upgrade is-alphanumerical aktualisiert ALLE seine untergeordneten Abhängigkeiten, auch wenn es bereits die neueste Version ist.
  
  
  
  • Aber wenn ich nur eine bestimmte Unterabhängigkeit aktualisieren möchte, ist das immer noch nicht sehr praktisch.
  
  

Ja, das ist im Moment ein großes Problem mit Garn. und es ist bereits in Diskussion bei #2394

Duplikat Nr. 2394

Bitte erneut öffnen: Es ist kein Duplikat.

2394 beschreibt das Duplizieren des Pakets meck-test-bb (indirekte Abhängigkeit):

Ich habe zwei Kopien von meck-test-bb

Dieses Problem beschreibt nur die Möglichkeit, die indirekte Abhängigkeit (irgendwie) zu aktualisieren.

@rally25rs Vergib mir zu pingen.

@rally25rs , bitte, Sie haben beide nicht duplizierten Probleme geschlossen, es ist falsch. Geben Sie uns bitte die Möglichkeit, indirekte Abhängigkeiten zu aktualisieren!

Entschuldigung, bei dem anderen Thema gab es einige Verwirrung. Ich dachte ursprünglich, 2394 würde nach einer Möglichkeit fragen, eine transitive Dep mit einem --deep -Flag oder so ähnlich zu aktualisieren, also hatte ich dieses Problem als Duplikat davon markiert. Später, nach dem erneuten Lesen von 2394, denke ich, dass es um etwas anderes ging, das kein Duplikat davon ist, wie ich ursprünglich dachte.

+1 für diese Funktionsanfrage. Auch ein Beispiel für jemanden wie mich, der in der Zwischenzeit eine bestimmte indirekte Abhängigkeit manuell aktualisieren muss:

Die gegebene explizite Abhängigkeit jsonwebtoken hat die implizite Abhängigkeit jws^3.0.0 in das anfällige jws=3.1.4 aufgelöst: und Sie müssen es stattdessen in das gepatchte 3.1.5 auflösen:

Löschen Sie den Eintrag jws zB unten aus der Garn.lock und führen Sie yarn erneut aus. Die indirekte Abhängigkeit und alle betroffenen Pakete werden aktualisiert, ohne andere Dinge zu berühren (zumindest auf Garn v1.3)

jws@^3.0.0, jws@^3.1.4:
  version "3.1.4"
  resolved "https://registry.npmjs.org/jws/-/jws-3.1.4.tgz#f9e8b9338e8a847277d6444b1464f61880e050a2"
  dependencies:
    base64url "^2.0.0"
    jwa "^1.1.4"
    safe-buffer "^5.0.1"

Bearbeiten: Interpunktion

@alex-thewsey-ibm, danke für die Problemumgehung!

Gearbeitet an Garn v1.7.

ty, gearbeitet Garn 1.9.2

Könnte helfen, Garn mit selektiver Abhängigkeit resolutions , selbst wenn es sich um eine einzelne Abhängigkeit handelt. Danke an @remolueoend für den Hinweis!
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

Aus den Dokumenten:

{
  "name": "project",
  "version": "1.0.0",
  "dependencies": {
    "left-pad": "1.0.0",
    "c": "file:../c-1",
    "d2": "file:../d2-1"
  },
  "resolutions": {
    "d2/left-pad": "1.1.1",
    "c/**/left-pad": "1.1.2"
  }
}

Wir benötigen diese Funktion im Autoprefixer, um Benutzern vorzuschlagen, wie sie caniuse-lite in ihrem yarn.lock https://github.com/postcss/autoprefixer/issues/1184 aktualisieren können

Selbes Problem hier. Ich habe erwartet, dass yarn upgrade caniuse-lite browserslist die Unterabhängigkeit aktualisiert. Das hat es nicht getan, und es hat mir auch keine Fehlermeldung gegeben, dass es nicht aktualisiert werden kann, weil es keine Abhängigkeit ist.

Das Löschen der relevanten Sperrdateieinträge und das erneute Ausführen yarn , wie @alex-thewsey-ibm vorgeschlagen hat, hat das unmittelbare Problem für mich behoben.

Es ist seltsam für mich, dass dem Garn diese Eigenschaft fehlt. Ich bin neu in Garn (und npm), also gehe ich davon aus, dass es einen Weg geben muss, dies zu tun. Ich bin mir immer noch nicht ganz sicher, ob es eine nicht offensichtliche Möglichkeit gibt, dies zu tun, die niemand in diesem Thread kennt, oder ob es wirklich keine Möglichkeit gibt, dies zu tun.

Wenn es wirklich keine Möglichkeit gibt, eine transitive/indirekte Abhängigkeit in der Sperrdatei zu aktualisieren, ohne sie zu package.json hinzuzufügen ... verstehe ich nicht, wie Garnbenutzer darauf verzichten.

Dies ist meiner Meinung nach ein unerwartetes Verhalten. Ich habe kürzlich versucht, Lodash mit yarn upgrade [email protected] zu aktualisieren, und es wurde immer noch nicht für vorübergehende Abhängigkeiten aktualisiert.

Ich hatte immer noch alle Versionen major (^4.XX) und patch (~4.17.X), die auf die alte Version verweisen.

Die einzige Möglichkeit, dies zu beheben, besteht darin, yarn.lock manuell zu bearbeiten und dann möglicherweise yarn upgrade auszuführen, um die Änderungen zu konsolidieren. Von einem so weit verbreiteten Tool würde ich etwas Besseres erwarten.

Ist dies ein anerkannter Fehler oder Garn ist standardmäßig konservativ und es wird erwartet, dass ich yarn.lock manuell bearbeite oder ein Flag verwende?

Ich vermute, ich muss die gleiche Sicherheitswarnung lösen wie @Machiaweliczny ;) Es wäre wirklich nützlich, die indirekte Abhängigkeit zu überschreiben, während wir darauf warten, dass Projekte ihre eigenen beheben. Selbst bei sehr reaktionsschnellen Projekten gibt es eine Verzögerung beim Warten auf Fixes und Releases.

Tatsächlich ist dies für Sicherheitsprobleme in indirekten Abhängigkeiten problematisch, und die Problemumgehung durch Bearbeiten von yarn.lock ist zwar effektiv, aber enttäuschend und schwer zu automatisieren. Wenn dies aus irgendeinem Grund nicht das Standardverhalten ist, wäre es toll, eine Option wie --include-indirect hinzuzufügen, die Yarn zwingt, den indirekten Abhängigkeiten zu folgen.

Ich denke nicht, dass es eine Option brauchen sollte, ich verstehe nicht, warum yarn upgrade [an indirect dependency] nicht einfach das Garn.lock auf die neueste Version der indirekten Abhängigkeit aktualisiert, die vom Abhängigkeitsbaum zugelassen wird, ohne dass dies erforderlich ist Zusatzoptionen. Ich denke, im Moment ist es nur ein No-Op?

Eine andere Problemumgehung, mit der ich zufrieden bin, ist jedoch das Hinzufügen resolutions zu meiner package.json. Wenn lodash eine indirekte Abhängigkeit ist und ich weiß, dass es >= 4.7.13 sein muss, um eine Sicherheitslücke zu vermeiden, kann ich meiner package.json Folgendes hinzufügen:

  "resolutions": {
    "lodash": ">= 4.17.13"
  }

Führen Sie dann einfach yarn install aus, es wird yarn.lock aktualisieren, um diese Anforderung zu erfüllen, oder sich beschweren, wenn dies nicht möglich ist, weil es mit einer indirekten Abhängigkeit in Konflikt steht.

Dies scheint in meinem Fall tatsächlich ziemlich gut funktioniert zu haben; Ich frage mich, ob es kein "Workaround" ist, sondern die beabsichtigte Lösung? Es dauerte eine Weile, bis ich es entdeckte. Und ich verstehe die Dinge nicht gut genug, um sicher zu sein, dass dies eine universelle/korrekte Lösung ist oder ob es in einigen Fällen Probleme damit geben könnte. Wenn es sich um die „richtige“ Lösung zum Aktualisieren indirekter Abhängigkeiten handelt, war es etwas schwierig, sie zu finden.

Warum installieren Sie nicht die transitive dep, die Sie aktualisieren möchten, aber übertragen Sie nicht die Änderungen der package.json, sondern nur die wool.lock?

Warum installieren Sie nicht die transitive dep, die Sie aktualisieren möchten, aber übertragen Sie nicht die Änderungen der package.json, sondern nur die wool.lock?

Ich glaube nicht, dass das (immer?) funktionieren wird, weil Garn gerne mehrere Versionen desselben Pakets installiert, selbst wenn eine einzelne Version alle relevanten Semver-Bereiche erfüllen würde. Dies würde also die gewünschte Version installieren, aber nicht die nicht gewünschte Version entfernen .

@djmitche Richtig. Sie müssten die Version innerhalb des erwarteten Bereichs installieren. Nicht ideal und etwas mühsam, aber vorerst eine verfügbare Notlösung.

@djmitche Dies ist in der Tat problematisch für Sicherheitsprobleme in indirekten Abhängigkeiten, und die Problemumgehung zum Bearbeiten von yarn.lock ist zwar effektiv, aber enttäuschend und schwer zu automatisieren.

Dies ist eine weitere Problemumgehung, die etwas besser automatisierbar ist:

yarn remove is-alphanumerical
yarn add is-alphanumerical

Unter Verwendung des Beispiels in der PR-Beschreibung würde dies die Top-Level-Dep entfernen und dann erneut hinzufügen, wodurch alle ihre neuesten Sub-Deps gemäß den durch is-alphanumerical angegebenen Bereichen (z. B. Caret-Bereiche) abgerufen werden. . Es erzeugt dann eine neue Sperrdatei.

Der Nebeneffekt ist, dass alle Sub-Deps aktualisiert werden, was nicht ideal ist. Bei einem Sicherheitsproblem in Unterabteilung A möchte ich nur Unterabteilung A aktualisieren.

Die Umgehung des Hinzufügens von Sub-Dep A als direktes Dep, nur um ein Sicherheitsproblem zu beheben, ist schlimmer, da es Verwirrung stiftet (das Paket wird nicht direkt verwendet) und einen Wartungsaufwand verursacht.

Garn entfernen ist alphanumerisch
Garn hinzufügen ist alphanumerisch

Dies scheint die einzig zuverlässige Möglichkeit zu sein, eine Abhängigkeit tatsächlich zu aktualisieren. Ich habe heute festgestellt, dass wir bei einer 1.0.0 -Version eines Pakets feststeckten, das vor einem Jahr auf $#$1 1.1.0 #$ aktualisiert wurde. Das Paket, das wir benutzten, verwendete ^1.0.0 und jedes Mal, wenn wir dieses Paket "aktualisiert" haben, hat es nie die neue 1.1.0 -Version seiner Abhängigkeit aufgenommen.
Es stellte sich heraus, dass es in unserem Produkt einen ziemlich schlimmen Fehler gab, der stillschweigend fehlschlug und der vor einem Jahr hätte behoben werden sollen, ohne dass ich einen Tag damit verschwenden musste, zu untersuchen, warum wir dieses Problem hatten.

Ich kann nicht glauben, dass das manuelle Bearbeiten von wool.lock, das Entfernen und erneute Hinzufügen des Pakets oder die Verwendung einer selektiven Auflösung die "Möglichkeiten" zum Aktualisieren einer indirekten Abhängigkeit sind.

IMO, yarn upgrade sollte die indirekten Abhängigkeiten auf die neueste akzeptierte Semver-Version aktualisieren, deshalb aktualisieren wir ein Paket. Ich meine, wenn es einen Bruch im Semver-Bereich gab, würde es die indirekten Abhängigkeiten aktualisieren, also sollte es das immer tun.

Würde es helfen, eine Art externes Skript zu schreiben, um dies zu tun? Ich nehme an, es würde einfach alle yarn.lock Einträge für das angegebene Paket entfernen und dann Garn erneut ausführen?

Dazu gibt es ein einfaches Skript: https://gist.github.com/pftg/fa8fe4ca2bb4638fbd19324376487f42

Kann einer der Betreuer bitte das Label von cat-feature in cat-bug ändern?

Kann einer der Betreuer bitte die Bezeichnung von cat-feature in cat-bug ändern?

warum? das ist kein Fehler. Es ist wie geplant. yarn upgrade war nie dazu gedacht, zum Aktualisieren einer transitiven Abhängigkeit verwendet zu werden. Das ursprünglich geöffnete "Problem" wird sogar als Feature Request gekennzeichnet.

Intern verwendet upgrade yarn outdated , um festzustellen, was veraltet ist und auf welche Versionen aktualisiert werden muss. outdated prüft nur direkte Abhängigkeiten.

Ich könnte mich irren, oder vielleicht hat es sich geändert, aber ich bin mir ziemlich sicher, dass npm upgrade mindestens vor 3 Jahren, als yarn upgrade zuletzt überarbeitet wurde, auch keine Möglichkeit bietet Upgrade einer transitiven Abh. (Auch das könnte sich im Laufe der Jahre geändert haben, ich bin nicht auf dem Laufenden über die Änderungen von npm).

Es steht jedem frei, eine PR einzureichen, um diese Funktionalität hinzuzufügen. Dies ist ein Open-Source-Projekt und es liegt an der Community im Allgemeinen, einen Beitrag zu leisten. Diese Feature-Anfrage ist seit Jahren offen, aber niemand hat sich bemüht, sie zu implementieren, und deshalb wurde sie nicht "behoben".

@nnmrts könnten Sie mein Skript überprüfen https://github.com/yarnpkg/yarn/issues/4986#issuecomment -562719589 wird es Ihnen vorerst helfen?

@rally25rs Sorry, ich war müde und mürrisch, betrachte meinen Kommentar als gelöst. 😬

@nnmrts könntest du mein Skript Nr. 4986 (Kommentar) überprüfen, wird es dir vorerst helfen?

Das Script hat bei mir leider nicht funktioniert, habe es gestern ausprobiert. Vielleicht habe ich etwas falsch gemacht, aber meine gesamte Garn.lock-Datei wurde vom Skript "geleert".

Ich bin mir nicht sicher, wie gut die Problemumgehung ist, aber ich habe dieses Skript ausgeführt, das ich geschrieben habe:

const fs = require('fs')
const lockfile = require('@yarnpkg/lockfile')
const package = require('./package.json')

const lock = lockfile.parse(fs.readFileSync('yarn.lock', 'utf-8')).object

const allDeps = new Set()

const parseDep = ([name, version]) => {
  allDeps.add(`${name}@${version}`)
}

Object.entries(package.dependencies).forEach(parseDep)
Object.entries(package.devDependencies).forEach(parseDep)

const newLock = Object.fromEntries(Object.entries(lock).filter(([dep]) => allDeps.has(dep)))
const newLockString = lockfile.stringify(newLock)

fs.writeFileSync('yarn.lock', newLockString)

Dann lief yarn install und es scheint die neuesten Versionen der indirekten Abhängigkeiten zu installieren.

Ich konnte tiefe/indirekte Abhängigkeiten erfolgreich auflösen. Ich frage mich, wann wir eine offizielle Unterstützung bekommen werden.

https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

Ich habe versucht, die Risiken der erneuten Generierung des Garns zu lösen und zu erklären, und habe vorgeschlagen, was getan werden sollte.

Lassen Sie mich wissen, ob das auch für Sie funktioniert. Oder Vorschläge zur Verbesserung des Upgrade-Prozesses.

@ayushya Hm, das scheint zu funktionieren, Genie.

Ich frage mich, ob Garn einen Patch akzeptieren würde, in dem yarn upgrade zu einer indirekten Abhängigkeit (oder einem anderen Befehl?) einfach ... das gemacht hat?

@jrochkind Ich hätte erwartet, dass ein yarn upgrade einer indirekten Abhängigkeit aktualisiert wird, auch wenn es nicht meine direkte Abhängigkeit ist. Ohne diese Funktion können Sie bei Aktualisierungen indirekter Abhängigkeiten Jahre im Rückstand sein.

In meinem Fall habe ich versucht, fsevents zu aktualisieren, damit es keine Fehler ausspuckte, als ich eine yarn install (https://github.com/fsevents/fsevents/issues/278 ). fsevents ist kein Paket, das ich direkt verwende – es ist etwas, das webpack-dev-server verwendet. Aber erschreckenderweise war ich an die Version gebunden, die existierte, als webpack-dev-server zum ersten Mal in dieser App installiert wurde.

Ich musste diesen Trick anwenden, um es zu aktualisieren, was wie ein totaler Hack aussah. https://github.com/yarnpkg/yarn/issues/4986#issuecomment -395036563

der workaround funktioniert bei mir nicht, leider wurden die alten deep-dependencies nach dem löschen wieder in die garn.lock datei eingefügt. Ich kann sie wieder im Ordner node_modules und in der Datei wool.lock sehen, nachdem ich die Garninstallation ausgeführt habe.

Vielleicht ist die Problemumgehung nicht mit Garn-Arbeitsbereichen kompatibel?

@FelipeLujan , wenn die Problemumgehung funktioniert, werden die tiefen Abhängigkeiten immer noch erneut zur Garn.lock-Datei hinzugefügt - das wird erwartet - aber mit neuen späteren Versionen. Aber nur mit neuen Versionen, wenn neue Versionen veröffentlicht werden und wenn sie vom Abhängigkeitsbaum zugelassen werden. Wenn eine zwischengeschaltete Abhängigkeit eine Einschränkung ausdrückt, die ein Upgrade nicht zulässt, können sie immer noch nicht aktualisiert werden. Sie werden nur auf die neueste Version aktualisiert, die von den Einschränkungen im Baum zugelassen wird.

Ich verwende jedoch keine Garn-Arbeitsbereiche, kann also nicht sagen, ob das relevant ist.

@FelipeLujan AFAIK- Garn-Arbeitsbereiche funktionieren auf ähnliche Weise.

Die Problemumgehung zum Löschen des Paketabschnitts aktualisiert das Paket nur auf die neueste MINOR/PATCH- Version.
Wenn Sie das Paket auf eine neuere MAJOR- Version aktualisieren möchten, müssen Sie die Paketabhängigkeitskette finden, die yarn why package-name-here ausführt, und das Paket an der Spitze seiner Kette aktualisieren.

ACHTUNG: Testen Sie Ihren Code, da ein Upgrade der Pakete auf eine neuere MAJOR-Version einige Breaking Changes mit sich bringen könnte.

https://github.com/djmitche/yarn-minify könnte dabei helfen.

Die Problemumgehung von @ayushya funktioniert hervorragend für mich, indem ich die thread.lock manuell bearbeite, um eine indirekte Abhängigkeit zu entfernen, und dann die Garninstallation ausführe, um sie in einer späteren Version erneut hinzuzufügen.

Für mich scheint dies jedoch eine Funktion zu sein, die in Garn integriert werden sollte, anstatt dass Sie die Datei "garn.lock" manuell bearbeiten müssen. Es scheint, als sollte es ziemlich einfach sein, ein Feature zu erstellen, das so aussieht, als hätten Sie es manuell bearbeitet, um die Abhängigkeit zu löschen und die Garninstallation auszuführen. Ich bin der Meinung, dass diese Funktion wirklich in Garn eingebaut werden sollte, und bin etwas verwirrt darüber, warum dies nicht der Fall ist.

Ich konnte tiefe/indirekte Abhängigkeiten erfolgreich auflösen. Ich frage mich, wann wir eine offizielle Unterstützung bekommen werden.

https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

Ich habe versucht, die Risiken der erneuten Generierung des Garns zu lösen und zu erklären, und habe vorgeschlagen, was getan werden sollte.

Lassen Sie mich wissen, ob das auch für Sie funktioniert. Oder Vorschläge zur Verbesserung des Upgrade-Prozesses.

Ich denke, das ist die gleiche Auflösung, die von @alex-thewsey-ibm gegeben wurde. Das Löschen dieser bestimmten Abhängigkeit von wool.lock hat mir geholfen.
Wie auch immer, danke für diesen Hack☺️

Die Verwendung resolutions in package.json hat bei mir funktioniert https://github.com/webpack/webpack-dev-server/issues/2739#issuecomment -695164486

Dies sollte zumindest eine Warnung zurückgeben:

yarn add [email protected]
yarn upgrade is-alphabetical

Das bekomme ich stattdessen:

success Saved lockfile.
success Saved 0 new dependencies.

Es gibt keine Änderungen in package.json und yarn.lock , obwohl eine neue is-alphabetical -Paketversion verfügbar ist.