Qual è la differenza tra npm-shrinkwrap.json e package-lock.json?

158

Con il rilascio di npm @ 5 , ora scriverà a package-lock.jsonse non npm-shrinkwrap.jsonesiste già un .

Ho installato npm @ 5 a livello globale tramite:

npm install npm@5 -g

E ora, se npm-shrinkwrap.jsonsi trova a durante:

npm install

verrà stampato un avviso:

npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I'll try to do my best with it!

Quindi il mio take-away è che dovrei sostituire la pellicola termoretraibile con la package-lock.json.

Ma perché esiste un nuovo formato per questo? Cosa può package-lock.jsonfare ciò che npm-shrinkwrap.jsonnon può?

npm npm-shrinkwrap package-lock.json

— k0pernikus
fonte

Risposte:

176

I file hanno esattamente lo stesso contenuto, ma ci sono alcune differenze nel modo in cui npm li gestisce, descritti nel sito dei documenti e anche in un file dei documenti nel repository npm che inizia indirizzando esplicitamente la differenza tra questi due file :

package-lock.jsonnon viene mai pubblicato su npm, mentre npm-shrinkwrapper impostazione predefinita è
package-lock.json i file che non si trovano nel pacchetto di livello superiore vengono ignorati, ma i file di restringimento appartenenti alle dipendenze vengono rispettati
npm-shrinkwrap.jsonè retrocompatibile con le versioni 2, 3 e 4 package-lock.jsondi npm , mentre è riconosciuto solo da npm 5+

È possibile convertire un esistente package-lock.jsonin uno npm-shrinkwrap.jsoneseguendo npm shrinkwrap.

Così:

Se non stai pubblicando il tuo pacchetto su npm, la scelta tra questi due file ha poche conseguenze. Potresti voler usare package-lock.jsonperché è l'impostazione predefinita e il suo nome è più chiaro per i principianti di npm; in alternativa, è possibile utilizzare npm-shrinkwrap.jsonper la retrocompatibilità con npm 2-4 se è difficile assicurarsi che tutti i membri del team di sviluppo siano su npm 5+. (Si noti che npm 5 è stato rilasciato il 25 maggio 2017; la compatibilità con le versioni precedenti diventerà sempre meno importante quanto più si ottiene da quella data, poiché la maggior parte delle persone alla fine aggiornerà.)
Se si sta pubblicando il pacchetto di NPM, avete una scelta tra:
1. utilizzando a package-lock.jsonper registrare esattamente quali versioni delle dipendenze sono state installate, ma consentendo alle persone che installano il pacchetto di utilizzare qualsiasi versione delle dipendenze compatibile con gli intervalli di versioni dettati dal proprio package.json, oppure
2. utilizzando un npm-shrinkwrap.jsonper garantire che tutti coloro che installano il pacchetto ottengano esattamente la stessa versione di tutte le dipendenze
La visione ufficiale descritta (molto tersamente) nei documenti è che l'opzione 1 dovrebbe essere usata per le biblioteche (presumibilmente per ridurre la quantità di duplicazione del pacchetto causata quando molte dipendenze di un pacchetto dipendono tutte da versioni leggermente diverse della stessa dipendenza secondaria) , ma quell'opzione 2 potrebbe essere ragionevole per gli eseguibili che verranno installati a livello globale.

— Mark Amery
fonte

+1 - puoi chiarire il tuo secondo punto elenco? Qual è la distinzione tra quel comportamento e avere un npm-shrinkwrap?

— Rhys,

@Rhys il secondo proiettile non importerà in pratica a meno che tu non stia facendo qualcosa di strano. In sostanza, si dice solo che se una libreria in qualche modo ha fatto pubblicare un package-lock.json(che non è possibile), quindi se si dovesse installare quella biblioteca come una dipendenza di qualche altro pacchetto, della biblioteca package-lock.jsonsarebbero stati ignorati da NPM. Tuttavia, se una libreria pubblica un npm-shrinkwrap.jsone si installa la libreria come dipendenza, verranno installate anche come dipendenze secondarie le versioni esatte di tutte le dipendenze specificate nella libreria npm-shrinkwrap.json.

— Mark Amery,

Potete aggiungere che npm ciesiste per assicurare l'installazione di package-lock.jsoncome sola lettura. ( npm installmuta la package-lock.jsonconfusione che causa e i potenziali bug e non ne approfitta di package-lock.jsonper sé.)

— k0pernikus

