Dovrei .npmignorare i miei test?

91

Cosa dovrei inserire esattamente .npmignore?

Test? Roba come .travis.yml, .jshintrc? Qualcosa che non è necessario durante l'esecuzione del modulo (eccetto il readme)?

Non riesco a trovare alcuna guida su questo.

node.js  npm  npmignore 
— callum
fonte
4
dovrebbe ignorare tutto ciò che non è necessario quando qualcuno chiama npm install yourlibrary, ad esempio .travis.ymle.jshintrc
— lante
veramente? anche un readme? è raccomandato ufficialmente ovunque?
— callum
2
README viene incluso automaticamente indipendentemente da .npmignoreo "files"( docs.npmjs.com/files/package.json#files ).
— Nicolás Fantone

Risposte:

86

Come probabilmente hai scoperto, NPM non specifica esattamente cosa dovrebbe essere inserito, piuttosto ha un elenco di file ignorati per impostazione predefinita . Molte persone non lo usano nemmeno perché tutto nel tuo .gitignoreviene ignorato npmper impostazione predefinita se .npmignorenon esiste. Inoltre, molti file sono già ignorati per impostazione predefinita indipendentemente dalle impostazioni e alcuni file sono sempre esclusi dall'essere ignorati, come indicato nel collegamento sopra.

Non c'è molto ufficiale su ciò che dovrebbe essere sempre lì perché è fondamentalmente un sottoinsieme di .gitignore, ma da quello che ho raccolto dall'uso di node per 5 anni, ecco cosa ho trovato.

Nota: per produzione intendo qualsiasi momento in cui il tuo modulo viene utilizzato da qualcuno e non per svilupparsi sul modulo stesso.

Fonti cross-compilate pre-rilascio

  • Pro : se si utilizza un linguaggio che esegue la compilazione incrociata in JavaScript, è possibile precompilare prima del rilascio e non includere .coffeefile nel pacchetto, ma continuare a tracciarli nel repository git.

Crea gli avanzi di file

  • Pro : le persone che usano cose come node-gyppotrebbero avere file oggetto che vengono generati durante una build che non dovrebbero mai essere inseriti nel pacchetto.
  • Contro : questo dovrebbe sempre andare in .gitignoreogni caso. Devi mettere queste cose qui dentro se stai .npmignoregià usando un file in quanto sovrascrive .gitignoredal punto di vista di npm.

Test

  • Pro : meno bagaglio nel codice di produzione.
  • Contro : non è possibile eseguire test su ambienti live nella minima possibilità che si verifichi un errore specifico del sistema, ad esempio una versione obsoleta del nodo in esecuzione che causa il fallimento di un test.

Impostazioni di integrazione continua / Meta file

  • Pro : ancora una volta, meno bagagli. Cose come.travis.yml non sono necessarie per usare, testare o visualizzare il codice.

Documenti non leggimi ed esempi di codice

  • Professionisti : meno bagagli. Alcune persone esistono nella scuola di pensiero dove se non puoi esprimere almeno la minima funzionalità possibile nel tuo file Readme, il tuo modulo è troppo grande.
  • Contro : le persone non possono vedere la documentazione esaustiva e gli esempi di codice sul proprio file system. Dovrebbero visitare il repository (che richiede anche una connessione Internet).

Oggetti Github-pages

  • Pro : Certamente non è necessario sporcare le tue pubblicazioni con CNAMEfile o segnaposto index.htmlse usi il tuo modulo che serve comegh-pages repository.

bower.json e amici

  • Pro : se decidi di creare le tue dipendenze prima del rilascio, non è necessario che l'utente finale installi bower, quindi installi più cose con quello. Personalmente, terrei quella roba nel pacchetto. Quando npm installeseguo un , dovrei fare affidamento solo su npm e non altre fonti esterne.

Fondamentalmente, dovresti mai usarlo se c'è qualcosa che desideri tenere fuori dal tuo pacchetto npm ma non dal tuo repository npm. Non è un lungo elenco di elementi, ma npm preferirebbe integrare la funzionalità piuttosto che avere persone bloccate con oggetti irrilevanti nel loro pacchetto.

— SamT
fonte
Non c'è un modo per rimuovere gli script non utilizzabili dal file package.json. Ad esempio, testare gli script? Mi sento un po 'incasinato a rimuovere tutto ma tengo gli script nel file ...
— inf3rno
No non c'è. Puoi ometterli dal package.json poiché è principalmente per NPM e se stai solo eseguendo test, puoi accedervi tramite il comando originale per eseguirli.
— SamT
64

Sono d'accordo con la risposta breve e sintetica di lante e la grande risposta di SamT :

  • Non dovresti includere i tuoi test nel tuo pacchetto.
  • Il pacchetto dovrebbe contenere solo file di runtime di produzione.
  • Ciò renderà il tuo pacco più semplice e veloce da scaricare.

Il mio contributo a quelle risposte:

.npmignore è il modo nella lista nera per ottenere la selezione del file del pacchetto. Ma in un modo più pratico, puoi inserire nella whitelist i file che devi includere nel tuo pacchetto usando il campo files nel tuo package.json:

{
  "files": [
    "lib/",
    "index.js"
  ]
}

Penso che sia più semplice, a prova di futuro e abbia una semantica migliore;)

