Devo eseguire il commit del file yarn.lock ea cosa serve?

305

Filato crea un yarn.lockfile dopo aver eseguito a yarn install.

Questo dovrebbe essere impegnato nel repository o ignorato? Cosa serve?

yarnpkg

— rlay3
fonte

3

IMHO, questa domanda (e la maggior parte delle risposte sottostanti) sono incomplete a causa della mancanza della domanda "Come e quando dovremmo rigenerare il file thread.lock?"

— MarkHu,

1

Sai ora come e quando?

— jayarjo,

@MarkHu l'ho trovato qui: yarnpkg.com/lang/en/docs/yarn-lock/#toc-managed-by-yarn Quindi, in sostanza:

Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.

— jayarjo,

Correlati: stackoverflow.com/questions/45614973/...

— k0pernikus

271

Sì, è necessario verificarlo, consultare Migrazione da npm

Yarn genererà un file yarn.lock nella directory principale del pacchetto. Non è necessario leggere o comprendere questo file: è sufficiente controllarlo nel controllo del codice sorgente.

— ckuijjer
fonte

33

Bella scoperta. Ho trovato quanto segue dai loro documenti che risponde "a cosa serve?": "Il client npm installa le dipendenze nella directory node_modules in modo non deterministico. Ciò significa che sulla base delle dipendenze dell'ordine sono installati, la struttura di un node_modules la directory potrebbe essere diversa da persona a persona. Queste differenze possono causare bug "funziona sulla mia macchina" che richiedono molto tempo per la ricerca. "

— rlay3,

13

Continua: "Il filato risolve questi problemi relativi al controllo delle versioni e al non determinismo utilizzando lockfile e un algoritmo di installazione che è deterministico e affidabile. Questi file di blocco bloccano le dipendenze installate su una versione specifica e assicurano che ogni installazione abbia la stessa identica struttura di file in node_modules su tutte le macchine. "

— rlay3,

Invece di dire "nessun file di blocco trovato". Dovrebbe semplicemente dire "Generazione del file thread.lock". Duh :) Non è un errore, ma il primo sembra un errore. E quest'ultimo sarà abbastanza allarmante per chiunque nello scenario inverso, (dove si aspettano di avere un file yarn.lock, ma apparentemente no).

— Alexander Mills,

7

Apprezzo il thread.lock sta bloccando il nostro progetto su versioni di pacchetti specifici, ma penso che l'uso della parola "lock" sia sfortunato. Di solito i file di blocco (come .ldb ) sono un mezzo per limitare una risorsa a un processo alla volta per evitare che la corruzione possa essere causata da aggiornamenti interrotti. Tali file di blocco non dovrebbero assolutamente essere impegnati nel controllo della versione, che è probabilmente il punto da cui deriva la maggior parte della confusione sul filato.lock.

— Antony,

2

Non mi piace molto la frase "non è necessario leggere o comprendere questo file". Questo è un file importante per mantenere il tuo progetto.

— Nathan Goings,

83

Dipende dal tuo progetto:

Il tuo progetto è un'applicazione? Quindi: Sì
Il tuo progetto è una biblioteca? In tal caso: No

Una descrizione più elaborata di questo può essere trovata in questo numero di GitHub in cui uno dei creatori di Yarn ad es. dice:

Package.json descrive le versioni previste desiderate dall'autore originale, mentre yarn.lock descrive l'ultima configurazione valida per una data applicazione.

yarn.lockVerrà utilizzato solo il file del progetto di livello superiore. Quindi, a meno che quei progetti non vengano usati autonomamente e non vengano installati in un altro progetto, non serve a nulla yarn.lockeseguire il commit di alcun file, ma sarà sempre package.jsoncompito del file comunicare le versioni delle dipendenze che il progetto si aspetta allora.

— VoxPelli
fonte

7

D'altra parte, il fatto che il file di blocco nei progetti di libreria non influenzerebbe la riproducibilità dei rispettivi test?

— E_net4 piacciono i voti negativi del

1

Se leggo correttamente la tua descrizione, allora "Il tuo progetto è una biblioteca?" si può rispondere con "Se vuoi". Non sembra avere aspetti negativi, ma potrebbe essere utile, se hai devDependencies complesse e vuoi che ogni sviluppatore della tua lib abbia gli stessi script di build e test. Destra?

— Pipo,

4

Poiché il file di blocco non verrà rispettato per gli utenti della tua libreria, fare affidamento su di esso durante lo sviluppo della libreria potrebbe dare un falso senso di sicurezza

— VoxPelli,

1

Dart ha lo stesso sistema con pubspec.yaml e pubspec.lock e raccomanda lo stesso della risposta. Vedi questa domanda e questa voce della documentazione.

— Jonas Kello,

16

Si prega di vedere questa voce nel blog ufficiale di Yarn: i file di blocco dovrebbero essere impegnati su tutti i progetti

— E_net4 piacciono i voti negativi del

66

Vedo che queste sono due domande separate in una. Lasciami rispondere ad entrambi.

Dovresti eseguire il commit del file in repository?

