xdg-portable
Get XDG Base Directory paths (cross-platform)
Installation
npm install xdg-portableUsage
const xdg = require('xdg-portable')
const locatePath = require('locatePath')
const mkdirp = require('mkdirp')
configDir = xdg.config()
//(mac)=> '/Users/rivy/Library/Preferences'
//(nix)=> '/home/rivy/.config'
//(win)=> 'C:\\Users\\rivy\\AppData\\Roaming\\xdg.config'
dataDirs = xdg.dataDirs()
//(mac)=> ['/Users/rivy/Library/Application Support']
//(nix)=> ['/home/rivy/.local/share', '/usr/local/share/', '/usr/share/']
//(win)=> ['C:\\Users\\rivy\\AppData\\Roaming\\xdg.data']
stateDir = xdg.state()
//(mac)=> '/Users/rivy/Library/State'
//(nix)=> '/home/rivy/.local/state'
//(win)=> 'C:\\Users\\rivy\\AppData\\Local\\xdg.state'
mkdirp.sync(configDir, 0o700);
const dataDir = locatePath.sync(dataDirs) || dataDirs[0]
mkdirp.sync(dataDir, 0o700);
mkdirp.sync(stateDir, 0o700);API
Initialization
require('xdg-portable'): XDGPortable()
const xdg = require('xdg-portable')The object returned by the module constructor is an XDGPortable Function object, augmented with attached methods. When called directly (eg, const p = xdg()), it returns a newly constructed XDGPortable object. Since the XDGPortable object contains no instance state, all constructed objects will be functionally identical.
Methods
All module methods return platform-compatible path strings.
The returned paths are simple strings and are not guaranteed to exist. The application is responsible for construction of the directories when needed. If needed, make-dir or mkdirp can be used to create the directories.
xdg.cache(): string
Returns the directory for user-specific non-essential (cached) data files
Deletion of the data contained here might cause the application to slow down.
This location would be analogous to /var/cache for *nix.
%LocalAppData%\xdg.cache is the default for the windows platform.
xdg.config(): string
Returns the directory for user-specific configuration files
Deletion of the data contained here might require the user to reconfigure the application.
This location would be analogous to /etc for *nix.
%AppData%\xdg.config is the default for the windows platform.
xdg.data(): string
Returns the directory for user-specific data files
Deletion of the data contained here might force the user to restore from backups.
This location would be analogous to /usr/share for *nix.
%AppData%\xdg.data is the default for the windows platform.
xdg.runtime(): string?
Returns the directory for user-specific non-essential runtime data files (such as sockets, named pipes, etc); may be undefined
Deletion of the data contained here might interfere with the currently executing application but should have no effect on future executions.
The XDG specification defines some fairly strict specifications for a “runtime”-data candidate directory. To meet these criteria, the directory must usually be supplied by the OS. The user may override this by using the XDG_RUNTIME_DIR environment variable.
undefined is the default for the windows platform.
xdg.state(): string
Returns the directory for user-specific state files (non-essential and more volatile than configuration files)
Deletion of the data contained here should not materially interfere with execution of the application.
This location might hold data such as backups, input history, logs, recent file lists, visual application state, etc.
%LocalAppData%\xdg.state is the default for the windows platform.
xdg.configDirs(): string[]
Returns a reference-ordered array of base directories to search for configuration files (includes .config() as the first entry)
xdg.dataDirs(): string[]
Returns a preference-ordered array of base directories to search for data files (includes .data() as the first entry)
Discussion
The XDG Base Directory Specification defines categories of user information (ie, “cache”, “config”, “data”, …), defines their standard storage locations, and defines the standard process for user configuration of those locations (using XDG_CACHE_HOME, etc).
Applications supporting the XDG convention are expected to store user-specific files within these locations, either within the common/shared directory (eg, `${xdg.cache()}/filename`) or within a more isolated application-defined subdirectory (eg, `${xdg.config()}/dir/filename`; dir usually being the application name).
Windows (“win32”) specific notes
Windows has an alternate convention, offering just two standard locations for applications to persist data, either %APPDATA% (for files which may “roam” with the user between hosts) and %LOCALAPPDATA% (for local-machine-only files). All application files are expected to be stored within an application-unique subdirectory in one of those two locations, usually under a directory matching the application name. There is no further popular convention used to segregate the file types (ie, into “cache”, “config”, …) in any way similar to the XDG specification.
So, to support basic XDG-like behavior (that is, segregating the information types into type-specific directories), this module creates a new convention for Windows hosts, placing the specific types of files into subdirectories under either %APPDATA% or %LOCALAPPDATA%, as appropriate for the file type. For example, “cache”-type files will be offered placement into %LOCALAPPDATA%\xdg.cache, “config”-type files into %APPDATA%\xdg.config, “data”-type files into %APPDATA%\xdg.data, etc.
xdg-app-paths builds on this module and offers application specific paths more in-line with usual platform conventions, but still compatible with the XDG specification.
Fallback to os.tmpdir()
In the uncommon case that both the XDG environment variable is not set and the users home directory can’t be found, os.tmpdir() will be used as a fallback for the missing os.homedir() value.
Origins
This module was forked from sindresorhus/xdg-basedir in order to add cross-platform portability and support simpler cross-platform applications.
Related
xdg-app-paths… easy XDG for applicationsxdg-basedir… inspiration for this module
License
MIT © Roy Ivy III, Sindre Sorhus