Recommendations / recommendations on custom node.js CLI tool configuration files: location & naming?

Question

I will try to keep this question short, but it consists of two parts:

• Where should the configuration files for nodejs / npm CLI tools be saved?
• What should they call?

Let's say I'm writing a CLI node.js tool that, for example, captures the weather today and displays it in the terminal. I call it weather-getter . Please note: the main goal is not to be called programmatically, but is entered into the terminal as BASH. It is designed to run by typing its simple name after installation around the world, or through a directory in the local / bin user. (Sudo is not required to install it.)

This project will install normally through npm. It can receive zipcode through an argument, for example:

 gavin@localhost :~$ weather-getter -z "12345" 

OK, the program works fine. The next step would be to allow the user to save the configuration file somewhere and pull the default configuration from this file. Like the .vimrc file. This configuration might look like this:

 { "zipcode": "12345", "language": "en", "unit": "fahrenheit" } 

I suppose it should start from a point. I also suggest that it should be located in the npm module, and not in ~ /. Or should I use ~ / or / etc / or ~ / .config or ~ / .local, like so many other programs? Should node programs try to use a shared directory, for example ~ / .config / node / or ~ / .config / npm /? And if the file is there, should it start without a dot?

Note. My question is not in reading / writing a file with node.js, but only in recommendations for configuration location and naming. Thanks!

Answer 1

Since this is a common CLI application (which is only implemented in Node.js this way) installed in the system path, you should follow the recommendations or rules set for the target operating system.

Unix / Linux / OS X similar

In order of priority, they will be (but not limited to):

• ~ (user's home folder) - many programs save the user level configuration in their home directory, usually in a file with a comma prefix, followed by the name of the application (or the like) - i.e. ~/.weather-getter

• /usr/local/etc , /etc - configuration files at the system level. They should, as a rule, apply to all users of the system and, therefore, should have a lower priority than the settings in the home folder. The difference between the two routes etc usually is that the former is used for user-installed programs, while the latter is intended for the system level (this is especially true for Mac users using Homebrew ). This difference, however, is not always respected, and therefore both places should be checked for configuration files (preferably if the /etc directory has lower priority).

• Your application root - this should be the default settings for your application, backups when the user or system config is not found.

• Other locations may be considered if necessary.

Window

This is usually somewhere in the %APPDATA% directory if your application allows you to use the GUI or at least CLI configuration management or the Windows registry (using winreg , for example). I personally have little experience developing Windows / CLI, so I welcome further comments or answers on this topic. I believe that using the user's home folder will also be acceptable if the file can be marked as hidden (therefore it does not clutter the view).

Some general considerations

• Many CLI applications set their default configurations to one of the mentioned locations, so the user has a good starting point when setting up your application.
• How your configuration parameters are processed when there are several configuration files (are they combined in some order? Is only one of them used? Which one has priority?) Is completely up to you, but you should clearly indicate your documentation, maybe even mention it in the configuration files themselves.
• If your application requires multiple configuration files, it is preferable that they be grouped into their own folder.

Dotfiles update

The reason some files or folders are prefixed with a dot is to hide them from the normal view of users (i.e. when viewing their home directory via a graphical interface). Therefore, it is common practice to use fixed-point file / folder names when storing configuration files in directories where users usually work, but do not do this when storing configuration files in system-level folders.