Sì. Come indicato nella risposta di ckuijjer, si consiglia di includere questo file nel repository nella Guida alla migrazione . Continua a leggere per capire perché è necessario farlo.

Che cosa è yarn.lock?

È un file che memorizza le versioni di dipendenza esatte per il tuo progetto insieme a checksum per ogni pacchetto. Questo è il modo del filato per fornire coerenza alle tue dipendenze.

Per capire perché questo file è necessario, devi prima capire qual è stato il problema dietro gli NPM originali package.json. Quando si installa il pacchetto, NPM memorizza l'intervallo di revisioni consentite di una dipendenza anziché una revisione specifica (semver). NPM tenterà di recuperare l'aggiornamento dell'ultima versione di dipendenza dell'intervallo all'interno dell'intervallo specificato (ovvero aggiornamenti di patch non interrompibili). Ci sono due problemi con questo approccio.

Gli autori delle dipendenze potrebbero rilasciare aggiornamenti della versione della patch, introducendo in realtà una modifica che influirà sul progetto.
Due sviluppatori in esecuzione npm installin momenti diversi possono ottenere il diverso set di dipendenze. Ciò può causare la non riproducibilità di un bug in due ambienti esattamente uguali. Ciò potrebbe causare, ad esempio, problemi di stabilità della build per i server CI.

D'altra parte, il filato prende la strada della massima prevedibilità. Crea yarn.lockfile per salvare le versioni esatte di dipendenza. Avere quel file sul posto filato utilizzerà le versioni archiviate yarn.lockinvece di risolvere le versioni da package.json. Questa strategia garantisce che nessuno dei problemi sopra descritti si verifichi.

yarn.lockè simile a npm-shrinkwrap.jsonquello può essere creato dal npm shrinkwrapcomando. Controlla questa risposta spiegando le differenze tra questi due file.

— Juriy
fonte

1

Ma vedo di yarn.lockessere aggiornato di tanto in tanto, sai perché e quando yarn?

— jayarjo,

1

I problemi di filato n. 4379 e n. 4147 suggeriscono che gli yarnaggiornamenti yarn.lockin molti casi, incluso l'esecuzione yarn installsenza modifiche a package.json. Usare yarn install --frozen-lockfilecome suggerito in Perché eseguire il filo su Windows cambia il thread.lock (o configurarlo tramite .yarnrc) sembra la scommessa migliore.

— Lauri Harpf,

npm al giorno d'oggi ha a package-lock.jsone a npm ci. Quel flusso di lavoro è filato analogo yarn.locke yarn install --frozen-lockfile.

— k0pernikus,

10

Immagino di sì, poiché le versioni di Yarn hanno il proprio file yarn.lock: https://github.com/yarnpkg/yarn

È usato per la risoluzione deterministica della dipendenza del pacchetto.

— jarekwg
fonte

8

Dovresti:

aggiungilo al repository e esegui il commit
utilizzare yarn install --frozen-lockfilee NON yarn installcome predefinito sia localmente che sui server di build CI.

