Give back some power to the end users

[d-fischer]

This change intends to make configuration more configurable for the end users, to suit the end user's project structure rather than the structures that (possibly multiple different) tooling maintainers imagined.

Examples

With a file named .config.yml in your project root with the following contents:

cosmiconfig:
  searchPlaces:
    - .config/{name}.yml

and given that you're using stylelint and prettier (with both using a version of cosmiconfig that supports this), cosmiconfig will only look at the file .config/stylelint.yml and .config/prettier.yml.

The same should work from a package.json "cosmiconfig" key.

An additional feature I plan to add here is to be able to put configuration for cosmiconfig consumers directly into this file, a little bit like it works now in package.json (#261):

cosmiconfig:
  searchPlaces:
    - .config/{name}.yml
  searchInThisFile: true # bikeshedding proposals encouraged

prettier:
  printWidth: 80

This was in a previous local version of mine, but I decided to remove it, because the general approach seemed too shaky to me, but I intend to try again.

To do

• Enable user to specify explorer options within package.json using a cosmiconfig key
• Enable user to specify explorer options in a .config.{yml,yaml,json,js,cjs} file using a cosmiconfig key
• Enable user to put all configuration in said file
• Optional: figure out a way to specify loaders from non-JS files (could also offload this to a new issue to implement later, but then we should probably throw for now when someone tries to specify the loaders key in a non-JS file)
  • Figure out a way to configure loaders from meta config #290
• Fix existing tests to not spy on reading this early stage
• Create new tests (get coverage back to 100%)
• Add documentation to README
• Add short summary to CHANGELOG

Fixes #261

This is intended to be in a minor update, so there should be no breaking changes.

Please add your thoughts to this, I appreciate any feedback 🙂

[fisker]

This approach seems bad to me.

1. It seems we can't config cosmiconfig for different tools.

   For example, I want Prettier look for prettier.config.mjs and stylelint look for stylelint.config.cjs, can it be done? At least, not clear to me how to do it.

2. The new behavior seems not able to opt-out.

   I don't want to allow user override searchPlaces.

Maybe I was wrong?

[d-fischer]

1. It seems we can't config cosmiconfig for different tools.

   For example, I want Prettier look for prettier.config.mjs and stylelint look for stylelint.config.cjs, can it be done? At least, not clear to me how to do it.

Just configure both extensions. searchPlaces is still an array as usual. (I thought the placeholder was described clearly enough.)

2. The new behavior seems not able to opt-out.

I don't want to allow user override searchPlaces.

Why would you deliberately want to say that your library/tool doesn't want to adhere to the end user's naming conventions? This is a strict improvement for end users and I don't see why consumers would have to have any say in this.

[d-fischer]

Maybe the first point wasn't actually made clear enough in the library. The {name} in the example isn't some kind of documentation placeholder, but it's a real "variable" that will be replaced by the consumer's name (the first argument to cosmiconfig()) at runtime.

[fisker]

Why would you deliberately want to say that your library/tool doesn't want to adhere to the end user's naming conventions?

If Prettier want support this, shouldn't this enough?

const {config: {searchPlaces}} = cosmiconfig("cosmiconfig").search()
const {config: prettierConfig} = cosmiconfig("prettier", {searchPlaces}).search()

No one requested it, why would we make things complicate?

[d-fischer]

Why would you deliberately want to say that your library/tool doesn't want to adhere to the end user's naming conventions?

If Prettier want support this, shouldn't this enough?

const {config: {searchPlaces}} = cosmiconfig("cosmiconfig").search()
const {config: prettierConfig} = cosmiconfig("prettier", {searchPlaces}).search()

So you propose that every single tool maintainer wanting to support this needs to copy and paste a snippet of code into their own code base, which pretends they are cosmiconfig? That's the whole point of a library completely taken apart. After a while, there would be subtle incompatibilities, not to mention that many (like you, apparently) don't even realize the problem that this solves, and in turn, probably won't include it. After all, no one made this before now, and no one requested it either, which is the perfect segue to your next question:

No one requested it, why would we make things complicate?

The problem is that tooling maintainers are usually living inside their own bubble. Yes, no tooling maintainer may have requested this, but I've heard a bunch of voices saying that their application, which uses a bunch of tools that have config files, all put these config files into the root of the project, which becomes annoying quickly. The addition of the .config subdirectory into the default searchPlaces was the first step towards improving this, but more steps are necessary for a complete solution, and this isn't even the last one. After all, not everyone uses cosmiconfig for config loading, and most people who just use e.g. prettier aren't even aware of cosmiconfig's existence.

Now, after I drifted away from the question a bit, I shall answer with a question of my own: Why are you so strictly against a new, optional feature that tooling maintainers don't even really have to care about?

If you don't want people to use it, just don't tell them. For the most part, at least at first, people will still be unaware of this feature because they're unaware of cosmiconfig itself even though it's in their dependency tree, possibly even multiple times.

[fisker]

Never mind. Hope other tool maintainers like it.

Just for the record, "No one requested it" I mean I didn't see any Prettier user asked for it in Prettier repository.