Would you be open to supporting the dot-config standard?

[michaelherold]

Background

The dot-config standard is a pseudo-extension of the XDG Base Directory Standard from the FreeDesktop project.

It proposes that the $PROJECT_ROOT/.config folder contains all the configuration files for tooling within the project instead of living in a pile at the project root.

Rubocop recently added support [1, 2] for it in the form of supporting $PROJECT_ROOT/.config/rubocop/config.yml or $PROJECT_ROOT/.config/.rubocop.yml in addition to the original .rubocop.yml file.

Proposal

It would be nice if Standard also supported the dot-config system by searching for a configuration file at $PROJECT_ROOT/.config/standardrb/config.yml (or $PROJECT_ROOT/.config/standard/config.yml) to support this standard (pun intended).

I propose the logic within BuildsConfig and ResolvesYamlOption be extended to search for:

1. The path passed as --config, then if not given or missing;
2. The current standard of .standard.yml, then if missing;
3. The new standard of $PROJECT_ROOT/.config/standardrb/config.yml

I do not believe it makes sense for Standard to support $PROJECT_ROOT/arbitrary/directory/.config/standardrb/config.yml (and I don't believe that it currently supports $PROJECT_ROOT/arbitrary/directory/.standard.yml) since Standard is not configurable in a way that one might want to use a different Standard configuration in a separate part of a project… though I might be wrong here.

If I'm wrong, then the list becomes:

1. The path passed as --config, then if not given or missing;
2. The current standard of .standard.yml, then if missing;
3. #{Dir.pwd}/.config/standardrb/config.yml, then if missing:
4. Pop a directory from Dir.pwd and repeat until Dir.pwd is the $PROJECT_ROOT

Offer

I'm willing to put in the legwork to add support if the project would like this addition.

Why wouldn't we want to support this?

I can think of two lines of reasoning as to why we wouldn't want to support this standard:

1. Giving choice to where the configuration file lives works against the "no bikeshedding" ethos of Standard as a project. This is a weak argument because either your team puts configuration in .config as much as possible or not; there shouldn't be arguing about it beyond the initial decision of "should we put tool configuration in .config?"
2. Supporting the XDG Base Directory specification could be done more elegantly through the use of XDG_CONFIG_DIRS, which a project could augment with tooling such as Shadowenv or direnv to include $PROJECT_ROOT/.config at the front of the path list. I'd like to believe that this is something that teams would be willing to do, but in my experience, this is a step too far in headache for the sake of purity for most teams (for N ≅ 12 distinct teams that I've worked with in my career). As such, my opinion is that this is a weak argument.

Open questions

1. What namespace should we use? .config/standardrb? Or .config/standard? My opinion is standardrb.
2. Should we move to deprecate .standard.yml if this proposal succeeds? My opinion is no because the ongoing maintenance cost/burden is low and the switching cost for teams is non-zero.

[searls]

Hey @michaelherold thanks for this. I'd be open to this change, assuming it's well-tested and doesn't break anything. I'm curious other people's thoughts.

My answers to:

What namespace should we use? .config/standardrb? Or .config/standard? My opinion is standardrb.

standardrb is safer

Should we move to deprecate .standard.yml if this proposal succeeds?

I'd say no. I don't see a reason to make anyone switch, personally

[michaelherold]

I started working on this and noticed a wrinkle in the implementation. FileFinder uses Pathname#ascend to look for the configuration file in ascending folder structure.

Since I'm attempting to make this as small of a change as possible, I am going to reuse this machinery for the .config/standardrb pattern as well so that the behavior is consistent between .standard.yml and .config/standardrb/config.yml.