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

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.

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.

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

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

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).

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.

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.

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 [.]

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

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.

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 ...