Monorepos, "required root" files, and the config dir proposal

[adamdehaven]

Required versus optional config file locations

You mentioned some files in the proposal that are common and unlikely to be nestable, mentioning .env and .gitconfig.

• What about tsconfig.json, .nvmrc, renovate.json, wrangler.toml files, and others?
  • These are definitely "config" files in respect to the repository, CI pipeline, etc., but will they be able to benefit from the same /.config/ directory placement?
• Wouldn't other .*ignore files face a similar issue such as .eslintignore, .stylelintignore, etc.?

Will moving to a /.config/ directory for some (but likely not all) tools/frameworks essentially bifurcate the ecosystem into two groups, whereby "some config files must live at the root, whereas other config files can live in a /.config/ directory"?

Does this run the risk of making things more confusing for developers to get up and running?

Opt-in

You mentioned the proposal would be opt-in, but TBH I'm leaning towards that in itself actually having the potential to make things worse?

Imagine yourself working in an organization with a large, distributed team of Vue/Nuxt engineers. If 1/2 of them set up their repositories with root-based configurations, and others opt for the /.config/ proposal, at what point do you hate context switching between projects, having to remember what is where?

Could this also create an issue with your IDE configuration when moving between projects (needing to adjust for the location of the config files)?

Monorepos

Currently, the convention for monorepos supports defining your base config files at the root of the repository. Based on the proposal:

In the case of monorepo when users need to specify multiple files of the same config, the config files can be nested into /<path>/.config directory and based on the tool requirements either merged with mono repo's /.config or not.

I think this makes sense in theory, as you would essentially extend from the /.config/* directory's files. Assuming this works with no extra config, given the other questions above, this piece sounds less painful.

[adamdehaven]

I also added a suggestion as to the naming from /.config/ => /.configs/ via #3 (comment)