2012-09-21 13 views
7

Il mio editor produce file di lavoro e cartelle di backup che non interessano gli utenti del software che scrivo. Per evitare di dover elencare le mie ignorazioni specifiche per ogni editor in ogni progetto, sto cercando di dire a npm di ignorarle a livello utente o globale.Perché npm non onora l'utente/global npmignore?

Sfortunatamente, non sto avendo fortuna a farlo. L'esecuzione di npm pack nella cartella del mio progetto, anche se svuoto prima la cache di npm, include sia il file dello spazio di lavoro che due megabyte di file di backup. (Per un progetto con solo dieci kilobyte di codice!) Ho provato l'impostazione di configurazione ignore, un numero per utente .npmignore e uno globale npmignore, il tutto senza alcun effetto.

Ecco la mia uscita dal npm config ls -l, stato tagliato a sezioni pertinenti:

; userconfig C:\Users\benblank\.npmrc 
ignore = "__history *.epp" 

; builtin config undefined 
prefix = "C:\\Users\\benblank\\AppData\\Roaming\\npm" 

; default values 
globalignorefile = "C:\\Users\\benblank\\AppData\\Roaming\\npm\\etc\\npmignore" 
userignorefile = "C:\\Users\\benblank\\.npmignore" 

E le (identici) contenuto di C:\Users\benblank\.npmignore e C:\Users\benblank\AppData\Roaming\npm\etc\npmignore:

__history 
*.epp 

Che cosa sto facendo di sbagliato? Sono in esecuzione Windows 7, [email protected] e [email protected]

+0

Hai mai risolto? – laggingreflex

+1

['globalignorefile' è" documentato ma non implementato "] (https://groups.google.com/forum/#!topic/npm-/m2eQPMRrjIc), tuttavia sembra (v2.5). '/ etc/npmignore' non funziona neanche. – laggingreflex

+1

[bug noto] (https://github.com/npm/npm/issues/2634) – laggingreflex

risposta

2

npm ha alcuni importanti outstanding issues relativi ai file npmignore.

Per fortuna c'è un'alternativa ancora migliore! È la proprietà package.json files.

Ecco un esempio dal mio progetto delivr.

"files": [ 
    "lib", 
    "index.js" 
] 

Perché è meglio?

  1. I meccanismi interni rendono questo meccanismo più affidabile.
  2. È una lista bianca invece di una lista nera. In genere, supponendo di utilizzare una cartella lib (o simile), ci sono meno file/directory che si desidera inclusi rispetto a quelli che si desidera esclusi, quindi è più conciso.
  3. È DRY. Se esiste un file .npmignore, npm non consulta lo .gitignore per i pattern di ignoranza, che spesso richiedono informazioni sovrapposte e ripetitive. Questo problema non esiste con una lista bianca.
  4. Un file in meno nel repository. package.json è già un manifest che definisce il pacchetto e ha un senso per questa configurazione di vivere lì.
Problemi correlati