It's pretty common to run cargo fmt --check in CI to firmly enforce a very specific code formatting. However, usually projects do not have, and may not want to add a rustfmt.toml file to their project to specify their required formatting style explicitly (by having an empty file that resets the settings to default).
fmt --check enforcement combined with the lack of a config file implicitly assumes that every contributor uses the default rustfmt config themselves. This makes existence of global rustfmt config (~/.rustfmt.toml) very contentious. If projects don't reset their rustfmt settings to default, then having any non-default rustfmt config actively ruins formatting in the projects that assume the default, and makes the global settings worse than useless. OTOH it's a big ask to require essentially all Rust projects to add a rustfmt config.
Do you have any ideas how to solve this dilemma?
Currently the ability to change rustfmt's defaults doesn't really work, because instead of having formatting automated and out of mind, it gets in the way and requires manually fixing CI failures due to formatting (some features like comment wrapping make the damage irreversible, so it's even more work than just reformatting a branch with the default config).
The alternative to a global config would be to copy the non-default config to each project using it, but that adds work to keep config copies in sync. An empty rustfmt.toml file is easier to "maintain".
Could there be some other option?
Perhaps rustfmt could have a notion of presets defined globally, so that non-standard projects can specify their style without copying the whole config?
Could rustfmt work more like gofmt, and allow the input to decide how lines are wrapped, as long as the line lengths stay under the limit, and breaks and indentation are correct for the style? (i.e. treat max_width as an actual maximum to wrap at, but not as the goal for extending shorter line lengths into). This won't solve all config mismatches, but rustfmt unwrapping multi-line code blocks into a single long line to maximize configured line length is the most common source of unnecessary big formatting changes.
Thanks for reaching out. I'm pretty sure this is more or less a duplicate of #6264. I left two workaround suggestions in that issue, but they both involve the user needing to create config files on their system.
It's pretty common to run
cargo fmt --check
in CI to firmly enforce a very specific code formatting. However, usually projects do not have, and may not want to add arustfmt.toml
file to their project to specify their required formatting style explicitly (by having an empty file that resets the settings to default).fmt --check
enforcement combined with the lack of a config file implicitly assumes that every contributor uses the defaultrustfmt
config themselves. This makes existence of global rustfmt config (~/.rustfmt.toml
) very contentious. If projects don't reset their rustfmt settings to default, then having any non-default rustfmt config actively ruins formatting in the projects that assume the default, and makes the global settings worse than useless. OTOH it's a big ask to require essentially all Rust projects to add arustfmt
config.Do you have any ideas how to solve this dilemma?
Currently the ability to change
rustfmt
's defaults doesn't really work, because instead of having formatting automated and out of mind, it gets in the way and requires manually fixing CI failures due to formatting (some features like comment wrapping make the damage irreversible, so it's even more work than just reformatting a branch with the default config).The alternative to a global config would be to copy the non-default config to each project using it, but that adds work to keep config copies in sync. An empty
rustfmt.toml
file is easier to "maintain".Could there be some other option?
Perhaps rustfmt could have a notion of presets defined globally, so that non-standard projects can specify their style without copying the whole config?
Could
rustfmt
work more likegofmt
, and allow the input to decide how lines are wrapped, as long as the line lengths stay under the limit, and breaks and indentation are correct for the style? (i.e. treatmax_width
as an actual maximum to wrap at, but not as the goal for extending shorter line lengths into). This won't solve all config mismatches, but rustfmt unwrapping multi-line code blocks into a single long line to maximize configured line length is the most common source of unnecessary big formatting changes.