Features of configuration loader

[cosmiconfig]

Features of configuration loader

[davidtheclark]

I think that each of the items you've listed are about resolving paths/modules. If cosmiconfig were able to serve each of these projects, I'm thinking it's role would end after resolving those items to absolute paths — then the consumer would decide what to do with those paths.

So the question here is whether the format of these configuration properties and the the means of resolution can be common enough between the projects to justify a shared tool.

I'll detail what stylelint (and stylefmt) does for comparison (cc @jeddy3 if I've made mistakes):

• plugins is an array of string locators or a single string locator. Each locator is either
  • The name of a module in local node_modules* (have not built in the ability to load global node_modules`, though it's been asked for.
  • An absolute path
  • A relative path, relative to the referencing configuration file — or, if that fails, relative to process.cwd()
• extends is the same as plugins.
• ignoreFiles is an array of globs or a single glob. If the globs are relative, we attempt to resolve them relative to the referencing configuration file, and if that fails we try to resolve them relative to process.cwd().

Stylelint has the special situation that you configure a loaded plugin via "rules". Other tools might not have this, so they may need to be able to accept configuration objects alongside lookups in the plugins array.

[azu]

I think that there are anthor issue.
Babel and ESLint synchronously load config.
If these project use cosmiconfig, there are breaking change.

[davidtheclark]

I don't think this in issue for cosmiconfig. If you'd like to open issues in other projects discussing this possibility, I think that would be more productive..