Allow extends

An option allowExtends could enable extending.

The model I have in mind is https://github.com/stylelint/stylelint/blob/master/src/postcssPlugin.js#L69. Hopefully we can avoid using require() directly, though, because it is synchronous. Open to other implementation ideas, of course, if they are comparably simple.

Whatever the implementation, key requirements are:

• extend configurations of JSON or YAML format.
• extends accepts a single string or an array of strings.
• extends lookups can be absolute or relative paths, or a node_module name.
• merging of extends occurs in the order of the array, so the last item takes priority over the first item (merges on top of it).

[azz]

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

[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.