Allow extends

[cosmiconfig]

Allow extends

[azz]

Yep you're totally right. We found a better way.

[davidtheclark]

Once the path of an extending config is found (i.e. one that is being extended), it could be loaded with loadDefinedPath().

One of the challenges will be getting all the async business to work.

[davidtheclark]

This is underway, just needs more tests.

[davidtheclark]

Done, and there are a bunch of tests (though I suppose there could always be more).

[alan-agius4]

Is this implemented? as I cannot find anything

[davidtheclark]

@alan-agius4: No, it's not ... I guess this issue resolved with out clarity. #40 is a followup issue that explains why.

[chrisblossom]

I've released chrisblossom/ex-config to handle the processing and extending of loaded configurations.

[azz]

@davidtheclark Are you open to reconsidering this? I was thinking the API could look like this:

Basic example, will merge extended config with Object.assign

cosmiconfig('my-module', {
  extends: true,
});

Advanced example, pass a custom merge function:

cosmiconfig('my-module', {
  extends: (parent, child) => _.mergeDeep(parent, child),
});

[davidtheclark]

🤔The ESLint RFC I found through the Prettier issue is very interesting. I agree with the premise that ESLint's current configuration complexity should be considered a warning to others, rather than something to emulate. And I really like the idea of demanding a JS file, allowing people to implement their own imports, merges, transforms, etc., rather than trying to appease every developer's desire with configuration-loader magic.

I've looked at a few packages that try to implement generic extends patterns, and they just don't seem generic enough that I want to include them in Cosmiconfig.

I'm not completely opposed to the idea of adding an extends option that always expects a custom merge function as its argument. Thinking through what that means, though ...

1. We look at an extends property in the loaded configuration. (What about those who will want a different property name, or a nested property?)
2. We expect the value of extends to be an array of strings. (What about those who will want to require() modules directly into their extends array?)
3. We resolve all of the strings to corresponding configuration files. (What about those who will want special resolution algorithms, as happened with both ESLint and Babel, the posterchildren of extends?)
4. We recursively use Cosmiconfig to find and load those files.
5. We merge them together with the provided merge function.

Cosmiconfig's value really lies in step 4: the rest is highly likely to vary across implementations, and is fairly straightforward to implement. So I still lean towards not trying to add a generic extends pattern in Cosmiconfig, instead allowing users who want extends, or some extends-like system, to use Cosmiconfig behind the scenes to look up and load files.