
Research
Security News
Malicious PyPI Package Exploits Deezer API for Coordinated Music Piracy
Socket researchers uncovered a malicious PyPI package exploiting Deezer’s API to enable coordinated music piracy through API abuse and C2 server control.
xdg-portable
Advanced tools
Determine XDG Base Directory paths (OS/platform portable)
npm install xdg-portable
# or... `npm install "git:github.com/rivy/js.xdg-portable"`
# or... `npm install "git:github.com/rivy/js.xdg-portable#v9.0.0"`
# or... `npm install "https://cdn.jsdelivr.net/gh/rivy/js.xdg-portable/dist/xdg-portable.tgz"`
const xdg = require('xdg-portable/cjs');
const configDirs = xdg.configDirs();
const stateDir = xdg.state();
const locatePath = require('locatePath');
const mkdirp = require('mkdirp');
const configDir = locatePath.sync(configDirs) || configDirs[0];
mkdirp.sync(configDir, 0o700);
mkdirp.sync(stateDir, 0o700);
import xdg from 'xdg-portable';
const configDirs = xdg.configDirs();
//...
import xdg from 'https://deno.land/x/xdg/src/mod.deno.ts';
//or...
//import xdg from 'https://deno.land/x/xdg@v9.0.0/src/mod.deno.ts';
//or (via CDN, with optional version/version-range/latest/commit support)...
//import xdg from 'https://cdn.jsdelivr.net/gh/rivy/js.xdg-portable@9.0.0/src/mod.deno.ts'; // v9.0.0
//import xdg from 'https://cdn.jsdelivr.net/gh/rivy/js.xdg-portable@9/src/mod.deno.ts'; // v9.x.y
//import xdg from 'https://cdn.jsdelivr.net/gh/rivy/js.xdg-portable/src/mod.deno.ts'; // latest
//import xdg from 'https://cdn.jsdelivr.net/gh/rivy/js.xdg-portable@latest/src/mod.deno.ts'; // latest
//import xdg from 'https://cdn.jsdelivr.net/gh/rivy/js.xdg-portable@COMMIT/src/mod.deno.ts'; // commit
const configDirs = xdg.configDirs();
//...
--allow-env
· allow access to the process environment variablesThis module/package requires access to various environment variable to determine platform and user configuration (eg, XDG configuration variables, location of temp and user directories, ...).
XDG()
const xdg = require('xdg-portable/cjs'); // CJS
//or...
//import xdg from 'xdg-portable'; // ESM/TypeScript
//import xdg from 'https://deno.land/x/xdg/src/mod.deno.ts'; // Deno
When importing this module, the object returned is a function object, XDG
, augmented with attached methods. Additional XDG
objects may be constructed by direct call of the imported XDG
object (eg, const x = xdg()
) or by using new
(eg, const x = new xdg()
). Notably, since the XDG
object contains no user-facing instance state, all XDG
objects will be functionally identical.
XDG
~ primary module function objectTypes named here are exported individually by name (eg, as "XDG").
import type { XDG } from 'xdg-portable'; // TypeScript
//or...
//import type { XDG } from 'https://deno.land/x/xdg/src/mod.deno.ts'; // Deno
All module methods return platform-compatible path strings which are normalized and have no trailing path separators.
The returned paths and are not guaranteed to exist on the file system. So, the user application is responsible for directory construction, if/when needed. If needed, make-dir
or mkdirp
can be used to create the directories.
xdg.cache(): string
Deletion of the data contained here might cause an application to slow down.
const cacheDir = xdg.cache();
//(mac)=> '/Users/rivy/Library/Caches'
//(nix)=> '/home/rivy/.cache'
//(win)=> 'C:\\Users\\rivy\\AppData\\Local\\xdg.cache'
This directory location would be analogous to /var/cache for *nix.
%LocalAppData%\xdg.cache
is the default for the windows platform.
xdg.config(): string
Deletion of the data contained here might require the user to reconfigure an application.
const configDir = xdg.config();
//(mac)=> '/Users/rivy/Library/Preferences'
//(nix)=> '/home/rivy/.config'
//(win)=> 'C:\\Users\\rivy\\AppData\\Roaming\\xdg.config'
This directory location would be analogous to /etc for *nix.
%AppData%\xdg.config
is the default for the windows platform.
xdg.data(): string
Deletion of the data contained here might force the user to restore from backups.
const dataDir = xdg.data();
//(mac)=> '/Users/rivy/Library/Application Support'
//(nix)=> '/home/rivy/.local/share'
//(win)=> 'C:\\Users\\rivy\\AppData\\Roaming\\xdg.data'
This directory location would be analogous to /usr/share for *nix.
%AppData%\xdg.data
is the default for the windows platform.
xdg.runtime(): string?
undefined
.Deletion of the data contained here might interfere with a currently executing application but should have no effect on future executions.
const runtimeDir = xdg.runtime();
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
Deletion of the data contained here should not materially interfere with execution of an application.
const stateDir = xdg.state();
//(mac)=> '/Users/rivy/Library/State'
//(nix)=> '/home/rivy/.local/state'
//(win)=> 'C:\\Users\\rivy\\AppData\\Local\\xdg.state'
This directory 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(): readonly string[]
xdg.config()
directory as first entry).const configDirs = xdg.configDirs();
//(mac)=> [ '/Users/rivy/Library/Preferences', ... ]
//(nix)=> [ '/home/rivy/.config', ... ]
//(win)=> [ 'C:\\Users\\rivy\\AppData\\Roaming\\xdg.config' , ... ]
xdg.dataDirs(): readonly string[]
xdg.data()
directory as first entry).const dataDirs = xdg.dataDirs();
//(mac)=> [ '/Users/rivy/Library/Application Support', ... ]
//(nix)=> [ '/home/rivy/.local/share', ... ]
//(win)=> [ 'C:\\Users\\rivy\\AppData\\Roaming\\xdg.share' , ... ]
Requirements
NodeJS >= 4.01
*.js
and *.cjs
)CJS is the basic supported output (with support for NodeJS versions as early as NodeJS-v4).
const xdg = require('xdg-portable/cjs');
console.log(xdg.config());
Note: for CJS,
require('xdg-portable')
is supported for backward-compatibility and will execute correctly at run-time. However,require('xdg-portable')
links to the default package type declarations which, though correct for ESM or TypeScript, are incorrect for CJS. This, then, leads to incorrect analysis of CJS files by static analysis tools such as TypeScript and Intellisense.Using
require('xdg-portable/cjs')
is preferred as it associates the proper CJS type declarations and provides correct information to static analysis tools.
*.mjs
)v8.0
+.XDG
fully supports ESM imports.
import xdg from 'xdg-portable';
console.log(xdg.config());
*.ts
)v8.0
+.As of v8.0
+, XDG
has been converted to a TypeScript-based module.
As a consequence, TypeScript type definitions are automatically generated, bundled, and exported by the module.
v9.0
+.XDG
also fully supports use by Deno.
import xdg from 'https://deno.land/x/xdg/src/mod.deno.ts';
console.log(xdg.config());
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 determined, the temporary directory (OS/platform specific; determined by temp()
from os-paths) will be used as a fallback for the missing home directory value.
This module was forked from sindresorhus/xdg-basedir in order to add cross-platform portability and support simpler cross-platform applications.
optional
git-changelog
(v1.1+) ... enables changelog automation
npm install-test
> npm run help
...
usage: `npm run TARGET` or `npx run-s TARGET [TARGET..]`
TARGETs:
build build/compile package
clean remove build artifacts
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:commits check for commit flaws (using `commitlint` and `cspell`)
lint:editorconfig check for EditorConfig format flaws (using `editorconfig-checker`)
lint:lint check for code 'lint' (using `eslint`)
lint:markdown check for markdown errors (using `remark`)
lint:spell check for spelling errors (using `cspell`)
lint:style check for format imperfections (using `prettier`)
realclean remove all generated files
rebuild clean and (re-)build project
retest clean and (re-)test project
reset:hard remove *all* generated files and reinstall dependencies
show:deps show package dependencies
test test package
test:code test package code
test:types test for type declaration errors (using `tsd`)
update update/prepare for distribution [alias: 'dist']
update:changelog update CHANGELOG (using `git changelog ...`)
update:dist update distribution content
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.
os-paths
... portable common OS/platform paths (home, temp, ...)xdg-app-paths
... easy XDG for applicationsxdg-basedir
... inspiration for this moduleWith the conversion to a TypeScript-based project, due to tooling constraints, building and testing are more difficult and more limited on Node platforms earlier than NodeJS-v10. However, the generated CommonJS/UMD project code is fully tested (for NodeJS-v10+) and continues to be compatible with NodeJS-v4+. ↩
FAQs
Determine XDG Base Directory paths (OS/platform portable)
The npm package xdg-portable receives a total of 608,330 weekly downloads. As such, xdg-portable popularity was classified as popular.
We found that xdg-portable demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncovered a malicious PyPI package exploiting Deezer’s API to enable coordinated music piracy through API abuse and C2 server control.
Research
The Socket Research Team discovered a malicious npm package, '@ton-wallet/create', stealing cryptocurrency wallet keys from developers and users in the TON ecosystem.
Security News
Newly introduced telemetry in devenv 1.4 sparked a backlash over privacy concerns, leading to the removal of its AI-powered feature after strong community pushback.