Add .config subdir to default searchPlaces

[d-fischer]

fixes #262

Open questions:

• do we want to add the .config.ext variants inside the config folder? (yes/no)
• do we want to keep the rc suffix? (yes/no/only for the extensionless file/add both variants/...?)

Also there should probably be adjustments to the tests and the README :)

[d-fischer]

Someone mentioned to me that Unix CLI tools usually drop the dot when they are in a folder dedicated to configuration files, but they keep the rc suffix. If we'd like to follow this, that would answer the second question.

[d-fischer]

There is a use case for handling the containing config subdirectory separately from the file names (for example, to support even cosmiconfig consumers that changed the default searchPlaces), but I won't get to provide this kind of alternative implementation this week. Feedback on this approach is appreciated :)

[kentcdodds]

How can we help get this over the finish line?

[d-fischer]

How can we help get this over the finish line?

I don't know - the maintainer has shown no interest in this at all.

[kentcdodds]

Looks like @davidtheclark is no longer very active in OSS and the last commit was by @Codex-. Any chance this could get in Alex? 🙏

[kentcdodds]

Oh, my bad, just realized Alex's commit was merged by @davidtheclark. I noticed that @sudo-suhas has publish rights on the package though. Any chance you could help us here?

[kentcdodds]

Maybe switch to lilconfig? https://github.com/antonk52/lilconfig/issues/27

[d-fischer]

I mean, this issue/PR proposes a solution where tooling maintainers don't have to do anything to fix this problem (unless they have non-default config in some specific keys).

Proposing to switch libraries is a thing you'd have to do with every single tooling maintainer, and if they don't like it, we're back to square one.

[kentcdodds]

Agreed, it would be better to have this added to cosmiconfig, but if no maintainer is maintaining it then that won't happen. Just suggesting an alternative. I've definitely personally been the maintainer of a library I was tired of maintaining and was thrilled to deprecate it in favor of something else.

[MichaelDeBoey]

As I said on Twitter: it would be an extra hurdle to convince all these packages to switch to lilconfig, especially since it would be a breaking change because lilconfig handles files without an extension differently https://github.com/antonk52/lilconfig#difference-to-cosmiconfig

So I think it's a better approach for the whole community that @davidtheclark at least gives somebody some rights to co-maintain the awesome package and this PR can get merged 🙏

[d-fischer]

The problem is that this is a breaking change to all users of the tool. If a YAML loader is not explicitly given, all existing YAML config files will break.

Anyway, I don't think a "call to replace this" is on topic here.

[d-fischer]

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/[email protected]"
  }

npm

  "overrides": {
    "cosmiconfig@7": "npm:@d-fischer/[email protected]"
  }

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]

If there are no hard objections, I will merge this into a new branch that will branch off main before the js-yaml change and try to manage getting a minor version out that includes this.