Yarn: Durch das Hinzufügen einer neuen Abhängigkeit werden vorhandene Versionsbeschränkungen bei der Auflösung nicht berücksichtigt
Möchten Sie eine Funktion anfordern oder einen Fehler melden?
Fehler.
Wie ist das aktuelle Verhalten?
Yarn berücksichtigt bereits hinzugefügte Versionssperren nicht, wenn die Abhängigkeiten neu hinzugefügter Abhängigkeiten aufgelöst werden.
Wenn das aktuelle Verhalten ein Fehler ist, geben Sie bitte die Schritte zur Reproduktion an.
- Initiiere ein leeres Modul
- Hinzufügen reagieren 15.6.1
yarn add [email protected] - Fügen Sie [email protected]
yarn add [email protected] - Der Fehler wird reproduziert und zwei unterschiedliche Versionen werden installiert:
$ yarn list react
yarn list v1.1.0
├─ [email protected]
└─ [email protected]
└─ [email protected]
✨ Done in 0.24s.
Was ist das erwartete Verhalten?
Es wird erwartet, dass nur [email protected] installiert wird, da dies alle Versionsbeschränkungen erfüllen kann. Dies passiert, wenn ich yarn.lock lösche, nachdem beide Abhängigkeiten in package.json und yarn install
$ rm -rf node_modules/ yarn.lock && yarn install && yarn list react
yarn list v1.1.0
└─ [email protected]
✨ Done in 0.17s.
Bitte geben Sie Ihre node.js, Garn und Betriebssystemversion an.
$ node --version
v6.9.4
$ yarn --version
1.2.0
$ system_profiler SPSoftwareDataType|grep "System Version"
System Version: macOS 10.12.6 (16G29)
BEARBEITEN: Die ursprüngliche Reproduktion wurde mit Garn v.1.1.0 durchgeführt, aber ich habe auf 1.2.0 aktualisiert und dies wird immer noch reproduziert.
hniirane
Alle 4 Kommentare
Ich beschäftige mich damit ...
Beachten Sie, dass die an PackageResolver.getHighestRangeVersionMatch(name, range, manifest) Parameter möglicherweise falsch sind. Das übergebene range scheint die tatsächlich aufgelöste Einzelversion ( 15.6.2 ) anstelle des angeforderten Bereichs ( ^15.5.4 ) zu sein.
Dies führt wiederum zu der Zeile, in der überprüft wird, ob aktuell installierte Versionen mit dem Semver-Bereich übereinstimmen: semver.maxSatisfying(["15.6.1"], '15.6.2'); // null Wenn der richtige Bereich übergeben worden wäre, hätte er semver.maxSatisfying(["15.6.1"], '^15.5.4'); // 15.6.1 was sollte Lösen Sie dieses Problem.
Ich werde den Code weiter zurückverfolgen ...
rally25rs
am 11. Okt. 2017
OK, es sieht so aus, als ob dies von # 3729 speziell in der Zeile in package-request.js :
const solvedRange = semver.validRange(range) ? info.version : range;
Wenn also der Bereich ( ^15.5.4 ) gültig ist, verwenden wir stattdessen info.version ( 15.6.2 ).
Das wird weitergegeben, um zu sehen, ob installierte Versionen mit 15.6.2 übereinstimmen:
const maxValidRange = semver.maxSatisfying(['15.6.1'], '15.6.2'); // null
@arcanis es sieht so aus, als ob die verknüpfte PR Ihnen gehört. Ich zögere, irgendetwas zu ändern und riskiere, alles, was durch diese PR behoben wurde, wieder zu öffnen. Könnten Sie helfen?
rally25rs
am 11. Okt. 2017
Werde das heute untersuchen 👍
arcanis
am 16. Okt. 2017
Sooo, lass uns versuchen, das zu beheben! Ich mag sie nicht , dass Pakete auf Hebe setzen (meine Worte - auch wenn wir dieses Problem zu beheben, werden sie brechen wieder in der Zukunft), aber wir machen es weniger effizient , als es sein könnte , ist auch nicht großartig. Reposting, was ich auf # 5561 gesetzt habe:
Ich verstehe die obige Logik nicht wirklich. Wenn range ein gültiger Semver ist, verwenden Sie ihn dann nicht?
Sie haben Recht, das macht nicht viel Sinn: / Ich denke, ich wollte "wenn dies keine Version ist, sondern ein Bereich, dann verwenden Sie die, die wir bereits haben, wenn möglich" (seit dem Ziel) der PR war keine Optimierung beim Lesen aus der Sperrdatei). Als solches sollte die Bedingung wahrscheinlich sein:
const solvedRange = semver.valid(range) && !semver.validRange(range) ? range : info.version;
Verwandte Themen
baptistelebail
·
3Kommentare
jviotti
·
3Kommentare
mnpenner
·
3Kommentare
victornoel
·
3Kommentare
Ambroos
·
3Kommentare
Hilfreichster Kommentar
Werde das heute untersuchen 👍