Is there a proper, cross-platform way to check if the config file already exists?

Hi there, I'm trying to use the lib within a electron project but I get this error:

Uncaught Exception:
TypeError: Cannot set property 'path' of undefined
    at Configstore (/Users/icke/Documents/frntl/frontal/app/node_modules/configstore/index.js:26:12)

Where can this come from?

I boiled it down to this gist https://gist.github.com/fabiantheblind/c557f3dcccf135b9ae441ed200f22e55

For testing purposes it'd be nice if I could edit my config without it saving to disk since other tests may need different configs and since there's only one file used race issues may happen.

Currently configstore creates files that are globally readable. They should instead be readable by the owner only by default. This allows you to store things like credentials securely.

It shouldn't be up to the package whether to store in ~/.config/configstore/ or in ~/.config/<pkgname>/, it should be up to the user.

Better: respect the XDG base directory specification, or do that and further add $<PKGNAME>_HOME env var option.

I came to this repo wondering where the hell ~/.config/configstore came from, because I haven't installed any 'configstore'. As #27 says, having some random secondary bucket for a select bunch of different program/package's configs is unconventional.

Hi, I'd like to congratulate you for the amazing work you've done with this package. It's been great. However, I've got a problem when I update the default configuration in the ConfigStore declaration and release it to npm. Users who have an older version of my package don't get their local config-store delete under ~/.config/configstore. Should I do this in the bootstrap of my package and save the version in the config itself? If the version is older do something like config.clear().

Thanks in advance

Noticed this in an output @addyosmani shared.

/usr/local/lib/node_modules/bower/node_modules/update-notifier/node_modules/configstore/configstore.js:83
    return this.all[key];
                   ^
TypeError: Cannot read property 'update' of null
    at Object.Configstore.get (/usr/local/lib/node_modules/bower/node_modules/update-notifier/node_modules/configstore/configstore.js:83:17)
    at UpdateNotifier.check (/usr/local/lib/node_modules/bower/node_modules/update-notifier/lib/update-notifier.js:51:28)
    at module.exports (/usr/local/lib/node_modules/bower/node_modules/update-notifier/lib/update-notifier.js:142:17)
    at Object.<anonymous> (/usr/local/lib/node_modules/bower/bin/bower:132:12)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)

I'm super interested in testing this out, I'm sure there are some great uses for this with Grunt and Yeoman, so I'l probably just play around and see what I come up with anyway... but before I do I wanted to see if there were ideas floating around already. Anything you've wanted to do but haven't had the time?

I'm using configstore to store some non-essential information in one of my projects. The other day one of our testers got a one time exception on Windows (seems to come from writeFileAutomic trying to rename the file).
The exception is unacceptable, especially since the information there is really non-essential and it's not the end of the world if it fails from time to time.
Are you open to accepting a PR that adds an option to not throw exceptions?
When the option is set, we could save the serialized errors to an array, so the developer could still get to them (e.g. on close if there is more than 1 error, report to the server).

Thanks for the XDG_CONFIG_HOME variable. It helped me by using it in Lambda Functions. Just in case someone struggles with it.

I'm trying to run a yeoman generator and I'm facing this error:

"TypeError: Object # has no method tmpdir" inside configstore.js

I'm not sure about it, but maybe you need to update your code with this fix sindresorhus/tempfile#4

I'm thinking of adding an option to specify the root folder in the ctor arguments.
Right now it's hardcoded to 'configstore'.

What do you think?

Im using this module in a react app and when trying to bundle the code with webpack in production mode I get an error due to this line:

const defaultPathMode = 0o0700;

with the text Invalid syntax. Should the value be a string (surrounded by quotes)?

Every time I run my code, it wipes out the previous config and resets to a blank file with just {}. Looking at the code, this seems to be by design if no defaults are put in. If I put something in default, it writes that instead each time. However, I want my config to persist, such that I can call it up, load some values, change some, close it, and when I rerun my code, it'll pull from that saved config file. It's a bit hard to explain. With my method, I can handwrite the json file if I wanted to.

This seems to be fixed by commenting out line 28:
//this.all = assign({}, defaults || {}, this.all || {});

With this line commented out, it loads whatever I have in my config.json file and works great

Just wondering if this is by design, or if we can have an ExistingFile flag to ignore the initialize with {} part

everything that can go wrong will go wrong

There are of course environments where $HOME is not set: bower/bower#558

Is there any way we can gracefully fallback to something else? Maybe a hidden local folder? (it needs to be persistent, so can't use /tmp).

@satazor @passy @stephenplusplus

I'm using CIDRs as config keys, and it makes less sense to use dotProp to set / get. I toyed with adding an option to specify whether to use dotProp or not, but in the end it was easier to add 2 new methods and use those to store plain strings with dots in the keys:

Configstore.prototype.setPlain = function (key, val) {
    var config = this.all;
    if (arguments.length === 1) {
        Object.keys(key).forEach(function (k) {
            config[k] = key[k];
        });
    } else {
        config[key] = val;
    }
    this.all = config;
};

and its counterpart:

Configstore.prototype.getPlain = function (key) {
    return this.all[key];
};

Might be useful to someone. I'm newish to github - should I fork the project, make the change and then create a pull request? Seems a lot of admin for 2 simple additions, but let me know..

Tx

It's been a while since the last version was published. Since then, a change has been introduced where del has been renamed to delete. The readme reflects this, but the latest version actually published on npm doesn't have the delete method. This is confusing.

Could we get a 2.0.1? :-)

