Yarn: Yarn verwendet die passende @next/unstable-Version anstelle der neuesten passenden stabilen Version wie NPM

Erstellt am 4. Nov. 2016  ·  3Kommentare  ·  Quelle: yarnpkg/yarn

Möchten Sie eine Funktion anfordern oder einen Fehler melden?
Bug 🐜 😱 Yarn wählt andere Versionen als NPM mit demselben Versionsbezeichner aus.

Wie ist das aktuelle Verhalten?

  • Paket aes-decrypter ist auf npm: { latest: '1.0.3', beta: '1.0.0-0', next: '1.1.0' }
  • Paket video.js ist auf npm: { latest: '5.11.9', next: '5.12.6', alpha: '5.9.0-2' }
  • Paket videojs-contrib-hls abhängig von aes-decrypter@^1.0.3' und video.js@^5.10.1
  • Mein Paket hängt von videojs-contrib-hls@^3.6.7 in package.json :
{
  "name": "yarn-next-bug-test",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "videojs-contrib-hls": "^3.6.7"
  }
}
  • Kein Garn.lock
  • yarn

Die installierten und zu Garn.lock hinzugefügten Pakete sind:

Was ist das erwartete Verhalten?
Was NPM mit demselben package.json macht:

Bitte geben Sie Ihre node.js-, Garn- und Betriebssystemversion an.
node.js v7.0.0
beide Garne v0.16.0 und v0.19.0-0 (Master at f0d875a67a06d8b2405be177d0c43820442d802b) haben den Fehler
Sowohl npm v3.10.9 als auch v4.0.2 tun das Erwartete
macOS Sierra 10.12.2 Beta (16C32f)

Hilfreichster Kommentar

Ist bei der Installation von nightmare über Garn aufgetreten - der Albtraum hängt von electron@^1.4.4 was zu 1.6.0 das unter dem beta Dist-Tag auf npm liegt. Die höchste neueste Version ist 1.4.15 . Ich habe unwissentlich Code gegen eine Beta-Version von Electron geschrieben, muss ihn jetzt downgraden, um in der Produktion zu laufen.

Meine Problemumgehung bestand darin, die Version von electron , die ich in package.json separat zu deklarieren.

Alle 3 Kommentare

Ich bin auf das gleiche gestoßen. Dies scheint in NpmResolve#findVersionInRegistryResponse schief zu gehen, wo range nie ein Schlüssel von dist-tags für transitive Abhängigkeiten ist, sondern einfach ein Semver-Bereich, und config.resolveConstraint dann einfach zurückgibt der höchste.
(Ein gutes Beispiel für einen Katastrophenfall ist der schrecklich kaputte Canary-Release-Mechanismus von lerna, der mehrere Pre-Release-Versionen produziert, die mit dem kurzen Git-Commit-Hash enden. Ich denke, echte Programmierer zählen immer abwärts und beginnen mit 'f'.)

Ich habe auch dieses Problem mit dem Typscript-Paket.

Laufen npm view typescript 'dist-tags'
Ergibt diese Ausgabe:

{ latest: '2.0.10',
  next: '2.2.0-dev.20161129',
  beta: '2.0.0',
  rc: '2.1.1',
  insiders: '2.0.6-insiders.20161017' }

Durch Ausführen von npm install die Version 2.0.10 installiert
Nachdem ich Garn ausgeführt habe, habe ich diesen Eintrag in Garn.lock

typescript@^2.0.9:
  version "2.1.1"
  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.1.1.tgz#41c2b64472f529331b2055c0424862b44ce58d42"

Sie könnten argumentieren, wer falsch macht. Ich denke, dass das Garn dem Semver folgt und nach der neuesten gültigen Version sucht, die in meinen Fällen 2.1.1 ist.

Npm scheint die Informationen von dist-tags zu verwenden und typescript hätte die Version "2.1.1-rc" verwenden sollen.

Ist bei der Installation von nightmare über Garn aufgetreten - der Albtraum hängt von electron@^1.4.4 was zu 1.6.0 das unter dem beta Dist-Tag auf npm liegt. Die höchste neueste Version ist 1.4.15 . Ich habe unwissentlich Code gegen eine Beta-Version von Electron geschrieben, muss ihn jetzt downgraden, um in der Produktion zu laufen.

Meine Problemumgehung bestand darin, die Version von electron , die ich in package.json separat zu deklarieren.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen