Devo eseguire il commit del file package-lock.json creato da npm 5?


1396

npm 5 è stato rilasciato oggi e una delle nuove funzionalità include installazioni deterministiche con la creazione di un package-lock.jsonfile.

Questo file dovrebbe essere mantenuto nel controllo del codice sorgente?

Suppongo che sia simile a yarn.locke composer.lock, entrambi i quali dovrebbero essere mantenuti nel controllo del codice sorgente.


20
Risposta breve: si. Un commento: quando cambia package-lock.json puoi effettuare un commit di quella modifica, separata dalle altre modifiche alla fonte. Questo git logsemplifica la gestione.
Purplejacket,

14
Un file non può aiutare a produrre un'installazione deterministica se non esiste.
Alan H.

4
Dipende dal progetto. github.com/npm/npm/issues/20603
Gajus

3
Se ti fidi davvero di npm, lo scopo è quello di segnalare in modo più esplicito ciò che il progetto sta usando. Se vuoi davvero la prevedibilità ignora questo file e installa invece i tuoi node_modules (vedi .npmrc e la relativa configurazione nelle risposte + commento) e usalo per tenere traccia di ciò che sta realmente cambiando piuttosto che di ciò che il tuo gestore di pacchetti afferma che sta facendo. In definitiva: qual è più importante? Il tuo gestore pacchetti o il codice che stai utilizzando.
Jimmont,

Risposte:


1617

Sì, package-lock.jsondeve essere verificato nel controllo del codice sorgente. Se stai usando npm 5, potresti vederlo sulla riga di comando: created a lockfile as package-lock.json. You should commit this file.Secondo npm help package-lock.json:

package-lock.jsonviene generato automaticamente per qualsiasi operazione in cui npm modifica l' node_modulesalbero o package.json. Descrive l'albero esatto che è stato generato, in modo che le installazioni successive siano in grado di generare alberi identici, indipendentemente dagli aggiornamenti di dipendenza intermedi.

Questo file è destinato al commit nei repository di origine e serve a vari scopi:

  • Descrivere una singola rappresentazione di un albero delle dipendenze in modo tale che i compagni di squadra, le distribuzioni e l'integrazione continua possano installare esattamente le stesse dipendenze.

  • Fornire agli utenti la possibilità di "viaggiare nel tempo" negli stati precedenti node_modulessenza dover impegnare la directory stessa.

  • Per facilitare una maggiore visibilità delle modifiche dell'albero mediante differenze di controllo della sorgente leggibili.

  • E ottimizza il processo di installazione consentendo a npm di saltare ripetute risoluzioni dei metadati per i pacchetti precedentemente installati.

Un dettaglio chiave package-lock.jsonè che non può essere pubblicato e verrà ignorato se trovato in un posto diverso dal pacchetto di livello superiore. Condivide un formato con npm-shrinkwrap.json (5), che è essenzialmente lo stesso file, ma consente la pubblicazione. Questo non è raccomandato a meno che non si distribuisca uno strumento CLI o non si usi altrimenti il ​​processo di pubblicazione per produrre pacchetti di produzione.

Se entrambi package-lock.jsone npm-shrinkwrap.jsonsono presenti nella radice di un pacchetto, package-lock.jsonverranno completamente ignorati.


78
In quale tipo di progetti è effettivamente utile eseguire il commit del file? Il punto centrale di semver e package.json è che non è necessario notare le dipendenze compatibili aggiornate.
curiousdannii,

45
La parola chiave è "non dovrebbe essere necessario", ma in pratica le persone non seguono perfettamente il semver. Ecco perché è possibile utilizzare package-lock.json e package.json insieme per semplificare l'aggiornamento dei pacchetti ma assicurandosi comunque che tutti gli sviluppatori e tutte le applicazioni distribuite utilizzino lo stesso albero delle dipendenze.
Panu Horsmalahti,

34
@trusktr: Sindre Sorhus consiglia di utilizzare "Lockfile per le app, ma non per i pacchetti".
vine77,

23
Un'altra cosa è che package-lock.json viene ignorato per la pubblicazione su NPM, quindi se uno sviluppatore lo utilizza per uno sviluppatore di librerie, sta riducendo al minimo la possibilità di ricevere una regressione da una versione di dipendenza aggiornata e quindi passerà quella bug sugli utenti finali. Per questo motivo, non utilizzare un file di blocco per lo sviluppo della libreria aumenta la possibilità di inviare meno bug.
trusktr,

