Perché "npm install" riscrive package-lock.json?

Ho appena aggiornato a npm @ 5 . Ora ho un file package-lock.json con tutto da package.json . Mi aspetto che, quando eseguo,npm install le versioni di dipendenza vengano estratte dal file di blocco per determinare cosa dovrebbe essere installato nella mia directory node_modules . La cosa strana è che finisce per modificare e riscrivere il mio file package-lock.json .

Ad esempio, nel file di blocco è stato specificato il dattiloscritto nella versione 2.1.6 . Quindi, dopo il npm installcomando, la versione è stata modificata in 2.4.1 . Ciò sembra vanificare l'intero scopo di un file di blocco.

Cosa mi sto perdendo? Come faccio a ottenere npm per rispettare effettivamente il mio file di blocco?

Aggiornamento 3: Come sottolineato anche da altre risposte, il npm cicomando è stato introdotto in npm 5.7.0 come ulteriore modo per ottenere build veloci e riproducibili nel contesto CI. Vedere la documentazione e il blog npm per ulteriori informazioni.

Aggiornamento 2: il problema per aggiornare e chiarire la documentazione è il problema n . 18103 di GitHub .

Aggiornamento 1: il comportamento descritto di seguito è stato risolto in npm 5.4.2: il comportamento attualmente previsto è delineato nel numero # 17979 di GitHub .

Risposta originale: il comportamento di è package-lock.jsonstato modificato in npm 5.1.0 come discusso nel numero # 16866 . Il comportamento che si osserva è apparentemente inteso da npm a partire dalla versione 5.1.0.

Ciò significa che package.jsonpuò eseguire l'override package-lock.jsonogni volta che viene trovata una versione più recente per una dipendenza in package.json. Se si desidera bloccare in modo efficace le proprie dipendenze, è ora necessario specificare le versioni senza prefisso, ad esempio, è necessario scriverle come 1.2.0anziché ~1.2.0o ^1.2.0. Quindi la combinazione di package.jsone package-lock.jsonprodurrà build riproducibili. Per essere chiari: package-lock.jsonda solo non blocca più le dipendenze a livello di root!

Se questa decisione di progettazione è stata buona o no è discutibile, c'è una discussione in corso risultante da questa confusione su GitHub nel numero # 17979 . (Ai miei occhi è una decisione discutibile; almeno il nome locknon è più vero.)

Un'altra nota a margine: esiste anche una restrizione per i registri che non supportano i pacchetti immutabili, come quando si estraggono i pacchetti direttamente da GitHub anziché da npmjs.org. Vedere questa documentazione dei blocchi dei pacchetti per ulteriori spiegazioni.

Ho scoperto che ci sarà una nuova versione di npm 5.7.1 con il nuovo comando npm ci, che verrà installata package-lock.jsonsolo da

Il nuovo comando npm ci viene installato SOLO dal file di blocco. Se package.json e il file di blocco non sono sincronizzati, verrà segnalato un errore.

Funziona gettando via i tuoi node_modules e ricreandoli da zero.

Oltre a garantirti che otterrai solo ciò che è nel tuo file di blocco, è anche molto più veloce (2x-10x!) Rispetto all'installazione di npm quando non inizi con un node_modules.

Come puoi prendere dal nome, ci aspettiamo che sia un grande vantaggio per gli ambienti di integrazione continua. Ci aspettiamo anche che le persone che eseguono distribuzioni di produzione dai tag git vedranno grandi guadagni.

Usa il nuovo introdotto

npm ci

npm ci promette il massimo beneficio per i team di grandi dimensioni. Dare agli sviluppatori la possibilità di "firmare" su un blocco dei pacchetti promuove una collaborazione più efficiente tra i team di grandi dimensioni e la possibilità di installare esattamente ciò che si trova in un file di blocco ha il potenziale per salvare decine se non centinaia di ore di sviluppo al mese, liberando i team per dedicare più tempo alla costruzione e alla spedizione di cose straordinarie.

Presentazione npm cidi build più veloci e affidabili

Risposta breve:

• npm install onora package-lock.json solo se soddisfa i requisiti di package.json.
• Se non soddisfa tali requisiti, i pacchetti vengono aggiornati e il blocco dei pacchetti viene sovrascritto.
• Se invece non riesci a compilare, piuttosto che riscrivere il blocco dei pacchetti quando ciò accade, usa npm ci.

Ecco uno scenario che potrebbe spiegare le cose (verificato con NPM 6.3.0)

Dichiarate una dipendenza in package.json come:

"depA": "^1.0.0"

Quindi lo fai, npm installche genererà un pacchetto-lock.json con:

"depA": "1.0.0"

Pochi giorni dopo, viene rilasciata una versione minore di "depA", ad esempio "1.1.0", quindi vale quanto segue:

npm ci       # respects only package-lock.json and installs 1.0.0

npm install  # also, respects the package-lock version and keeps 1.0.0 installed 
             # (i.e. when package-lock.json exists, it overrules package.json)

Successivamente, aggiorni manualmente package.json a:

"depA": "^1.1.0"

Quindi rieseguire:

npm ci      # will try to honor package-lock which says 1.0.0
            # but that does not satisfy package.json requirement of "^1.1.0" 
            # so it would throw an error 

npm install # installs "1.1.0" (as required by the updated package.json)
            # also rewrites package-lock.json version to "1.1.0"
            # (i.e. when package.json is modified, it overrules the package-lock.json)

Utilizzare il npm cicomando anziché npm install.

"ci" sta per "integrazione continua".

Installerà le dipendenze del progetto in base al file package-lock.json anziché alle dipendenze del file lenient package.json.

Produrrà build identiche ai tuoi compagni di squadra ed è anche molto più veloce.

