Stiamo usando il filato per tutte le nostre installazioni deterministiche di pkg ma non impediamo all'utente di usare npm - immagino che avere entrambi questi file causerà problemi comunque. Dovrebbe essere aggiunto alla tua directory .gitignore?

Esegui sempre il commit dei file di blocco delle dipendenze in generale

Come è coperto altrove, file di lock dipendenza, che sono supportati da molti sistemi di gestione dei pacchetti (per esempio: il compositore e Bundler ), dovrebbero impegnarsi a base di codice in progetti di fine catena - in modo che ogni individuo che cerca di eseguire quel progetto sta facendo quindi con esattamente il set di dipendenze testato.

È meno chiaro se i file di blocco debbano sempre essere inseriti in pacchetti destinati ad essere inclusi in altri progetti (dove sono desiderabili dipendenze più sciolte). Tuttavia, sia Yarn che NPM (come coperto da @Cyrille) ignorano in modo intelligente yarn.locke package-lock.jsonrispettivamente dove necessario, rendendo sicuro il commit di questi file di blocco.

Quindi dovresti sempre eseguire il commit di almeno uno yarn.locko inpackage-lock.json base al gestore di pacchetti che stai utilizzando.

Dovresti eseguire il commit sia di yarn.lock che di package-lock.json?

Attualmente abbiamo due diversi sistemi di gestione dei pacchetti, che sia installare lo stesso insieme di dipendenze da package.json, ma che generano e letti da due file di lock differenti. NPM 5 genera package-lock.json, mentre Yarn genera yarn.lock.

Se effettui il commit package-lock.json, stai costruendo il supporto per le persone che installano le tue dipendenze con NPM 5. Se ti impegni yarn.lock, stai costruendo il supporto per le persone che installano le dipendenze con Yarn.

Se scegli di impegnarti yarn.locko di package-lock.jsonentrambi dipende dal fatto che coloro che sviluppano il tuo progetto utilizzino solo Yarn o NPM 5 o entrambi. Se il tuo progetto è open source, la cosa più adatta alla comunità da fare sarebbe probabilmente impegnare entrambi e disporre di un processo automatizzato per garantire yarn.locke package-lock.jsonrimanere sempre sincronizzati.

Aggiornamento: Yarn ha ora introdotto un importcomando che genererà un yarn.lockfile da un package-lock.jsonfile. Questo potrebbe essere utile per mantenere sincronizzati i due file. (Grazie @weakish)

Questo problema è stato discusso a lungo nel progetto Yarn in:

• "Idea: supporta package-lock.json da npm 5"
• "I file di blocco concorrenti creano una UX scadente"

Entrambi sono ora chiusi.

Dovresti eseguire il commit di 1 file di blocco dell'albero delle dipendenze, ma non dovresti eseguire il commit di entrambi. Ciò richiede anche la standardizzazione su filato o npm (non entrambi) con cui costruire + sviluppare un progetto.

Ecco l'articolo sul filato sul motivo per cui il filato.lock dovrebbe essere impegnato, se standardizzi il filato.

