Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow operating system config location standards #1276

Closed
Siilwyn opened this issue Apr 9, 2018 · 4 comments
Closed

Follow operating system config location standards #1276

Siilwyn opened this issue Apr 9, 2018 · 4 comments
Labels
triaged: feature request Issue or PR has been reviewed by a maintainer and work is being tracked

Comments

@Siilwyn
Copy link

Siilwyn commented Apr 9, 2018

It would be great if this module followed the XDG Base Directory Specification. Instead of placing the config directory .now in the home directory it should be placed in the OS specific appropriate directory. Getting the correct directory is easy with a module like env-paths. This, among other things, allows a user to specify a directory in which they want all applications to look for their user configurable setting files and keep their home directory clean.

For more context, this long standing issue on Atom contains a lot of replies with people wanting Atom to follow the standards for various reasons.

@leo
Copy link
Contributor

leo commented Nov 13, 2018

This sounds like a very good idea! 👍

We only need to make sure to make it backwards compatible.

@leo leo added the triaged: feature request Issue or PR has been reviewed by a maintainer and work is being tracked label Nov 13, 2018
@Siilwyn
Copy link
Author

Siilwyn commented Nov 13, 2018

Great to see activity again! Guess you were really busy with v2. :)

Maybe of interest for you, my two cents since I've done this for other projects like electron-download, js-v8flags, greenkeeper and node-gyp.

Easiest is making a major breaking change but for user facing config this is a no-go, the now cli falls in this category. There is the option to migrate the config but this can be unexpected behaviour for the user. So the most straightforward way that I would recommend is first reading from the 'old' location and falling back to the new location, documenting this and encouraging users to use the new location.

Code-wise something like this:

const path = require('path');
const envPaths = require('env-paths');
const { existsSync } = require('fs');

const paths = envPaths('now', { suffix: '' });

export function getDataDir(): string {
  return maybePath(getOldPath('data')) || paths.data;
}

export function getCacheDir(): string {
  return maybePath(getOldPath('cache')) || paths.cache;
}

export function getConfigDir(): string {
  return maybePath(getOldPath('config')) || paths.config;
}

function maybePath(path) {
  if(existsSync(path)) {
    return path;
  } else {
    return false;
  }
}

@dsifford
Copy link

Just to add to @Siilwyn's comments (which I agree with). You should also begin writing by default to the new location for all new users. That's key. Stop writing to home entirely for new users (unless explicitly asked to do so).

So, in other words, keep looking in the old location first, but stop writing to the old location if nothing exists there already.

@TooTallNate
Copy link
Member

Closed by #1909.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triaged: feature request Issue or PR has been reviewed by a maintainer and work is being tracked
Projects
None yet
Development

No branches or pull requests

4 participants