Hello,

is it possible to extend the config.set() (and maybe config.get() as well) to allow more than one level of nesting?

My problem is that my config file looks similar to this:

{
  "foo": {
    "bar": true,
    "baz": "yes"
  },
  "something": {
    "different": false
  }
}

and I want to be able to set config.set('foo.bar', false);.

Otherwise I would've to split the JSON up into smaller pieces and that would become really messy after a while 😥

Edit: I could also send a PR if extending the method is fine?

Cheers,
Moritz

Is there any similar tool or convention for saving cached data instead of configuration?

For example, in a CLI that sometimes downloads stuff from the internet in response to user input... is there any standard location for caching downloaded things to speed up the next run? Or is the convention just to put them in a new hidden folder in the root of the home dir?

I'm looking into ways to reduce the footprint from all dependencies to try and reduce the overall size.
One of them i looked into was if unique-string was really needed.

After reading up on some natives way of solving this problem i found this nice article that solves it in a very straight forward way:
https://advancedweb.hu/secure-tempfiles-in-nodejs-without-dependencies/

mkdtemp handles randomness and uniqueness without collision

import fs from 'fs'
import os from 'os'
import path from 'path'
// import uniqueString from 'unique-string';

// const configDirectory = xdgConfig || path.join(os.tmpdir(), uniqueString()); 
const configDirectory = xdgConfig || fs.mkdtempSync(fs.realpathSync(os.tmpdir()) + path.sep);