Se si esegue il commit sia del yarn.lockfile CHE dei package-lock.jsonfile, ci sono molti modi in cui i 2 file possono fornire diversi alberi delle dipendenze (anche se gli algoritmi di risoluzione dell'albero di filato e npm sono identici), ed è non banale assicurarsi che forniscano esattamente stessa risposta. Poiché non è banale, è improbabile che lo stesso albero delle dipendenze venga mantenuto in entrambi i file e non si desidera un comportamento diverso a seconda che la compilazione sia stata eseguita utilizzando filato o npm.

Se e quando il filato passa dall'uso yarn.locka package-lock.json( problema qui ), la scelta del file di blocco da eseguire il commit diventa facile e non dobbiamo più preoccuparci del filato e dell'npm che si traducono in build diverse. Sulla base di questo post del blog , questo è un cambiamento che non dovremmo aspettarci a breve (il post del blog descrive anche le differenze tra yarn.locke package-lock.json.

Stavo pensando alla stessa domanda. Ecco i miei pensieri, spero che aiuti:

La documentazione di npm package-lock.json dice quanto segue:

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 tale che le installazioni successive siano in grado di generare alberi identici, indipendentemente dagli aggiornamenti intermedi delle dipendenze.

Questo è ottimo perché impedisce l'effetto "lavori sulla mia macchina".

Senza questo file, se tu npm install --save A, npm aggiungerà "A": "^1.2.3"al tuo file package.json. Quando qualcun altro esegue npm installil tuo progetto, è possibile che la versione 1.2.4di Aè stata rilasciata. Poiché è l'ultima versione disponibile che soddisfa l'intervallo di semver specificato nel tuo package.json, installerà questa versione. Ma cosa succede se c'è un nuovo bug introdotto in questa versione? Questa persona avrà un problema che non puoi riprodurre perché hai la versione precedente, senza alcun bug.

Fissando lo stato della tua node_modulesdirectory, package-lock.jsonfile previene questo problema perché tutti avranno le stesse versioni di ogni pacchetto.

Ma cosa succede se scrivi e pubblichi un modulo npm? La documentazione dice quanto segue:

Un dettaglio chiave su package-lock.json è che non può essere pubblicato e verrà ignorato se trovato in un posto diverso dal pacchetto di primo livello.

Quindi, anche se lo commetti, quando l'utente installa il tuo modulo, non riceverà il package-lock.jsonfile, ma solo il package.jsonfile. Quindi npm installerà l'ultima versione che soddisfa gli intervalli di semver di tutte le tue dipendenze. Significa che vuoi sempre testare il tuo modulo con queste versioni delle tue dipendenze, e non quella che hai installato quando hai iniziato a scrivere il tuo modulo. Quindi, in quel caso, package-lock.jsonè chiaramente inutile. Inoltre, può essere fastidioso.

Ecco la mia regola pratica: se stai lavorando su un'applicazione, salva i file di blocco. Se stai gestendo una libreria, aggiungila al tuo elenco ignorato. In entrambi i casi dovresti usare intervalli di semver accurati in package.json. Yehuda Katz ( memorizzato nella cache ) ha scritto un'ottima spiegazione per quando eseguire il commit Gemfile.lock(file di blocco di Ruby) e quando no. Almeno leggi la sezione tl; dr.

Hai ragione! Consentire l'uso di npme yarncauserà problemi. Dai un'occhiata a questo articolo .

Attualmente, stiamo pianificando di aggiungere alcuni avvisi agli utenti che utilizzano entrambi yarn e npmnello stesso repository per installare i pacchetti.

Ti consigliamo vivamente di eliminare il package-lock.jsonfile se decidi di utilizzare il filato per evitare future confusioni e possibili problemi di coerenza.

Potresti non volere entrambi npme yarncome gestore di pacchetti.

Questi file sono gestiti dai tuoi strumenti, quindi, supponendo che l'uso di filato aggiorni effettivamente, package-lock.jsonsuppongo che il commit di entrambi i file funzioni bene.

Penso che la cosa più importante per il tuo utente sia package-lock.json(io, per esempio, non uso il filo) quindi questo deve essere impegnato.

Per il yarn.lock, dipende se lavori da solo o in squadra. Se da solo, suppongo che non sia necessario impegnarlo. Se (pianifichi di) lavorare in una squadra, probabilmente dovresti impegnarlo, almeno fino a quando il filo non lo supporta 🙂

Suppongo che il team dei filati alla fine smetterà di usare yarn.locke userà package-json.lockinvece, in questo momento diventerà più semplice 😛

No, l'utilizzo simultaneo di entrambi i file di blocco si tradurrà molto spesso in incongruenze nell'albero delle dipendenze, soprattutto quando si collabora in un team. Ignorare una serratura o l'altra è una soluzione semplice. Assicurati solo che il tuo team comprenda e sia d'accordo con questo cambiamento.