Risposte:
La risposta non è facile come suggerisce Alberto Zaccagni. Se sviluppi applicazioni (in particolare applicazioni enterprise), inclusi node_modules nel tuo repository git è una scelta praticabile e quale alternativa scegli dipende dal tuo progetto.
Poiché ha discusso molto bene contro node_modules, mi concentrerò sugli argomenti per loro.
Immagina di aver appena finito un'app aziendale e dovrai supportarla per 3-5 anni. Sicuramente non vuoi dipendere dal modulo npm di qualcuno che domani potrebbe scomparire e non puoi più aggiornare la tua app.
Oppure hai i tuoi moduli privati che non sono accessibili da Internet e non puoi costruire la tua app su Internet. O forse non vuoi dipendere dal tuo build finale sul servizio npm per alcuni motivi.
Puoi trovare pro e contro in questo articolo di Addy Osmani (anche se si tratta di Bower, è quasi la stessa situazione). E finirò con una citazione dalla homepage di Bower e dall'articolo di Addy:
"Se non stai creando un pacchetto destinato ad essere utilizzato da altri (ad esempio, stai creando un'app Web), dovresti sempre controllare i pacchetti installati nel controllo del codice sorgente."
git checkout foo. Se node_modules non è in VCS - lo scambio di rami è git checkout foo ; npm installe qualunque cosa la tua attuale versione di NPM richiede per funzionare;)
I dettagli dei moduli sono memorizzati packages.json, questo è sufficiente. Non è necessario effettuare il check-in node_modules.
Le persone erano solite archiviare il node_modulescontrollo versione per bloccare le dipendenze dei moduli, ma con npm shrinkwrap non è più necessario.
Un'altra giustificazione per questo punto, come ha scritto @ChrisCM nel commento:
Inoltre, vale la pena notare che tutti i moduli che coinvolgono estensioni native non funzionano da architettura a architettura e devono essere ricostruiti. Fornire una giustificazione concreta per NON includerli nel repository.
Vorrei raccomandare di non archiviare node_modules a causa di pacchetti come PhantomJS e node-sass, ad esempio, che installano il binario appropriato per il sistema attuale.
Ciò significa che se un Dev viene eseguito npm installsu Linux e verifica in node_modules, non funzionerà per un altro Dev che clona il repository su Windows.
È meglio controllare nei tarball quali npm installano i download e puntarli npm-shrinkwrap.json. Puoi automatizzare questo processo usando shrinkpack .
npm install --global shrinkpackquindi la debolezza differita, richiedendo altri pacchetti con cui installare i pacchetti rimpiccioliti? Questo va contro il consiglio di Addy.
shrinkpackè necessaria la dipendenza per installare in modo affidabile le dipendenze di build. Pertanto, l'installazione dello strumento di creazione stesso diventa il punto debole dell'argomento contro l'invio di tutte le dipendenze di build al controllo di versione.
Questo argomento è piuttosto vecchio, vedo. Ma mi manca qualche aggiornamento agli argomenti forniti qui a causa della mutata situazione nell'ecosistema di npm.
Consiglio sempre di non mettere node_modules sotto controllo di versione. Quasi tutti i benefici derivanti dal farlo, elencati nel contesto della risposta accettata, sono piuttosto obsoleti al momento.
I pacchetti pubblicati non possono più essere facilmente revocati dal registro npm. Quindi non devi temere di perdere dipendenze su cui il tuo progetto ha fatto affidamento prima.
Mettere il file package-json.lock in VCS aiuta con le dipendenze frequentemente aggiornate che probabilmente portano a diverse configurazioni facendo affidamento sullo stesso file package.json.
Pertanto, l'inserimento di node_modules in VCS in caso di strumenti di compilazione offline potrebbe essere considerato l'unico caso d'uso idoneo rimasto. Tuttavia, node_modules di solito cresce abbastanza velocemente. Qualsiasi aggiornamento cambierà molti file. E questo sta influenzando i repository in diversi modi. Se consideri davvero gli effetti a lungo termine, questo potrebbe essere anche un impedimento.
VCS centralizzato come svn richiede il trasferimento di file di commit e di checkout sulla rete, che sarà lento come l'inferno quando si tratta di estrarre o aggiornare una cartella node_modules.
Quando si tratta di git questo elevato numero di file aggiuntivi inquinerà immediatamente il repository. Tieni presente che git non sta monitorando le differenze tra le versioni di qualsiasi file, ma sta memorizzando copie di entrambe le versioni di un file non appena un singolo carattere è cambiato. Ogni aggiornamento a qualsiasi dipendenza si tradurrà in un altro grosso changeset. Il tuo repository git diventerà rapidamente enorme a causa di ciò che influisce sui backup e sulla sincronizzazione remota. Se decidi di rimuovere node_modules dal repository git in un secondo momento, sarà ancora parte di esso per motivi storici. Se hai distribuito il tuo repository git su un server remoto (ad es. Per il backup), pulirlo è un'altra attività dolorosa e soggetta a errori in cui ti imbatteresti.
Pertanto, se ti interessano processi efficienti e ti piace mantenere le cose "piccole", preferirei utilizzare un repository di artefatti separato come Nexos Repository (o solo un server HTTP con archivi ZIP) che fornisce alcune serie di dipendenze precedentemente scaricate per il download.
Non tracciare node_modulescon il controllo del codice sorgente è la scelta giusta perché alcuni moduli NodeJS, come il driver MongoDB NodeJS, utilizzano i componenti aggiuntivi NodeJS C ++. Questi componenti aggiuntivi vengono compilati durante l'esecuzione del npm installcomando. Pertanto, quando si tiene traccia della node_modulesdirectory, è possibile eseguire il commit accidentale di un file binario specifico del sistema operativo.
Sono d'accordo con ivoszz che a volte è utile controllare la cartella node_modules, ma ...
scenario 1:
Uno scenario: usi un pacchetto che viene rimosso da npm. Se hai tutti i moduli nella cartella node_modules, non sarà un problema per te. Se hai solo il nome del pacchetto in package.json, non puoi più ottenerlo. Se un pacchetto ha meno di 24 ore, è possibile rimuoverlo facilmente da npm. Se ha più di 24 ore, è necessario contattarli. Ma:
Se contatta l'assistenza, controlleranno se la rimozione di quella versione del pacchetto interromperà qualsiasi altra installazione. In tal caso, non lo rimuoveremo.
Quindi le possibilità per questo sono basse, ma c'è lo scenario 2 ...
scenario 2:
Un altro scenario in cui questo è il caso: sviluppi una versione aziendale del tuo software o un software molto importante e scrivi nel tuo package.json:
"dependencies": {
"studpid-package": "~1.0.1"
}Si utilizza il metodo function1(x) di quel pacchetto.
Ora gli sviluppatori di studpid-pacchetto di rinominare il metodo function1(x)di function2(x)e fanno un guasto ... Cambiano la versione del loro pacchetto da 1.0.1a 1.1.0. Questo è un problema perché quando chiami npm installla prossima volta, accetti la versione 1.1.0perché hai usato la tilde ("studpid-package": "~1.0.1" ).
La chiamata function1(x)può causare errori e problemi ora.
Ma:
Il push dell'intera cartella node_modules (spesso più di 100 MB) nel repository, ti costerà spazio di memoria. Pochi kb (solo package.json) rispetto a centinaia di MB (package.json e node_modules) ... Pensaci.
Potresti farlo / dovresti pensarci se:
il software è molto importante.
ti costa denaro quando qualcosa fallisce.
non ti fidi del registro npm. npm è centralizzato e potrebbe teoricamente essere chiuso.
Non è necessario pubblicare la cartella node_modules nel 99,9% dei casi se:
sviluppi un software solo per te stesso.
hai programmato qualcosa e vuoi solo pubblicare il risultato su GitHub perché qualcun altro potrebbe essere interessato a questo.
Se non si desidera che node_modules si trovi nel proprio repository, è sufficiente creare un .gitignorefile e aggiungere la riga node_modules.
npm installsu Windows e MacOS potrebbe generare file diversi (file dipendenti dal sistema operativo) in alcuni pacchetti. Ma non ne sono sicuro. Qualcuno può verificare che questo sia vero?
package-lock.json. Se in futuro c'è un problema con un aggiornamento di studpid-package, puoi ripristinare il file di blocco per scoprire la versione esatta che ha funzionato per te.
Vorrei offrire una via di mezzo alternativa.
node_modules in Git.package-lock.json file per inchiodare le versioni di dipendenza.Nel raro caso in cui non sia possibile accedere a NPM (o ad altri registri utilizzati) o a un pacchetto specifico in NPM, si dispone di una copia di node_modules e si può continuare a lavorare fino al ripristino dell'accesso.
Un'altra cosa da considerare: il check-in node_modulesrende più difficile / impossibile usare la differenza tra dependenciese devDependencies.
D'altra parte, si potrebbe dire che è rassicurante spingere alla produzione lo stesso identico codice che ha superato i test, quindi anche devDependencies.