I'm not sure if you have control over the npm package at https://www.npmjs.com/package/configstore , but it's currently out of date with a last-published date of about 4 months ago. (Most notably it doesn't have the "has" function, which is how I noticed.)

It's connected with yeoman/insight#22

Configstore doesn't lock config storage before writing to it. It can result in invalid YAML when instantiating configstore in different processes concurrently.

If configstore encounters invalid YAML, it cleans the store, resulting in yeoman/insight#22

The solution is to use file lock around any filesystem call (mkdir, write, read).

We have an electron app that uses configstore and one user reported this error:

Error: EACCES: permission denied, rename '/Users/customeruser/.config/configstore/myapp.json.4047768619' -> /Users/customeruser/.config/configstore/myapp.json'

You don't have access to this file.

It appears on osx in multiple computers/users on app launch.

Any idea on what can cause this?

I've asked the user to run a chown but I don't understand what changed the permissions in that folder. Any idea on why this happens?

Please update graceful-fs to v4 for node 6.0.0 compatibility.

In version 0.2.1 new Configstore object removes all values from file and writes {} there.
In 0.2.0 all fine.

How to set it to the same path as the electron-store

I noticed that configstore creates the directory and file on read.

Would you be interested in adding an option that allowed for file creation at write time if it doesn't exist?

I had some user complaining about files being written when they hadn't made any changes.

I wrote a similar module some time ago. Later I extracted just the path-constructing part into a separate library. I think it could benefit this module.

LinusU/node-application-config-path

It just exposes one function which takes a name and gives a path, this in accordance with the table below.

Sounds interesting?

Appreciate the note about the breaking change in 1.x -- do you have a recommended upgrade path for moving towards 1.x and above? Is it just a matter of digging up the existing yaml file and converting it to json?

Just curious if you have a recommended way to upgrade, since it seems like it shouldn't be too tough and I'm sure people want to do it 😀

What parameters are needed to set the path to electron-sotre

Node.js 10 LTS introduced recursive fs.mkdirSync so that we can drop make-dir from dependencies.
https://nodejs.org/dist/latest-v10.x/docs/api/fs.html#fs_fs_mkdirsync_path_options

If it is fine, I will open a pull request to drop make-dir.

internal/modules/cjs/loader.js:1085
      throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
      ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /mnt/e/crypto-command-line/node_modules/configstore/index.js
require() of ES modules is not supported.
require() of /mnt/e/crypto-command-line/node_modules/configstore/index.js from /mnt/e/crypto-command-line/lib/KeyManager.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /mnt/e/crypto-command-line/node_modules/configstore/package.json.

    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1085:13)
    at Module.load (internal/modules/cjs/loader.js:933:32)
    at Function.Module._load (internal/modules/cjs/loader.js:774:14)
    at Module.require (internal/modules/cjs/loader.js:957:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/mnt/e/crypto-command-line/lib/KeyManager.js:1:21)
    at Module._compile (internal/modules/cjs/loader.js:1068:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10)
    at Module.load (internal/modules/cjs/loader.js:933:32)
    at Function.Module._load (internal/modules/cjs/loader.js:774:14) {
  code: 'ERR_REQUIRE_ESM'

This is the error I am getting

Building an Electron app, and using configstore to persist small bits of data. Wondering if this will work when the app auto-updates.

nodejs have built in recursive mkdir...

Some users may have different opinion on where configstore should store the data. For example, using C:\Users\<name>\.config on Windows is unconventional and not really common, nor recommended (actually, it's an anti-pattern that only Linux tools use).

No matter the reason, the user may want to store the config somewhere else (my usecase is for portable packaging of Node.js, where I want it to store everything in a custom directory). Imo, configstore should support an environment variable like CONFIGSTORE_DIR and store the config elsewhere if it is set.

patrikx3@bitang:~$ /snap/bin/p3x-onenote 
A JavaScript error occurred in the main process
Uncaught Exception:
Error: EPERM: operation not permitted, chown '/home/patrikx3/snap/p3x-onenote/21/.config/configstore/p3x-onenote.json.994378042'
    at Object.chownSync (fs.js:1064:3)
    at Function.writeFileSync [as sync] (/snap/p3x-onenote/21/resources/app.asar/node_modules/write-file-atomic/index.js:196:27)
    at Configstore.set all [as all] (/snap/p3x-onenote/21/resources/app.asar/node_modules/configstore/index.js:61:20)
    at Configstore.set (/snap/p3x-onenote/21/resources/app.asar/node_modules/configstore/index.js:91:12)
    at Object.<anonymous> (/snap/p3x-onenote/21/resources/app.asar/src/electron/app.js:56:10)
    at Object.<anonymous> (/snap/p3x-onenote/21/resources/app.asar/src/electron/app.js:111:3)
    at Module._compile (internal/modules/cjs/loader.js:693:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:704:10)
    at Module.load (internal/modules/cjs/loader.js:602:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:541:12)
/usr/share/libdrm/amdgpu.ids: No such file or directory

When I revert to configstore v4 and install on SNAP it works 100%.
With v5 it tries to chown a file, that is not permitted on SNAP.

Let's say I have a json file
{
"items":[
{"name":"abc","size":1},
{"name":"abcd","size":2},
]
}
How can I add a new item to the items array?

Thanks
Jeff

In our attempt to make everything more userfriendly we should try to help the user out more if it encounters an permission error. I've seen many of these in the wild and there isn't a lot of documentation on how to fix if you don't know about chown/chmod.

We need to come up with a good error message on how they can fix the problem. Do you know any good guides we can link to? According to passy it could either be solved with chown or chmod, but in Windows I have like no idea. The text also needs to be easily understandable. This is not just for this module as we can reuse it.

You don't seem to have access to this file. This is unfortunately you, not me, so no need to open a ticket. You can fix it by doing...

@passy @stephenplusplus @btford @addyosmani

var Configstore = require('configstore');
var pkg = require(__dirname + '/package.json');
var conf = new Configstore(pkg.name);

if(conf.has('keyName')) {
    console.log(true);
}

When I try and use conf.has('keyName') I get an Uncaught TypeError: conf.has is not a function.
The docs on npm do not show the .has function but it does apear on the readme.md on github.

EDIT: npm does not contain the version with .has and renamed .del function.

I have searched the doc but not found a clear answer to this. Apologies if I missed anything.
Is there a 'clean' method to determine the existence of a configstore file?
Currently a new configstore file is created if it doesn't exist. Ideally I would like to check for the presence of a configstore that is expected to be present.

Thanks

The latest version use ES module import statement in index.js file of the module

import path from 'path' etc.

which is throwing error in normal node js application using common js imports - require('configstore')

Error :

configstore version: 6.0.0
nodejs version: 16.13.0
typescript version: 4.5.2

Error:
require() of ES Module /path/node_modules/configstore/index.js from /path/dist/lib/Key.js not supported.
Instead change the require of index.js in /path/dist/lib/Key.js to a dynamic import() which is available in all CommonJS modules.

I tried changing module and target in tsconfig and added type="module" in package.json but it didin't help

v3.1.3, just released, has started breaking our Node 6 CI server builds.

This is because node 6 comes bundled with npm 3.10.10, and npm 3 does not support package aliasing in dependencies ("npm:dot-prop-legacy@^4.2.1")

The package aliasing feature was only added in npm v6.9.0 (https://npm.community/t/release-npm-6-9-0/5911)

EDIT: I see it is breaking your CI builds for configstore on Node 4 + Node 6 too (https://travis-ci.org/github/yeoman/configstore/builds/717961663)

Hi there,

I just installed configstore 2.0.0 from NPM and it does not have has() method.
I suspect new version was not published to npm yet?

Hello there, would it be possible to cut a release including the fix for CVE-2020-8116?

It doesn't seem like there's a changelog anywhere, so I can't be sure if things will break or what has changed when I update the version 😕

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.

I like the YAML syntax, but it's not as well known as JSON and comes with a lot of baggage.

It would be nice to have events like .on('set', cb) in case behaviour of the whole system should be updated. If such change is desirable by community, I would love to make a PR with it.

I am still using the 0.3.x line because of this issue, and getting the graceful-fs warning on node 6. Any chance of a patch update?