129
Personalmente ora ho dovuto ricorrere ad aggiungere package-lock.jsonal mio .gitignore... mi stava causando molti più problemi che risolverli. È sempre in conflitto quando ci uniamo o si ribatte, e quando una fusione si traduce in un package-lock.jsondanneggiamento sul server CI, è solo una seccatura dover rimanere a ripararlo.
Stefan Z Camilleri,

111

Sì, è previsto per il check-in. Voglio suggerire che ottiene il proprio commit unico. Scopriamo che aggiunge molto rumore ai nostri diff.


19
è lecito discutere se debba essere verificato nel repository del codice sorgente, ma la pubblicazione di questo file su npm non è realmente oggetto di dibattito: è necessario includere il pacchetto-lock.json o il file shrinkwrap nel registro di npm. in caso contrario, il pacchetto pubblicato sarà soggetto a modifiche non vincolate delle dipendenze delle dipendenze di prima generazione. non noterai che questo è un problema fino a quando una di quelle dipendenze di seconda generazione + non pubblica un cambiamento di rottura e il tuo pacchetto pubblicato diventa misteriosamente rotto. questo file package-lock.json è stato creato per risolvere il problema.
guerrillapresident,

9
@BetoAveiga per rumore Voglio dire che i commit con package-lock.json possono avere così tante linee di versioni di pacchetti di nodi che qualsiasi altro lavoro in quel commit viene nascosto.
xer0x,

7
Di solito mantengo le installazioni dei pacchetti separate dalle altre attività. Non ho mai bisogno di diff un commit come "Installed chai and mocha", perché so già cosa è cambiato.
Keith

3
Qualche consiglio riguardo al package-lock.jsonfile quando si lavora su un sistema SCM con tronchi e diramazioni? Sto apportando alcune modifiche su un ramo che deve essere unito al trunk ... ora devo (in qualche modo) risolvere i conflitti tra i due package-lock.jsonfile? Questo è doloroso.
kmiklas,

3
@guerillapresident A quanto ho capito, hai parzialmente ragione. La pubblicazione di questo file su npm non è in discussione. Non puoi pubblicarlo.
Tim Gautier,

66

Si, dovresti:

  1. commettere il package-lock.json.
  2. utilizzare npm ciinvece dinpm install quando si creano applicazioni sia sull'IC che sulla macchina di sviluppo locale

Il npm ciflusso di lavoro richiede l'esistenza di a package-lock.json.


Un grande svantaggio del npm installcomando è il suo comportamento inaspettato che può mutare package-lock.json, mentre npm ciusa solo le versioni specificate nel file di blocco e produce un errore

  • se package-lock.jsone non package.jsonsono sincronizzati
  • se package-lock.jsonmanca un.

Quindi, correndo npm installlocalmente, esp. in team più grandi con più sviluppatori, può portare a molti conflitti all'interno package-lock.jsone gli sviluppatori decidono di eliminare completamente package-lock.jsoninvece.

Tuttavia, esiste un valido caso d'uso per poter fidarsi che le dipendenze del progetto si risolvono ripetutamente in modo affidabile su macchine diverse.

Da un package-lock.jsonsi ottiene esattamente questo: uno stato noto al lavoro.

In passato, avevo progetti senza file package-lock.json/ npm-shrinkwrap.json/ la yarn.lockcui generazione avrebbe fallito un giorno perché una dipendenza casuale ha avuto un aggiornamento di rottura.

Questi problemi sono difficili da risolvere poiché a volte devi indovinare quale fosse l'ultima versione funzionante.

Se si desidera aggiungere una nuova dipendenza, si esegue comunque npm install {dependency}. Se si desidera aggiornare, utilizzare npm update {dependency}o npm install ${dependendency}@{version}e confermare la modifica package-lock.json.

Se l'aggiornamento non riesce, è possibile ripristinare l'ultimo funzionamento noto package-lock.json.


Per citare npm doc :

