Dove devo memorizzare la cache di un modulo npm CLI personalizzato?

Question

Sto sviluppando un modulo npm, dove l'utente può interagire con esso tramite un terminale per l'esecuzione di comandi:

> mymodule init 
> mymodule do stuff 

Nell'eseguire determinati comandi utente viene chiesto per alcuni dati, che saranno utilizzati dal modulo. Dato che questi dati non cambieranno davvero durante l'uso del modulo e poiché questi comandi possono essere eseguiti abbastanza frequentemente, non è la migliore opzione per chiedere all'utente i dati ogni volta che esegue un comando. Quindi ho deciso di mettere in cache questi dati, e non appena dovrebbe vivere attraverso più chiamate di moduli, il modo più semplice per memorizzarlo che vedo è un file (la struttura dei dati consente di archiviarlo in un semplice JSON). Ma sono abbastanza sicuro di dove dovrebbe andare questo file sulla macchina di un utente.

Dove nel file system dovrei memorizzare una cache in una forma di un file o più file per un modulo npm personalizzato, considerando che il modulo stesso può essere installato globalmente, su più sistemi operativi e può essere utilizzato in più progetti allo stesso tempo?

Stavo pensando di archiviarlo nella cartella di un modulo, ma potrebbe essere complicato in caso di installazione globale + utilizzo di più progetti. La seconda idea era di archiviarla in un archivio di tmp specifico per il sistema operativo, ma non ne sono abbastanza sicuro. Mi sto anche chiedendo se ci sono alcune alternative alla memorizzazione dei file in questo caso.

Answer 1

Su som I sistemi che è possibile memorizzare in cache su ~/.cache creano una sottodirectory per memorizzare i dati della cache, sebbene sia molto più comune per le applicazioni creare una directory nascosta nella home directory degli utenti. Sulle moderne macchine Windows è possibile utilizzare creare una directory in C:/Users/someUser/AppData.In Windows utilizzando un suffisso . non si nasconde un file. Mi consiglia di fare qualcosa di piattaforma agnostica in questo modo:

var path = require('path'); 

function getAppDir(appName, cb) { 
    var plat = process.platform; 

    var homeDir = process.env[(plat == 'win32') ? 'USERPROFILE' : 'HOME']; 
    var appDir; 

    if(plat == 'win32') { 
     appDir = path.join(homeDir, 'AppData', appName); 
    } 
    else { 
     appDir = path.join(homeDir, '.' + appName); 
    } 

    fs.mkdir(appDir, function(err) { 
     if(err) return cb(err); 

     cb(null, appDir); 
    }) 
} 

Basta dichiarare una funzione per ottenere la cartella app. Questo dovrebbe gestire la maggior parte dei sistemi, ma se ti imbatti in un caso in cui non dovrebbe essere facile da risolvere perché puoi semplicemente creare una sorta di logica alternativa qui. Diciamo che vuoi consentire a un utente di specificare un percorso personalizzato per i dati delle app in un file di configurazione in seguito, potresti facilmente aggiungere quella logica. Per ora questo dovrebbe essere la maggior parte dei casi per la maggior parte dei sistemi Unix/Linux e Windows Vista e successivi.

Memorizzando nella cartella temporanea del sistema, a seconda del sistema, la cache potrebbe essere persa a intervalli (cron) o al riavvio. L'utilizzo del percorso di installazione globale comporterebbe alcuni problemi. Se è necessario che questi dati siano univoci per progetto, è possibile estendere tale funzionalità per consentire di archiviare questi dati nella radice del progetto, ma non nella radice del modulo. È preferibile non archiviarlo nella root del modulo, anche se è stato appena installato come modulo locale/di progetto, perché l'utente non ha la possibilità di includere questa cartella nei suoi repository senza includere l'intero modulo.

Pertanto, nel caso in cui sia necessario memorizzare i dati memorizzati nella cache relativi a un progetto, è necessario farlo nella radice del progetto, non nello node_modules. Altrimenti memorizzarlo nella directory home dell'utente in modo agnostico di sistema.

Answer 2

Vorrei creare una cartella nascosta nella home directory dell'utente (a partire da un punto). Ad esempio, /home/user/.mymodule/config.cfg. La home directory dell'utente non sta andando da nessuna parte, e il punto si assicurerà che sia fuori dalla sua portata, a meno che non lo cerchino.

Questo è il modo standard in cui la maggior parte dei software memorizza le configurazioni utente, tra cui SSH, Bash, Nano, Wine, Ruby, Gimp e persino NPM stesso.

Answer 3

In primo luogo è necessario sapere in che tipo di SO in esecuzione:

1. La tua idea originale non è male, perché i moduli globali non sono realmente globale in tutti i SO e in tutti ambienti virtuali.
2. L'utilizzo di/home/utente potrebbe non funzionare in Windows. In windows devi controllare process.ENV.HOMEPAHT

Ti consiglio una catena di controlli per determinare il posto migliore.

1. Lascia che l'utente prenda il controllo. Scegli la tua variabile ENV. Supouse MYMOD_HOME. È FIRTS controllare se process.ENV.MYMOD_HOME esiste, e usarlo
2. controllare se le finestre standard di process.ENV.LOCALAPPDATA
3. controllare se le finestre standard di process.ENV.HOMEPATH
4. controllare se è presente '/home/user' o '~'
5. utilizzano Altrimenti __dirname

In tutti i casi creare una directory ./mymodule