Closed sschuberth closed 2 years ago
Yes, the tables are always rewritten in this order and white space like blank lines are not recorded during parsing. Would this prevent you from using the plugin or could you just accept the format like for example a code formatter like ktlint does? The benefit in my opinion that this prevents bike shedding conversations around the catalog toml file format, like other code formatting tools do (so in I'd consider this a feature myself 😁)
Would this prevent you from using the plugin
No, it wouldn't, I just took it into use 😁
this prevents bike shedding conversations around the catalog toml file format
Well, I'd argue an even better way to avoid bike shedding here is not not touch the formatting at all 😉
Anyway, if it's just to inconvenient to avoid sorting the section, feel free to close. Personally, I'm anyway committing each version update separately to be able to link the library's changelog in the commit message, so I can as well omit diff hunks that just touch the formatting.
Gave it some thought and I'll close it for now. Although it could be possible to have an option to specify in what order you want those sections, I'm not sure if that's a common enough problem to justify adding a setting really (and I still like to prevent having potentially a lot of formatting options). I hope you won't mind!
Although strictly speaking "sections" are not "keys", I'd expect that setting
sortByKey
tofalse
leaves the formatting of my wholegradle/libs.versions.toml
alone, including the order of the[versions]
,[plugins]
,[libraries]
and[bundles]
sections, and any custom blank lines added for formatting in between.What happens instead is that blank lines seem to be stripped, and sections being reordered.