Si consiglia vivamente di affidare il blocco del pacchetto generato al controllo del codice sorgente: ciò consentirà a chiunque nel tuo team, alle tue distribuzioni, alla tua integrazione continua / continua e a chiunque esegua npm di installare nel tuo pacchetto sorgente di ottenere esattamente lo stesso albero delle dipendenze su cui stavi sviluppando. Inoltre, le differenze tra queste modifiche sono leggibili dall'uomo e ti informeranno di eventuali modifiche che npm ha apportato ai tuoi node_modules, in modo da poter notare se eventuali dipendenze transitive sono state aggiornate, issate, ecc.

E per quanto riguarda la differenza tra npm civsnpm install :

  • Il progetto deve avere un pacchetto-lock.json o npm-shrinkwrap.json esistente.
  • Se le dipendenze nel blocco del pacchetto non corrispondono a quelle in package.json, npm ci uscirà con un errore, invece di aggiornare il blocco del pacchetto.
  • npm ci può installare interi progetti alla volta: non è possibile aggiungere singole dipendenze con questo comando.
  • Se a node_modulesè già presente, verrà rimosso automaticamente prima di npm ciiniziare l'installazione.
  • Non scriverà mai su package.jsonnessuno dei blocchi dei pacchetti: le installazioni sono essenzialmente bloccate.

Nota: ho pubblicato una risposta simile qui


10
Questa risposta merita più credito, soprattutto utilizzando npm ci. L'uso di questo mitiga la maggior parte dei problemi che le persone hanno riscontrato con il blocco dei pacchetti.
James B

Ho trovato che usare la versione fissa in package.json (nessun cursore o tilde) è un'opzione molto più pulita. Questo mi salva dal whose build would fail one day because a random dependency got a breaking updatetipo di problema. Anche se lascia la possibilità della dipendenza del bambino, causando lo stesso problema.
Ashwani Agarwal,

58

Sì, la procedura migliore è effettuare il check-in (SÌ, CHECK-IN)

