Save config under each app's own namespace

[hackergrrl]

The current behaviour is to save some package package-name under

~/.config/configstore/package-name

This means every app using configstore has its configuration file saved under the configstore namespace, rather than under that app's own namespace. This approach goes against the usual config convention (~/.config/package-name). There are some drawbacks to going against this convention:

1. Dependents migrating to or from configstore becomes harder.
2. A user or program wanting to read/write the config file will need to know the app uses configstore in order to find it.

Dropping the configstore prefix addresses these, though it also means introducing backwards incompatibility with existing configstore users. Some ideas:

1. Embrace semver! Increment the major version and break compatibility without fear.
2. Have the API methods check both locations: configstore/package-name.json and package-name/config.json. This keeps compatibility, but makes logic more complicated. (What do you do if you find data in both locations?)
3. Provide a constructor flag for choosing whether to save in the current style, or the above style. Conservatively default to the current behaviour.
4. Worst solution: fork a new project that uses the above pathing pattern. This avoids breaking compatibility entirely.

[sindresorhus]

It's intentional. By having it under the configstore namespace, we ensure that there will never be any conflict, as package names are unique on npm. Having it directly under ~/.config makes it a target for conflict with any other ecosystem. I didn't want my users potentially having to deal with that.

This approach goes against the usual config convention (~/.config/package-name).

Proof please. Very few tools even use ~/.config. Most just throws it in $HOME.

Dependents migrating to or from configstore becomes harder.

Never heard of anyone migrating to configstore. Sounds like an edge-case.

A user or program wanting to read/write the config file will need to know the app uses configstore in order to find it.

From experience, most users don't even know about ~/.config. Configstore exposes the path to the configfile, so implementors are free to somehow expose it to users if they prefer: https://github.com/yeoman/configstore#path

[hackergrrl]

It's intentional. By having it under the configstore namespace, we ensure that there will never be any conflict, as package names are unique on npm. Having it directly under ~/.config makes it a target for conflict with any other ecosystem. I didn't want my users potentially having to deal with that.

That makes sense: that's a strong benefit for configstore clients that's in line with the project's tagline of "store config and don't worry about it".

Are you open to compromising and providing a constructor option to specify a config path? I really like configstore's API, but I'd like my CLI programs' configs to be first-class unix ecosystem citizens.

[sindresorhus]

Sure. PR welcome. Should be an options object in case of more options in the future.

[sindresorhus]

Fixed by #28.