Validate/dry-run mode

[Kernald]

Matching google-java-format's google/google-java-format/issues/105 and google/google-java-format/pull/106 - it would be nice to have a dry-run mode that would show which files would be changed. Context: a CI task checking that the files are properly formatted.

google-java-format does this with two command line switches:

--dry-run or -n
Prints the paths of the files whose contents would change if the formatter were run normally.

--set-exit-if-changed
Return exit code 1 if there are any formatting changes.

[cgrushko]

Thanks for the idea.
What CI is this?
On Spotless for Gradle, for example, you get this for free from ./gradle build if I understand correctly.
Anyway, happy to accept a PR for doing this.

[Kernald]

I'm not using Gradle - Bazel on GitLab CI. I can do something to run ktfmt over the whole repo, but building something more fine-grained by generating actual test targets would be much more convenient. Glad to see that it's something you'd be happy with, I don't have time to do that any time soon either, but if I have a free Sunday afternoon... :-)

[cgrushko]

I can do something to run ktfmt over the whole repo, but building something more fine-grained by generating actual test targets

Can you elaborate?
Do you mean Bazel sh_test targets to be run on presubmit?
Is this how you run google-Java-format presubmit?

[Kernald]

Sure, happy to elaborate - I don't have any Java so I don't run google-java-format. But I do run ktlint, and hoped I could do something similar. Basically, for every kt_*_library and kt_*_binary target, I generate (all those targets are behind macros) a $name_ktlint_test target, which runs ktlint on those source files specifically. This allows me to leverage Bazel's caching mechanism and only re-run ktlint on source files that actually changed. I described the whole process over here and a very similar approach is currently being worked on over in bazelbuild/rules_kotlin.

[cortinico]

it would be nice to have a dry-run mode that would show which files would be changed

As a side note, ktfmt-gradle will also benefit form this. Currently I had to manually diff the ktfmt output with the original source file to understand if there was a violation or not (in order to support a ktfmtCheck task).

[cgrushko]

This is now fixed in main, will release a new version on Monday or Tuesday.