Standardize a common configuration folder in the defaults

[d-fischer]

As pointed out in #152 (comment):

It would be great to have a solution like OP pointed out, or as others have suggested: <project_root>/.config

That means cosmiconfig has a golden opportunity to be a leader in standardizing / consolidating schemes.

The core problem for me is that my projects are cluttered with config files at the top level and I'd like to have the ability to personally wrangle that.

End users don't have much control over where their config files are located

To sum it up, I think it would be great to default to additionally searching in a predefined subdirectory (I think .config seems like the most popular one).

The benefit of this would be that you wouldn't have to clutter your package.json nor your root folder with tooling configuration, both of which seem to be annoying for many people. Rather than this being up to the library/tooling author that uses cosmicconfig, this should be up to the end user using said library/tooling (see last quote), which is why (IMO) appealing to library/tooling authors to customize searchPlaces is not the right approach.

You'd still be able to do either of these two ways; this is really just adding another option by default.

Do note that this is not a duplicate of #152 since the XDG config spec is for user-global configuration while this aims to standardize a common per-project configuration folder.

I am open to create a PR for this. EDIT: I already created #263 :)

[d-fischer]

This should be a minor version bump in order to enable people to just run a deep upgrade in order to be able to place their config files in a subdirectory.

[ssbarnea]

Use of .config is not a good idea, is a brilliant one. It matches already existing patterns and help decluttering project root directories. I do know other tools that already did this and I suspect many others will follow.

[d-fischer]

Use of .config is not a good idea, is a brilliant one. It matches already existing patterns and help decluttering project root directories. I do know other tools that already did this and I suspect many others will follow.

Yes, but sadly this seems to be actively ignored 😢 there could be so many tools at once to be decluttered if this was introduced in a patch/minor release!

[d-fischer]

Repost from the PR to increase visibility for people who have been following this issue:

I just published this PR as a fork!

To use it as an end user, you need to use yarn resolutions or npm overrides.

yarn

  "resolutions": {
    "cosmiconfig": "npm:@d-fischer/cosmiconfig@7.1.0"
  }

npm

  "overrides": {
    "cosmiconfig@7": "npm:@d-fischer/cosmiconfig@7.1.0"
  }

Then just move your config files to a .config subfolder :)

Caveats

• obvoiusly, this only works with tools that actually use cosmiconfig@^7.0.0 or higher. Some tools may be behind, some other tools (such as eslint) may not use cosmiconfig at all - if you want to move these files, they need to update their dependencies or change their other/custom solution!
• Even worse, with yarn, this might actually break packages that use a lower major version. YMMV!
• If the tool developer customized the configuration (specifically, the searchPlaces option) this doesn't work either. Again, I can't do anything about this, please show them that you want this!

[davidtheclark]

Just posted this note at the top of the README:

MAINTAINERS WANTED! If you're interested in taking over and maintaining Cosmiconfig, please let @davidtheclark know (with an issue or email). I'd like to hand over the keys completely, so I'm looking for owners, not people who just want to merge a PR or two! You can make the decisions about what happens in v8 and subsequent versions, how the package balances stability and opinionated features, and so on. Take a look at open issues and PRs to learn about possibilities that have been on people's minds over the years.

If you're interested in taking ownership of the package and moving this feature forward, let me know!

[MichaelDeBoey]

@davidtheclark If nobody wants to take over ownership, you can maybe contact @openjs-foundation to ask if they want to take over the project.

[d-fischer]

@davidtheclark seeing that there's a few people that now have requested access, but (whether or not they actually got access - didn't check) things are still not moving here (not just this issue in particular, but the whole repository), I would like to get access to maintain and publish this package.

[d-fischer]

This now landed in version 7.1.0 which I just published - closing 🎉