— Yves M.
fonte
3
... per non parlare di più facile da ricordare e meno incline agli incidenti da usare (se sei smemorato come posso essere). Grazie per il suggerimento, è fantastico.
— Connor
2
Mi piace questo approccio.
— Brady Holt
2
Penso che tu possa anche omettere "index.js" assumendo che sia il file 'principale' nel tuo package.json :)
— Ben George
Ignorare immagini e documenti non necessari va bene. Ma ignorare i test probabilmente non è una buona idea. Il download di alcuni KB extra non richiede molto tempo e fare una ricorsiva npm testsu tutti i node_modules può darti un suggerimento se qualcosa funziona in modo diverso in un determinato ambiente.
— adelriosantiago
3
@ NicolásFantone La proprietà files accetta anche il pattern glob . Quindi possiamo ignorare i file di prova senza creare .npmignore. files: ["lib", "!lib/**/*.test.js"]. :)
— Sureshraj
15

Giusto per chiarire, ogni volta che qualcuno lo fa npm install your-library, npm scaricherà tutti i file sorgente inclusi nel repository, ad eccezione dei file che includi nel tuo.npmignore .

Sappi che le persone che installano la tua libreria avranno bisogno solo della tua libreria in esecuzione, qualsiasi altra cosa non sarà necessaria.

Ad esempio, quando qualcuno installa una libreria, è probabile che non gli importi dei tuoi .travis.ymlo dei tuoi .jshintrcfile, o anche di alcune immagini, file Grunt, documentazione, ecc.

.npmignore potrebbe lasciare che il tuo pacchetto npm abbia meno file e più veloce da scaricare

— lante
fonte
1
Il sentimento qui è buono, ma per chiarire: .npmignorenon influisce direttamente su ciò che viene scaricato , influisce su ciò che entra nel tuo pacchetto quando npm pubblichi e carichi. Questo indirettamente crea file più piccoli da scaricare.
— Mark Stosberg
2

Non includere i tuoi test. Spesso i test sono circa 5 volte la dimensione della base di codice effettiva. Finché i tuoi test sono su Github, ecc., È abbastanza buono.

Ma quello che dovresti assolutamente fare è testare il tuo pacchetto NPM nel formato pubblicato . Creare alcuni test del fumo che risiedono nella base di codice effettiva, ma non fanno parte della suite di test.

Puoi leggere informazioni sul test del tuo pacchetto dopo averlo tarballato, qui: https://github.com/ORESoftware/r2g

Come testare un risultato di "pubblicazione npm", senza effettivamente pubblicare su NPM?

— Alexander Mills
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.