Geben Sie einen Bereich aus package.json ein (^1.2.3, ~1.2.3, 1.x, >=1.0.0 <2.0.0, ||) und sehen Sie genau, welche Versionen er akzeptiert. Laden Sie die echte Versionsliste eines beliebigen npm-Pakets oder fügen Sie Ihre eigene ein.
Beispiele:
Entspricht
>=1.2.3 <2.0.0-0
mindestens 1.2.3, unter 2.0.0, ohne dessen Vorabversionen
Höchste akzeptierte Version: 1.9.9 · 4 von 9 Versionen akzeptiert
^ (Caret) erlaubt jede Änderung, die die erste von null verschiedene Zahl von links nicht verändert: ^1.2.3 bedeutet >=1.2.3 <2.0.0, aber ^0.2.3 bedeutet >=0.2.3 <0.3.0 und ^0.0.3 nur 0.0.3.
~ (Tilde) erlaubt Patch-Änderungen, wenn eine Minor-Version angegeben ist: ~1.2.3 bedeutet >=1.2.3 <1.3.0. ~1 ist dasselbe wie 1.x.
x, X und * sind Platzhalter: 1.x ist >=1.0.0 <2.0.0. Ein fehlender Teil zählt als Platzhalter, 1.2 bedeutet also 1.2.x.
Ein Leerzeichen bedeutet UND, || bedeutet ODER. Ein Bindestrich-Bereich 1.2.3 - 2.3.4 schließt beide Enden ein; ein unvollständiges oberes Ende wie - 2.3 bedeutet unter 2.4.0.
Vorabversionen (1.3.0-beta.1) sind ausgeschlossen, es sei denn, der Bereich nennt selbst eine Vorabversion desselben major.minor.patch. Diese Regel überrascht am häufigsten.
Logik nach den node-semver-7-Regeln geschrieben, die npm verwendet (strikter Modus, includePrerelease aus), und vor der Veröffentlichung mit dem semver-Paket abgeglichen. Versionslisten kommen direkt von registry.npmjs.org in Ihrem Browser; nichts wird an VersionDude gesendet.
Ein Bereich schwankt. Ihre Build-Maschine sollte es nicht.
Ein Caret lässt die nächste Installation eine neuere Version wählen; nur die Lockfile und die Maschine, die npm ci ausführt, machen Builds reproduzierbar. Infomaniak, ein schweizerischer, datenschutzfreundlicher Anbieter, bietet VPS und Cloud-Server, um eigene Build- und CI-Maschinen zu betreiben.