Feature Request: rustfmt.toml Inheritance (Directory-Level Overrides Via Multiple rustfmt.toml's)

[tmillr]

I feel like there should exist a way to be able to utilize multiple rustfmt.toml's for a single project. For example, tsconfig.json allows an extends key for this very purpose. Basically all config from an arbitrarily-named base file is loaded, then the normal/usual rustfmt.toml file is also loaded and any keys found in the normal config file which also overlap with the base config take precedence (overriding the corresponding base keys). Finally, both files are combined in order to derive the ultimate/final configuration that will be used. This allows for a single global/base config while also allowing a per-project/per-directory override as needed and uses regular rustfmt.toml files which can then be easily tracked and committed (unlike trying to override a base config by passing extra args to rustfmt itself). Also it seems that by default most plugins and such simply invoke rustfmt without any extra options but the file path or content, so relying on command-line arguments for setting or overriding options isn't really a great solution (doesn't really seem "portable" without manual user-intervention/re-configuration of existing tools/plugins, or a 3rd-party solution, etc.).

In my opinion, the current practice of only allowing a single config file seems to be somewhat limiting and can only be worked-around via a combination of unpleasant hacks (like writing a script to manually parse rustfmt.toml's, watching for changes to the global/base config file with e.g. watchman or vim autocommands, locating and updating all of my own "derived" rustfmt.toml files whenever the global rustfmt.toml changes). For my own personal/side-projects, I kinda would like to have my own set of global preferences that are used for every such repo I start that are also kept in sync whenever those preferences change, all while permitting per-repo overrides for the hypothetical use-case where incorporating particular settings into a global rustfmt.toml would not be appropriate (or, would conflict with my usual/regular preferences that I want for most repos).

I apologize in advance if this issue already exists. I did a quick search beforehand and found similar, but distinct, feature requests (such as file or method level overrides). I'm still getting a feel for GitHub in general.

[ytmimi]

Thanks for reaching out!

No worries about still getting used to GitHub. I find myself struggling to find things in the issue tracker all the time. Is #5313 similar to what you're proposing here?

[calebcartwright]

I think there's a few items in this, a large part of which is actually just the inheritance/merging of files as implemented in #4179.

That's definitely one we should backport, and which addresses the main thrust of this.

However, I'm not willing to take on an arbitrary extends key as suggested as part of the issue. It's a non-trivial effort that still has bugs in the JS/TS space even with the plethora of libraries that deliver those capabilities. As detailed in the first section of our configuration documentation, global config files are already supported so really the only missing piece is the merging, which a backport of #4179 would address.

I don't think there's anything actionable for us here beyond the backport which I've already labeled, so I'm going to close. Feel free to ask any follow up questions though.