Puoi leggere di più a riguardo in questo post del blog: https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

In futuro, sarai in grado di utilizzare un --from-lock-fileflag (o simile) per installare solo da package-lock.jsonsenza modificarlo.

Ciò sarà utile per ambienti CI, ecc. In cui le build riproducibili sono importanti.

Consulta https://github.com/npm/npm/issues/18286 per il monitoraggio della funzione.

Sembra che questo problema sia stato risolto in npm v5.4.2

https://github.com/npm/npm/issues/17979

(Scorri verso il basso fino all'ultimo commento nel thread)

Aggiornare

Corretto effettivamente in 5.6.0. Si è verificato un errore multipiattaforma in 5.4.2 che causava ancora il problema.

https://github.com/npm/npm/issues/18712

Aggiornamento 2

Vedi la mia risposta qui: https://stackoverflow.com/a/53680257/1611058

npm ci è il comando che dovresti usare quando installi progetti esistenti adesso.

Probabilmente hai qualcosa del tipo:

"typescript":"~2.1.6"

nel package.jsonquale npm si aggiorna all'ultima versione minore, nel tuo caso2.4.1

Modifica: domanda dall'OP

Ma ciò non spiega perché "npm install" cambierebbe il file di blocco. Il file di blocco non è pensato per creare una build riproducibile? In tal caso, indipendentemente dal valore del semver, dovrebbe comunque utilizzare la stessa versione 2.1.6.

Risposta:

Questo ha lo scopo di bloccare l'intero albero delle dipendenze. Diciamo che typescript v2.4.1richiede widget ~v1.0.0. Quando si installa npm lo prende widget v1.0.0. Successivamente il tuo collega sviluppatore (o build CI) esegue un'installazione npm e ottiene typescript v2.4.1ma widgetè stato aggiornato a widget v1.0.1. Ora il tuo modulo nodo non è sincronizzato. Questo è ciò che package-lock.jsonimpedisce.

O più in generale:

Ad esempio, considera

pacchetto A:

{"name": "A", "version": "0.1.0", "dependencies": {"B": "<0.1.0"}}

pacchetto B:

{"name": "B", "version": "0.0.1", "dependencies": {"C": "<0.1.0"}}

e pacchetto C:

{"name": "C", "version": "0.0.1"}

Se queste sono le uniche versioni di A, B e C disponibili nel registro, verrà installata una normale installazione npm A:

A@0.1.0 - B@0.0.1 - C@0.0.1

Tuttavia, se viene pubblicato B@0.0.2, verrà installata una nuova installazione npm A:

A@0.1.0 - B@0.0.2 - C@0.0.1 supponendo che la nuova versione non abbia modificato le dipendenze di B. Naturalmente, la nuova versione di B potrebbe includere una nuova versione di C e un numero qualsiasi di nuove dipendenze. Se tali modifiche sono indesiderabili, l'autore di A potrebbe specificare una dipendenza da B@0.0.1. Tuttavia, se l'autore di A e l'autore di B non sono la stessa persona, non c'è modo per l'autore di dire che non vuole inserire le versioni di C pubblicate di recente quando B non è cambiato affatto.

Domanda OP 2: Fammi vedere se ho capito bene. Quello che stai dicendo è che il file lock specifica le versioni delle dipendenze secondarie, ma si basa ancora sulla corrispondenza fuzzy di package.json per determinare le dipendenze di livello superiore. È preciso?

Risposta: No. package-lock blocca l'intero albero dei pacchetti, inclusi i pacchetti root descritti in package.json. Se typescriptè bloccato 2.4.1nel tuo package-lock.json, dovrebbe rimanere tale fino a quando non viene modificato. E diciamo che domani typescriptrilascia la versione 2.4.2. Se controllo il tuo ramo ed npm installeseguo, npm rispetterà il file di blocco e l'installazione 2.4.1.

Maggiori informazioni su package-lock.json:

package-lock.json viene generato automaticamente per qualsiasi operazione in cui npm modifica l'albero node_modules 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" verso gli stati precedenti di node_modules senza dover eseguire il commit della 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.

https://docs.npmjs.com/files/package-lock.json

Probabilmente dovresti usare qualcosa del genere

npm ci

Invece di utilizzare npm install se non si desidera modificare la versione del pacchetto.

Secondo la documentazione ufficiale, entrambi npm installe npm ciinstallare le dipendenze necessarie per il progetto.

La differenza principale è npm installche installa i pacchetti prendendo packge.jsoncome riferimento. Dove nel caso di npm ci, installa i pacchetti prendendo package-lock.jsoncome riferimento, assicurandosi ogni volta che viene installato il pacchetto esatto.

C'è un problema aperto per questo sulla loro pagina github: https://github.com/npm/npm/issues/18712

Questo problema è particolarmente grave quando gli sviluppatori utilizzano sistemi operativi diversi.

EDIT: il nome "lock" è difficile, il suo NPM sta cercando di raggiungere Yarn. Non è assolutamente un file bloccato. package.jsonè un file corretto dall'utente, che una volta "installato" genererà l'albero delle cartelle node_modules e tale albero verrà quindi scritto package-lock.json. Come vedi, è il contrario: le versioni delle dipendenze verranno estratte package.jsoncome sempre e package-lock.jsondovrebbero essere chiamatepackage-tree.json

(spero che questo abbia reso la mia risposta più chiara, dopo così tanti voti negativi)

Una risposta semplicistica: package.jsonavere le proprie dipendenze come al solito, mentre package-lock.jsonè "un albero node_modules esatto e, soprattutto, riproducibile" (preso dagli stessi documenti di npm ).

Per quanto riguarda il nome difficile, il suo NPM sta cercando di raggiungere Yarn.