(Ho aperto un ticket sul tracker dei problemi di filato per presentare un caso per rendere predefinito il comportamento del file di blocco congelato, vedere # 4147 ).

Fai attenzione a NON impostare il frozen-lockfileflag nel .yarnrcfile in quanto ciò ti impedirebbe di poter sincronizzare il file package.json e il filato.lock. Vedi il problema relativo al filato su github

yarn installpuò mutare il tuo filato.bloccare in modo imprevisto , rendendo nulle le rivendicazioni di filati di costruzioni ripetibili. Dovresti usare solo yarn installper inizializzare un thread.lock e aggiornarlo.

Inoltre, esp. in team più grandi, potresti avere molto rumore riguardo ai cambiamenti nel blocco del filo solo perché uno sviluppatore stava configurando il loro progetto locale.

Per ulteriori informazioni, leggi la mia risposta su npm's package-lock.json, poiché vale anche qui.

Questo è stato recentemente chiarito anche nei documenti per l'installazione del filato :

yarn install

Installa tutte le dipendenze elencate in package.json nella cartella node_modules locale.

Il yarn.lockfile viene utilizzato come segue:

Se è presente thread.lock ed è sufficiente per soddisfare tutte le dipendenze elencate in package.json, vengono installate le versioni esatte registrate in yarn.lock e il thread.lock rimarrà invariato. Il filato non controlla le versioni più recenti.

Se yarn.lock è assente o non è sufficiente per soddisfare tutte le dipendenze elencate in package.json (ad esempio, se si aggiunge manualmente una dipendenza a package.json), Yarn cerca le versioni più recenti disponibili che soddisfano i vincoli nel pacchetto .json. I risultati sono scritti su yarn.lock.

Se vuoi assicurarti che il thread.lock non sia aggiornato, usa --frozen-lockfile.

— k0pernikus
fonte

Mentre vero, l'unica volta che mi viene in mente che si dovrebbe avere per l'uso --frozen-lockfileè se qualcuno manualmente aggiornato package.json senza poi correre yarn installe commettere gli aggiornamenti. Quindi un elemento della configurazione potrebbe voler utilizzare quel flag, ma gli sviluppatori non dovrebbero perché nasconde i problemi.

— jkrehm,

@jkrehm Dipende da cosa intendi nascondendo i problemi. Ho avuto più problemi con i yarn.lockfile modificati inaspettatamente introdotti da yarn install, o gonfiando richieste pull, o causando conflitti di unione non necessari o tirando una libreria di rottura. (Solo perché una libreria usa semvar, non significa che un aggiornamento patch / minore non romperà la tua app - ci sono stato). Ritengo che l'aggiornamento yarn.lockdovrebbe essere solo un passaggio manuale, motivo per cui mi affido yarn install --frozen-lockfile(e npm ciai progetti npm) anche sulla mia macchina di sviluppo in quanto affidabile e deterministico.

— k0pernikus,

1

Non ho mai avuto problemi con yarn.lockl'aggiornamento inaspettato (utilizzato da ottobre 2016 quando è uscito). È sempre stato un utente fare qualcosa manualmente o uno script post-installazione scadente. È il motivo per cui preferisco Yarn rispetto a NPM (NPM aggiorna tutto ogni volta che lo desidera). Immagino che mi ritroverò fortunato a non essermi imbattuto in questi problemi.

— jkrehm,

5

Dalla mia esperienza, direi di sì, dovremmo eseguire yarn.lockil commit del file. Garantirà che, quando altre persone usano il tuo progetto, avranno le stesse dipendenze del tuo progetto.

Dal documento

Quando si esegue l'aggiunta di filo o filo, Yarn genererà un file yarn.lock nella directory principale del pacchetto. Non è necessario leggere o comprendere questo file: è sufficiente controllarlo nel controllo del codice sorgente. Quando altre persone iniziano a usare Yarn anziché npm, il file yarn.lock garantirà che ottengano esattamente le stesse dipendenze che hai.

Un argomento potrebbe essere che possiamo raggiungerlo sostituendolo ^con --. Sì, possiamo, ma in generale, abbiamo visto che la maggior parte dei npmpacchetti viene fornita con ^notazione e dobbiamo modificare manualmente la notazione per garantire la versione di dipendenza statica, ma se lo usi yarn.lockassicurerai a livello di codice la versione corretta.

Anche come diceva Eric Elliott qui

Non .gitignore yarn.lock. È lì per garantire la risoluzione deterministica della dipendenza per evitare bug "funziona sulla mia macchina".

— Anshul
fonte

3

Sì, dovresti impegnarlo. Per ulteriori informazioni sul file yarn.lock, fai riferimento ai documenti ufficiali qui

— Navin prasad
fonte

3

Sì! yarn.lockdeve essere registrato in modo che qualsiasi sviluppatore che installa le dipendenze ottenga esattamente lo stesso output! Con npm [che era disponibile nell'ottobre 2016] , ad esempio, puoi avere una patchversione (diciamo 1.2.0) installata localmente mentre un nuovo sviluppatore che esegue una nuova versione installpotrebbe ottenere una versione diversa (1.2.1).

— enapupe
fonte

1

Il comportamento npm che hai citato dipende da come salvi le tue dipendenze. Se risparmi con l' --save-exactutilizzo di npm, puoi ottenere lo stesso comportamento.

— AlicanC,

4

@AlicanC Non penso sia così semplice. Credo che il filo (attraverso un file di blocco impegnato) garantirà la stessa versione dei pacchetti e anche tutte le loro dipendenze . Questo è qualcosa con cui NPM ha sempre avuto un problema, perché una dipendenza di una dipendenza potrebbe non essere bloccata su una versione specifica, quindi una nuova installazione potrebbe generare dipendenze di livello inferiore diverse. Il restringimento di NPM avrebbe dovuto risolvere questo problema in una certa misura, ma è sempre stato complicato e molto spesso non funziona correttamente.

— nextgentech,

@nextgentech Se in tal caso, come posso assicurarmi che la dipendenza della dipendenza sia aggiornata correttamente. Supponiamo che io abbia un pacchetto principale che ha alcuni pacchetti (diciamo 3) dipendenti. Cercherò le modifiche nel mio pacchetto principale e lo aggiornerò in package.json. Ma se uno dei 3 sotto-pacchetti viene aggiornato da loro come riceverò le modifiche? A causa del file di blocco, tali dipendenze non verranno aggiornate, giusto?

— Pragatheeswaran,

Non ho ancora fatto un sacco di problemi, ma credo che sia qui che yarn upgradeentra in gioco il comando. Questo comando aggiorna tutti i pacchetti e ricrea il file di blocco. Quindi, ad esempio, se stai distribuendo un'app in produzione e hai bisogno di installare le dipendenze, lo farebbe in base al file di blocco tirato giù dal repository. Non eseguire mai a yarn upgrademeno che non si desideri esplicitamente modificare le informazioni sulla dipendenza (e quindi eseguire il commit di un nuovo file di blocco).

— nextgentech,

yarn installnon assicurerà le stesse versioni. Fa solo yarn install --frozen-lockfile.

— k0pernikus,