Explain why it's not a singleton

[sindresorhus]

It's easy to think that it would make for a simpler API. No need to initialize it first. I thought so too at first.

But imagine if it had been a singleton:

index.js

const config = require('electron-config');
const someComponent = require('./some-component');

config.setDefaults({
  foo: true
});

…

config.get('foo');
//=> true

some-component.js

const config = require('electron-config');

…

config.get('foo');
//=> undefined

Note the undefined. So you would have to be careful about setting the defaults before any app imports, which is easy to forget.

---

The following a much safer and explicit pattern:

config.js

const config = require('electron-config');

module.exports = new Config({
  foo: true
});

index.js

const config = require('./config');
const someComponent = require('./some-component');

…

config.get('foo');
//=> true

some-component.js

const config = require('./config');

…

config.get('foo');
//=> true

---

Thoughts on this?

[feafarot]

I'd agree that it should not be a singleton. The ability to create multiple instances for multiple files is very helpful. Maybe it should be explained somewhere in the docs thou.

[thisismydesign]

@feafarot's explanation makes sense to me.

On another note, not sure about module.exports = new Config() but keep in mind that using ES6 modules export default new Config() is most likely not what you want. It will evaluate a single time during import and won't pick up changes to userData path, for example.