NodeJS e NPM: problemi seguente raccomandazione per controllare moduli in git

Question

sto avendo problemi seguendo la raccomandazione 'ufficiale' per il check-in tutte le dipendenze esterne in git (articolo http://www.mikealrogers.com/posts/nodemodules-in-git.html legate FAQ fron)

1. come si fa ti assicuri che non solo le dipendenze di primo livello siano archiviate? La maggior parte dei moduli NPM attualmente non seguono la raccomandazione. Hanno tutti i loro node_modules in .gitignore. Cancellare il loro .gitignore sembra rischioso.

2. Per il modulo compilato, l'articolo consiglia di eseguire il check-in solo dei sorgenti ed eseguire "npm ricostruzione" e tempo di distribuzione. Sfortunatamente 'npm rebuild' non fa un 'clean make' per tutti i moduli (nonostante il bugfix https://github.com/isaacs/npm/issues/1872 sia incluso nella versione 1.0.106 di npm che sto usando). Ciò significa che devo impedire che i target compilati vengano archiviati (altrimenti avrei compilato il codice oggetto per la macchina dello sviluppatore sulla macchina di produzione senza essere sovrascritto dalla ricostruzione di npm). Ma: come faccio? Sfortunatamente i moduli non hanno una directory di compilazione compilata, quindi basta ignorare "node_modules//build" e "/ node_modules//out /" (come menzionato in questo buon articolo eng.yammer.com/blog/ 2012/1/4/managing-nodejs-dipendenze-e-installazioni-at-yammer.html non aiuterà in tutti i casi

versione corta:. come si fa a fare in modo che i server di produzione utilizzano l'esatto stessa versione di tutti i moduli dipendenti utilizzati durante lo sviluppo?

Answer 1

AGGIORNAMENTO: ora è npm shrinkwrap che risolve il problema del blocco delle versioni esatte delle dipendenze, anche delle dipendenze 'dependenc i! More info here.

Controllo in node_modules può essere problematico, in quanto l'ambiente su cui sta girando può differire da utente a utente - cosa è compilato in qualche ambiente non può funzionare su un altro. Inoltre riempire i tuoi log delle modifiche e repository con codice di terze parti. Quello che prendo è la conslusione a cui sei arrivato con la tua versione breve della domanda, quindi lascia che ti dia una risposta.

Versione corta: come si assicura che i server di produzione utilizzino la stessa identica versione di tutti i moduli dipendenti durante lo sviluppo?

All'interno della vostra package.json, ci saranno dependencies: {}, se non c'è, quindi inserirlo. Per ottenere ciò che desideri, aggiungi le tue dipendenze come chiave e le loro esatte versioni come valore. Per esempio. dependencies: { docpad: '2.5.0', mocha: '1.1.0' }

Tuttavia, in generale (dipende l'autore) gli aggiornamenti per il numero di revisione (il numero x.x.X) sono solo correzioni di bug e di sicurezza. Puoi consentire modifiche minori facendo dependencies: { docpad: '2.5.x', mocha: '1.1.x' } che ti evita di dover aggiornare il tuo pacchetto.json e fare una versione ogni volta che c'è una versione di bugfix. Puoi anche fare cose come 2.x se lo desideri.

Questa è la soluzione che ho imparato a utilizzare per tutti i miei moduli, in quanto garantisce che anche 6 mesi dopo o qualunque altro modulo funzioni ancora - mentre fare qualcosa come >= 2.0.0 significa che quando esce una dipendenza di v3, il tuo modulo sarà probabilmente inutilizzabile in quel momento. Garantire il rispetto delle specifiche versioni "garantisce" la stabilità nel tempo.

For reference you can see how I've done it in my open-source node.js modules here

Answer 2

Circa l'.gitignore delle tue dipendenze (in "node_modules"), NPM 1.1 ignora i file .gitignore, in modo che essi non sono installati;

npm 1.1 will exclude .gitignore files from the things it installs. 
npm 1.0 did not have this feature, so you have to be careful about that. 
Deleting them recursively is fine: 
    find node_modules -name .gitignore | xargs rm 
But, in npm 1.1, you never have to do this, because it excludes them 
from the install automatically. 

che sta arrivando dal capo in persona (Isacco), e it's here e sembra coprire praticamente tutto. Il problema "estraneo" che ho deve essere qualcosa di sciocco che ho fatto, cercherò un setup pulito.