Scrivi un intervallo di package.json (^1.2.3, ~1.2.3, 1.x, >=1.0.0 <2.0.0, ||) e guarda esattamente quali versioni accetta. Carica l'elenco reale delle versioni di qualsiasi pacchetto npm, oppure incolla il tuo.
Prova:
Equivale a
>=1.2.3 <2.0.0-0
almeno 1.2.3, sotto 2.0.0, senza nessuna delle sue pre-release
Versione più alta accettata: 1.9.9 · 4 versioni accettate su 9
^ (caret) consente ogni modifica che non tocca il primo numero diverso da zero a partire da sinistra: ^1.2.3 vale >=1.2.3 <2.0.0, ma ^0.2.3 vale >=0.2.3 <0.3.0 e ^0.0.3 accetta solo 0.0.3.
~ (tilde) consente le patch quando è indicata una minor: ~1.2.3 vale >=1.2.3 <1.3.0. ~1 equivale a 1.x.
x, X e * sono jolly: 1.x vale >=1.0.0 <2.0.0. Una parte mancante conta come jolly, quindi 1.2 significa 1.2.x.
Uno spazio significa E, || significa O. Un intervallo con trattino 1.2.3 - 2.3.4 include entrambi gli estremi; un estremo superiore parziale come - 2.3 significa sotto 2.4.0.
Le pre-release (1.3.0-beta.1) sono escluse, a meno che l'intervallo stesso non nomini una pre-release dello stesso major.minor.patch. È la regola che sorprende di più.
Logica scritta secondo le regole di node-semver 7 usate da npm (modalità rigorosa, includePrerelease disattivato) e verificata con il pacchetto semver prima della pubblicazione. Gli elenchi di versioni arrivano direttamente da registry.npmjs.org nel tuo browser; nulla viene inviato a VersionDude.
Un intervallo fluttua. La tua macchina di build no.
Un caret lascia che la prossima installazione scelga una versione più recente; solo il lockfile e la macchina che esegue npm ci rendono riproducibili le build. Infomaniak, provider svizzero attento alla privacy, offre VPS e server cloud per eseguire le tue macchine di build e integrazione continua.