Geek Answers Handbook

Where should I store the CLI CLI user module cache?

I am developing an npm module where the user can interact with him through the terminal by executing the commands:

> mymodule init > mymodule do stuff

When certain commands are executed, the user is asked for some data that will be used by the module. Since this data will not really change when using the module, and since these commands can be executed quite often, this is not the best way to ask the user about the data at any time when he runs the command. Therefore, I decided to cache this data, and as soon as it should work through several module calls, the easiest way to save it that I see is a file (the data structure allows you to store it in simple JSON). But I have to be sure where this file should be located on the user machine.

Where in the file system should I store the cache in the form of a file or several files for the npm custom module, given that the module itself can be installed globally on several operating systems and can be used in several projects at the same time?

I thought to store it in the module folder, but it can be difficult in the case of a global installation and the use of several projects. The second idea was to store it in the tmp OS repository, but I'm not quite sure about that. I am also wondering if there are some alternatives to file storage in this case.

+6
source share
3 answers

On some systems, you can cache up to ~/.cache by creating a subdirectory to store your cache data, although it is much more common for applications to create a hidden directory in the users home directory. On modern Windows machines, you can create a directory in C:/Users/someUser/AppData . On Windows using a suffix . will not hide the file. I would recommend you do something like platform agnostic as follows:

 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); }) }

Just declare a function to get the application directory. This should handle most systems, but if you are faced with a situation where it is not, it should be easy to fix, because you can just create some kind of alternative logic here. Suppose you want to allow the user to specify an arbitrary location for application data in the configuration file later, you can easily add this logic. At the moment, this should fit most of your cases for most Unix / Linux and Windows Vista systems and above.

Saving in the temp system folder, depending on the system, your cache may be lost in the interval (cron) or during reboot. Using the global installation path will lead to some problems. If you need this data to be unique for each project, you can expand this functionality so that you can store this data in the root of the project, but not in the root of the module. It is better not to store it in the root of the module, even if it is simply installed as a local / project module, because then the user does not have the opportunity to include this folder in his repositories, not including the entire module.

Therefore, if you need to save the caching data related to the project, you should do this in the root of the project, and not in node_modules . Otherwise, save it in the users home directory in an agnostic way to the system.

+3
source

I would create a hidden folder in the user's home directory (starting from the point). For example, /home/user/.mymodule/config.cfg . The user's home directory will not go anywhere, and the point will ensure that it is out of order if they did not look for it.

This is the standard way in which most programs store user configurations, including SSH, Bash, Nano, Wine, Ruby, Gimp, and even NPM itself.

+6
source

First you need to know what SO you work in:

  • Your original idea is not bad, because global modules are not global in all SOs and in all virtual environments.
  • Using / home / user may not work on Windows. In windows you should check process.ENV.HOMEPAHT

I recommend you a chain of checks to determine the best place.

  • Let the user take control. Choose your own env variable. Supouse MYMOD_HOME. Are you sure that process.ENV.MYMOD_HOME exists and use it
  • Make sure the standard windows process.ENV.LOCALAPPDATA
  • Make sure the standard windows process.ENV.HOMEPATH
  • Check if '/home/user' or '~' exists
  • Otherwise use __dirname

In all cases, create the ./mymodule directory

+4
source

More articles:


All Articles