Sono d'accordo che causerà molto rumore o conflitti quando vedo il diff. Ma i vantaggi sono:

  1. garantire la stessa versione esatta di ogni pacchetto . Questa parte è la più importante quando si costruisce in ambienti diversi in momenti diversi. Puoi usarlo ^1.2.3nel tuo package.json, ma come puoi assicurarti che ogni volta npm installprenda la stessa versione nella tua macchina di sviluppo e nel server di build, in particolare quei pacchetti di dipendenza indiretta? Bene, package-lock.jsonlo garantirà. (Con l'aiuto del npm ciquale installa i pacchetti in base al file di blocco)
  2. migliora il processo di installazione.
  3. aiuta con la nuova funzione di controllo npm audit fix(penso che la funzione di controllo sia dalla versione 6 di npm).

3
Per quanto ne so, non usare mai semver (che gli sviluppatori npm non capiscono comunque) dovrebbe produrre lo stesso comportamento di avere un file di blocco almeno nel 99% dei casi. La mia esperienza personale è che i fuckup di semver si verificano principalmente con pacchetti primari (dipendenze dirette, datepickers jquery scadenti, ecc.). La mia esperienza personale con npm è stata che i file di blocco erano rumori per sempre. Spero che questa saggezza sia rimasta invariata rispetto alle versioni recenti.
Svend,

13
+1 per la menzione npm ci. Le persone spesso menzionano che a package-lock.jsonconsente un'installazione deterministica di pacchetti ma quasi mai menziona il comando che facilita questo comportamento! Probabilmente molte persone presumono erroneamente che l' npm installinstallazione sia esattamente nel file di blocco ...
ahaurat,

npm ci non è in npm 5.
dpurrington

Grazie! Ha senso eseguire il commit di package-lock.json solo se lo stai utilizzando npm ci. Il tuo team / lead developer può decidere quando eseguire l'aggiornamento. Se tutti lo commettono arbitrariamente, non ha senso, e sta solo creando rumore nel tuo repository. La documentazione NPM dovrebbe renderlo più chiaro. Penso che la maggior parte degli sviluppatori sia solo confusa da questa funzione.
Adampasz,

@adampasz in realtà ogni sviluppatore può eseguire il commit del file di blocco e, una volta superato il test e unito, il secondo ramo semplicemente rinnova il file di blocco se in qualche modo i pacchetti vengono cambiati (non cambiamo il pacchetto.json spesso, affrontiamo meno questo problema (
Xin,

38

Non impegno questo file nei miei progetti. Qual e il punto ?

  1. È generato
  2. È la causa di un errore di integrità del codice SHA1 in gitlab con build gitlab-ci.yml

Anche se è vero che non uso mai ^ nel mio pacchetto.json per le librerie perché ho avuto brutte esperienze con esso.


11
Vorrei che questo potesse essere spiegato più approfonditamente da npm docs - Sarebbe utile avere uno schema di ciò che specificamente perdi non impegnandoti package-lock.json. Alcuni repository potrebbero non richiedere i benefici che ne derivano e potrebbero preferire non avere contenuti generati automaticamente nella fonte.
PotatoFarmer

2
Vedo come può essere utile per il debug (una differenza tra due blocchi per esempio) per aiutare a risolvere i problemi. Immagino che possa anche essere usato per prevenire questo tipo di cose, ma può anche essere un dolore averlo in un repository condiviso in cui potrebbe verificarsi unire conflitti a causa di esso. Per i principianti voglio mantenere le cose semplici, userò solo package.json da solo fino a quando vedrò che c'è davvero bisogno di package-lock.json.
Radtek,

6
Non puoi usare ^ nel tuo package.json, ma puoi essere sicuro che le tue dipendenze non lo usano?
Neiker,

35

Alle persone che si lamentano del rumore quando fanno git diff:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

Quello che ho fatto è stato usare un alias:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Per ignorare package-lock.json in diff per l'intero repository (tutti quelli che lo usano), è possibile aggiungere questo a .gitattributes:

package-lock.json binary
yarn.lock binary

Ciò comporterà differenze che mostrano "I file binari a / package-lock.json e b / package-lock.json differiscono ogni volta che viene modificato il file di blocco del pacchetto. Inoltre, alcuni servizi Git (in particolare GitLab, ma non GitHub) escluderanno questi file (non più 10k linee modificate!) dai diff quando si visualizzano online quando si esegue questa operazione.


1
Ho gd() { git diff --color-words $1 $2 -- :!/yarn.lock :!/package-lock.json; }nel mio .bashrc invece di un alias.
apostl3pol

16

Sì, puoi eseguire il commit di questo file. Dai documenti ufficiali di npm :

package-lock.jsonviene generato automaticamente per qualsiasi operazione in cui si npmmodifica l' node_modulesalbero o package.json. Descrive l'albero esatto che è stato generato, in modo che le installazioni successive siano in grado di generare alberi identici, indipendentemente dagli aggiornamenti di dipendenza intermedi.

Questo file è destinato al commit nei repository di origine [.]


13
Un'installazione non aggiorna sempre node_modules e quindi aggiorna package-lock.json?
Tim Gautier,

2
No, puoi eseguire npm cil'installazione dal pacchetto-lock.json
William Hampshire,

Devi sottolineare nella tua risposta che DEVI usare npm ci nella tua build di integrazione continua se hai pacchetto-lock.json sul repository
MagicLAMP

6

Disabilita package-lock.json a livello globale

digitare quanto segue nel terminale:

npm config set package-lock false

questo funziona davvero per me come per magia


2
questo crea ~/.npmrc(almeno sui miei macos) con contenuti package-lock=falsee lo stesso può essere fatto in qualsiasi progetto specifico a fianco node_modules/(ad esempioecho 'package-lock=false' >> .npmrc
jimmont

6
è divertente per me che questo sarebbe un aspetto negativo. la community di npm non può accettare che la generazione automatica di package-lock.json sia stata un cattivo coinvolgimento della community. non dovresti fare cose che possono influire sul processo di un team. avrebbe dovuto essere un'opzione da abilitare, non forzata. quante persone fanno semplicemente "git add *" senza nemmeno accorgersene e rovinare build. Se hai qualsiasi tipo di flusso basato su fusione, so che git flow è come la bibbia per le persone che lo usano, questo non funzionerà. non puoi avere generazione su unione! npm versioning non funziona, pacchetto: 1.0.0 dovrebbe essere deterministico!
Eric Twilegar,

3
perché questo è sotto votato? questo è chiaramente un modo legittimo per disabilitare una funzionalità che non funziona. E sebbene non risponda alla domanda di per sé, si oppone alla domanda. cioè non ha più bisogno di una risposta.
Complimenti

Il motivo per cui viene ridimensionato è perché stai semplicemente disabilitando una funzione.
Raza,

5

Sì, è una pratica standard impegnare package-lock.json

Il motivo principale per cui è stato eseguito il commit di package-lock.json è che tutti nel progetto hanno la stessa versione del pacchetto.

Professionisti:-

  • Se segui un rigido controllo delle versioni e non consenti l'aggiornamento automatico alle versioni principali per salvarti da modifiche incompatibili all'indietro nei pacchetti di terze parti, il commit del blocco dei pacchetti aiuta molto.
  • Se aggiorni un determinato pacchetto, questo viene aggiornato in package-lock.json e tutti coloro che usano il repository vengono aggiornati a quella particolare versione quando prendono il pull delle tue modifiche.

Contro: -

  • Può far sembrare brutte le tue richieste pull :) '

Modifica: - npm install non si accerterà che tutti nel progetto abbiano la stessa versione del pacchetto. npm ci aiuterà con questo.


4
I contro svanirebbero se si usasse npm ciinvece di npm install.
k0pernikus,


1
"Tutti nel progetto saranno sulla stessa versione del pacchetto, tutto ciò che devi fare è installare npm" Non è vero, devi invece usare "npm ci"
reggaeguitar

Grazie, @reggaeguitar. Aggiornamento della mia risposta per questo.
Nikhil Mohadikar il

2

Il mio uso di npm è generare css / js minimizzati / ugificati e generare il javascript necessario nelle pagine servite da un'applicazione django. Nelle mie applicazioni, Javascript viene eseguito sulla pagina per creare animazioni, a volte eseguire chiamate Ajax, lavorare all'interno di un framework VUE e / o lavorare con i CSS. Se package-lock.json ha un controllo prioritario su ciò che è in package.json, potrebbe essere necessario che esista una versione di questo file. Nella mia esperienza, non ha effetto su ciò che è installato da npm install o, in caso affermativo, non ha influenzato negativamente le applicazioni che distribuisco a mia conoscenza. Non uso mongodb o altre applicazioni simili che sono tradizionalmente thin client.

Rimuovo package-lock.json dal repository perché npm install genera questo file e npm install fa parte del processo di distribuzione su ciascun server che esegue l'app. Il controllo della versione di node e npm viene eseguito manualmente su ciascun server, ma faccio attenzione che siano uguali.

Quando npm installviene eseguito sul server, cambia package-lock.json e se sono presenti modifiche a un file registrato dal repository sul server, la successiva distribuzione WONT consente di estrarre nuove modifiche dall'origine. Cioè non è possibile distribuire perché il pull sovrascriverà le modifiche apportate a package-lock.json.

Non è nemmeno possibile sovrascrivere un pacchetto-lock.json generato localmente con ciò che è sul repository (reimposta hard origin master), poiché npm si lamenterà ogni volta che si emette un comando se il pacchetto-lock.json non riflette ciò che è in node_modules a causa dell'installazione di npm, interrompendo così la distribuzione. Ora, se questo indica che sono state installate versioni leggermente diverse in node_modules, ancora una volta ciò non mi ha mai causato problemi.

Se node_modules non è nel tuo repository (e non dovrebbe esserlo), allora package-lock.json dovrebbe essere ignorato.

Se mi manca qualcosa, correggimi nei commenti, ma il punto che il controllo delle versioni è preso da questo file non ha senso. Il file package.json contiene numeri di versione e presumo che questo file sia quello utilizzato per compilare i pacchetti quando si verifica npm install, come quando lo rimuovo, npm install si lamenta come segue:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

e la compilazione fallisce, tuttavia quando si installa node_modules o si applica npm per compilare js / css, non viene fatto alcun reclamo se rimuovo package-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...

Solo per aggiungere, ora ho impegnato il mio pacchetto-lock.json nel mio repository e sto usando npm ci sulla mia distribuzione Ansible, che credo eliminare i node_modules, e installa tutto in package-lock.json senza aggiornarlo. Questo permette al mio ragazzo di front-end di aggiornare roba javascript senza bisogno di intervento manuale nella distribuzione.
MagicLAMP
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.