Get XDG Base Directory paths (cross-platform)
npm install xdg-portable
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);
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.
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.
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.
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.
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.
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.
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.
Returns a reference-ordered array of base directories to search for configuration files (includes .config()
as the first entry)
Returns a preference-ordered array of base directories to search for data files (includes .data()
as the first entry)
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 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.
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.
This module was forked from sindresorhus/xdg-basedir in order to add cross-platform portability and support simpler cross-platform applications.
git-changelog
... enables changelog automation
npm install
npm test
> npm run help
...
usage: `npm run TARGET [TARGET..]`
TARGETs:
coverage calculate and display (or send) code coverage [alias: 'cov']
fix fix package issues (automated/non-interactive)
fix:lint fix `ESLint` issues
fix:style fix `Prettier` formatting issues
help display help
lint check for package code 'lint'
lint:lint check for code 'lint' (using `ESLint`)
lint:spell check for spelling errors (using `cSpell`)
lint:style check for format imperfections (using `Prettier`)
lint:types check for type declaration errors (using `tsd`)
test test package
test:code test package code
update:changelog update CHANGELOG (using `git changelog ...`)
Contributions are welcome.
Any pull requests should be based off of the default branch (master
). And, whenever possible, please include tests for any new code, ensuring that local (via npm test
) and remote CI testing passes.
By contributing to the project, you are agreeing to provide your contributions under the same license as the project itself.
xdg-app-paths
... easy XDG for applicationsxdg-basedir
... inspiration for this module