@ k0pernikus Non credo che ci sia alcuna differenza tra il modo in cui npm cihandle npm-shrinkwrap.jsone package-lock.json- qual è la sua rilevanza per questa domanda sulla differenza tra i due file? Inoltre, dopo aver letto: penso che " npm install... non sfrutti il package-lock.json" sia falso da npm 5.4 - Credo che npm installora rispetti il tuo a package-lock meno che non sia del tutto incompatibile con il tuo package.json, nel qual caso quest'ultimo avrà la precedenza. (Ma sono stato un po 'fuori dal mondo JavaScript - mi sto perdendo qualcosa?)

— Mark Amery,

Spiegazione dello sviluppatore NPM :

L'idea è sicuramente che package-lock.json sia l'ultimo e il più grande nella tecnologia degli strizzacervelli, e npm-shrinkwrap.json sia riservato a quelle preziose poche persone là fuori che si preoccupano moltissimo che le loro librerie abbiano un node_modules esatto - e per le persone che desiderano CI utilizzando npm @> = 2 per installare un albero specifico senza dover eseguire il bump della sua versione npm.

Il nuovo lockfile ("package-lock.json") condivide sostanzialmente tutto lo stesso codice, lo stesso identico formato di npm-shrinkwrap (puoi rinominarli tra loro!). È anche qualcosa che la comunità sembra capire: "ha un file di blocco" sembra fare clic molto più velocemente con le persone. Infine, avere un nuovo file significava che avremmo potuto avere una retrocompatibilità relativamente a basso rischio con shrinkwrap senza dover fare cose strane come consentire la pubblicazione menzionata nel post principale.

— SeriousM
fonte

Non sono ancora chiaro sulla differenza. Se npm-shrinkwrapè per node_modules esatti .... Presumo che il package-lock.jsonblocco sia inferiore all'esatto? E se è così, cosa non sta bloccando che npm-shrinkwrapsta bloccando?

— Dman,

hai sbagliato @dman. package-lock è la nuova versione di npm-shrinkwrap. package-lock è opt-out (quindi devi rimuovere la funzione perché è abilitata per impostazione predefinita), npm-shrinkwrap è opt-in (quindi devi abilitarla perché non è inclusa la mia impostazione predefinita). il motivo per cui hanno introdotto il blocco dei pacchetti è che 1. l'utente ora ha un modo più economico di gestire le dipendenze perché è abilitato di default e 2. il nome implica ciò che è opposto a "restringimento". npm-shrinkwrap aveva alcune impostazioni speciali di comportamento delle dipendenze che ora non ha il pacchetto-lock. npm-shrinkwrap è ora obsoleto.

— SeriousM,

questo non è corretto. Dicendo che package-lock è la nuova versione di npm-shrinkwrap, stai dicendo che è un rimpiazzo. npm-shrinkwrap non è obsoleto e presenta differenze con package-lock.json. Inoltre, package-lock.json ha un bug mentre npm-shrinkwrap non lo fa ... sottolineando di più quindi non sono lo stesso codice.

— Dman,

Anche package-lock.json è invadente. Quindi può facilmente causare conflitti scm se si chiama "npm i" mentre il restringimento dovrebbe essere esplicitamente generato e non causerà conflitti sui server ci. Sì, posso sbagliarmi qui.

— norekhov,

@dman "package-lock.json ha un bug mentre npm-shrinkwrap no" - no non lo è. Non ci sono indicazioni nel problema a cui ti sei collegato; non menziona nemmeno npm-shrinkwrap. Come noto nella mia risposta, la conversione di a package-lock.jsonin npm-shrinkwrap.jsonè letteralmente fatta semplicemente rinominando il file; essi sono "lo stesso codice".

— Mark Amery,

Penso che l'idea fosse quella di: salvataggi e termoretraibili per impostazione predefinita, ma evitare qualsiasi potenziale problema con un restringimento che si verifica dove non era desiderato. Quindi, gli hanno appena dato un nuovo nome per evitare conflitti. Qualcuno di npm l'ha spiegato più a fondo qui:

https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/

La citazione pertinente:

npm pubblica la maggior parte dei file nella directory di origine per impostazione predefinita e le persone pubblicano film termoretraibili da anni. Non volevamo interrompere la compatibilità. Con --save e shrinkwrap di default, c'era un grosso rischio che si accendesse accidentalmente e si propagasse attraverso il registro, e sostanzialmente rendesse la nostra capacità di aggiornare deps e dedupe ... null.

Quindi abbiamo scelto un nuovo nome. E abbiamo scelto un nuovo nome all'improvviso. Il nuovo file di blocco condivide sostanzialmente lo stesso codice, lo stesso identico formato

— Cody Brumfield
fonte