-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Would you be open to supporting the dot-config standard? #625
Comments
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:
I'd say no. I don't see a reason to make anyone switch, personally |
I started working on this and noticed a wrinkle in the implementation. Since I'm attempting to make this as small of a change as possible, I am going to reuse this machinery for the |
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
andResolvesYamlOption
be extended to search for:--config
, then if not given or missing;.standard.yml
, then if missing;$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:
--config
, then if not given or missing;.standard.yml
, then if missing;#{Dir.pwd}/.config/standardrb/config.yml
, then if missing:Dir.pwd
and repeat untilDir.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:
.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
?"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
.config/standardrb
? Or.config/standard
? My opinion isstandardrb
..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.The text was updated successfully, but these errors were encountered: